[
Lists Home |
Date Index |
Thread Index
]
Simon St. Laurent wrote:
> If some aspect of ASN.1 can cover mixed content and open content
> models, I'm happy to welcome it to my regular list of XML schema
> languages.
ASN.1 has explicit support for "Open Types" as well as
specific support in the X.694 XML encoding stuff for the equivelant of
XML Schema's "xs:any" and "xs:anyAttribute") X.694 extensions even
provide the support needed to handle XML namespaces, etc...
>(It's the anyXML->ASN.1->anyXML part that seems to remain a problem.)
This picture doesn't make sense. You don't convert concrete
data to ASN.1. ASN.1 is abstract. Data is concrete... You use ASN.1 to
define how data should be converted from one format to another. The
picture would make more sense like this:
anyXML -> InMemoryDOM -> (anyXML or PER or BER or ??)
You use ASN.1 to tell an XML decoder how to convert XML to
your in-memory data structures. Then, you can process the data or you
can write it out using either an XML encoder or an encoder for some
other format. The ASN.1 definition and the in-memory structures are
independent of the specific encoder.
If you only care about XML, then the picture looks like this:
anyXML -> InMemoryDOM -> anyXML
If you want to read and write PER then you get this:
PER -> InMemoryDOM -> PER
If you want to read PER and write XML, you get this:
PER -> InMemoryDOM -> XML
In all cases, the in-memory data structures and virtually all
of your code are identical. (Except for the call to tell which
encoder/decoder to use.)
>There could be some very cool stuff there.
It's not a "could be"... There *is* cool stuff here!
bob wyman
|
