[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RE: Schema vs Schema-free
> -----Original Message----- > From: Tim.Bray@S... [mailto:Tim.Bray@S...] On Behalf Of Tim Bray > Sent: Wednesday, April 14, 2004 13:46 > To: Rich Salz > Cc: 'xml-dev'; bob@w...; 'Elliotte Rusty Harold' > Subject: Re: RE: Schema vs Schema-free > > > On Apr 14, 2004, at 9:27 AM, Rich Salz wrote: > > > No, it's a mismatch between the data-type folks and the markup-type > > folks. And the data folks don't seem to realize that the > current crop > > of security functions requires them think like markup-type folks on > > the wire. > > Indeed. And to pound my tired old drum, since I haven't for a few > weeks: The only basis for interoperability in networked > systems is at > the level of bits-on-the-wire. You can pretend this isn't > so, but it > will always bite you. Tim, I don't see why the use of ASN.1 would not satisfy this constraint. Given an ASN.1 specification, and given a value for a data type defined in it, and given the name of the encoding rules used, the bits on the wire are defined unambiguously. There are two kinds of encoding rules: canonical and non-canonical. - If you use canonical encoding rules, the bits on the wire are not only unambiguously defined, but also *exactly* defined for any possible abstract value (however complex). - If you use non-canonical encoding rules, there is a minor variability due to "encoder's options". I am not aware that the existence of encoder's options in BER has ever been a problem except when a unique on-the-wire representation is needed. In such cases, people can choose DER/CER or canonical PER. (By the way, non-canonical PER is actually canonical in most cases.) The restriction of ASN.1 is that all parties *must* agree on a set of type definitions. Normally, you cannot make an arbitrary unilateral change to the type definitions and hope that you will still be able to reobtain the abstract value that is represented in a message. In return for this constraint, ASN.1 gives you speed, compactness, and flexibility. Indeed, this very flexibility enables ASN.1 to encode abstract values in XML, and decode them and re-encode them at will between XML, PER, BER, etc. Since abstract values exist independently of representation, we have "pluggable" representations. This provides a clean conceptual model of transcoding instances between XML and other representations. The price for this is the "invariability of the specification". In addition, in ASN.1 there are provisions for versioning and dynamic extensibility, which mitigate the issue of invariability of the specification. I have yet to hear a convincing argument that ASN.1 is inherently less interoperable than XML. Historical accidents, such as buggy software, are not relevant. Alessandro Triglia OSS Nokalva -Tim >
|
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
|