Re: ASN.1 and XML

["Thomas B. Passin" <tpassin@home.com>]

ASN.1 actually makes a pretty good schema language that is easy to read and
write if you don't mind that it reflects pretty straighforward xml (which
might be a Good Thing).  But there is a real disconnect between ASN.1 and
XML/XML-schema.

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.  This
disconnect is the main thing that that makes an xml encoding of ASN.1 from
being obvious.  You have to consider each kind of construction individually
to come up with a mapping.  And it's best to have a mapping that can be
programmatically applied.  You can always wing an xml format by hand, but
that's not a desirable way to go in the longer run, since no-one can predict
what the next mapping will be.

Once you have some mapping, it's quicker to whip up an ASN.1 schema than an
XML-schema (by hand, I'm talking about) and the result is more readable.  As
long as you don't mind giving up a bunch of stuff that xml-schemas (and xml)
can give you, that is.  As usual, it depends on what you want to use it for.

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.

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.

Cheers,

Tom P