Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
