Re: Non-XML binary formats

> -----Original Message-----
> From: public-xml-binary-request@w3.org 
> [mailto:public-xml-binary-request@w3.org] On Behalf Of David Ryan
> Sent: Tuesday, November 30, 2004 08:04
> To: bobwyman@pubsub.com
> Cc: 'Stephen D. Williams'; public-xml-binary@w3.org
> Subject: Re: Non-XML binary formats.
> 
> I've made the effort to go back and look over some of the ASN.1 
> standards.  Again briefly, however, I think with enough knowledge to 
> re-iterate that ASN.1 was not what I was looking for then as 
> is now.  I 
> reviewed the specifications at 
> http://asn1.elibel.tm.fr/en/standards/index.htm as provided in an 
> earlier email by Ed Day.  I was impressed with the XML Schema 
> to ASN.1 
> mappings, however, was surprised that no ASN.1 to XSD mappings were 
> present.  


The ASN.1 standards group has now started working on that.  The availability of bidirectional mappings between ASN.1 and XSD has always been considered desirable, but priority was given to the XSD->ASN.1 mapping because it implicitly provides a "binary encoding" for XSD schemas.

The idea is that, given an XSD schema, you can translate it to ASN.1 by using X.694, then you can use PER to encode the instances (between two ASN.1-based endpoints), thus achieving greater speed and compactness.  Or you can use XER to exchange XML instances (between an ASN.1-based endpoint and a non-ASN.1 endpoint that creates and processes XML).

In other words, once you have obtained an ASN.1 schema "equivalent" to the original XSD schema, you can use it either for validation, or for producing binary encodings.  If the XSD schema changes, you can always redo the translation.

(X.694 goes into as much detail as to guarantee that two conforming implementations will always interoperate on the wire when applying PER, BER, XER, etc. to the ASN.1 schema).

The reverse mapping (from ASN.1 to XSD) will enable other usages.  For example, since ASN.1 is in general much more readable and concise than XSD, some people may want to use it as the primary schema language, and then translate ASN.1 schemas to XSD for easier integration with tools and technologies based on XSD.  Each time the ASN.1 schema changes, the translation can be redone, so there will be no need to maintain two separate sets of schemas.

Alessandro Triglia
OSS Nokalva

Received on Tuesday, 30 November 2004 17:37:03 UTC