Re: ASN.1 and XML

[Al Snell <alaric@alaric-snell.com>]

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