[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ASN.1 and XML
On Sun, 27 May 2001, Thomas B. Passin wrote: > In ASN.1 you have types and values. In xml-schema, you have types, > elements, and values (disregarding attributes and other good stuff to > simplify). In basic xml 1.0, it's not exactly clear whether an element is a > type or not in some sense that corresponds to the other two. Indeed. The result of ASN.1 as XML is indeed tied to something like the Infoset; there is a standard semantic toolkit behidn it all. The current issues are: 1) It's currently mandatory in ASN.1 that types have names starting with a capital letter, and values with a small letter. sually, value names map to XML element names - the things compromising an Address-typed element are called street city, and postcode so the elements are named after that, not "String". This is fine when you're encoding something with ASN.1 roots in XML, but how does that cope with an existing XML schema using capital letters on things that you convert to ASN.1? The case-of-first-letter thing will probably be dropped from "requirement" to "stylistic recommendation". Similary with attributes. In ASN.1, a compound type has a set of fields with values. Which fields go to attributes and which to child elements? You can say that all children of simple type go to attributes and the rest as elements, perhaps. Again, that's fine for ASN.1->XML, but hwo do we recreated the behaviour of existing XML vocabularies? It looks like we'll have to extend the ASN.1 syntax a bit to allow some kind of special tagging to mark our preference in XML encodings, but such encoding issues are not meant to come up in the Abstract Syntax Notation itself! Mixed content is easier. We just add a UTF8String field to the SEQUENCE type representing the enclosing element, with a special name such as "mixed-text", ideally one that's a valid ASN.1 name but not a valid XML element/attribute name to avoid problems. > This > disconnect is the main thing that that makes an xml encoding of ASN.1 from > being obvious. An encoding that captures everything ASN.1 needs is easy, an encoding that captures a distinction between attributes and child elements is a little trickier :-) > An automated ASN.1 - to -xml schema translator might make it quite > attractive to do your schema in ASN.1 first, to get started. Murali Mani > might complain that there's no satisfactory theory underlying the ASN.1, I > don't know, but it's interesting to think about. In terms of theory, ASN.1 works basically precisely like type declarations in your favourite typed programming language - you define types of array/struct/whatever and build them up. > If you didn't insist on handling everything in ASN.1 but limited yourself to > a subset that was especially suited for representing xml schemas, I think > such a translator wouldn't be too hard to come up with. The fun is more when you try to do the *other* way around :-) > > Tom P > ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|