OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] ASN.1 is an XML Schema Language (Fix those lists!)and Bina

[ Lists Home | Date Index | Thread Index ]

Bob Wyman wrote:
> Robin Berjon wrote:
>>There's a lot to say in favour of minimizing the 
>>number of concrete syntaxes, and that's where a 
>>lot of the concerns about having *two*  (just two!) 
>>universal formats came from at the binary infosets 
> 	The number of syntaxes isn't important. The only important
> question is: "Can two systems interoperate?"

Obviously, interoperability is at the heart of the matter. But it is 
much easier to interoperate with a single concrete syntax than with ten. 
Lesser complexity, little or no negotiation.

> Well, even if there are
> hundreds of alternative syntaxes, you can always answer "Yes" to that
> question by simply making a rule: "Text-based XML must always be
> supported. All other encodings are optional." This allows "Dual
> encoding" systems (systems that support both text-based XML and binary
> encodings to interoperate with *any* other system. 

This was also suggested at the workshop, but fails to work in cases 
where the reason XML doesn't work is because of its footprint (or 
sometimes other issues such as performance that cannot drop below a 
given threshold). In those cases you can't reasonably ask people to 
support XML 1.x, and if you do they won't listen.

Also, it won't work for unidirectional networks. If you broadcast using 
an optional encoding that I don't support, you'll never know about it 
and the broadcast will fail. Using XML 1.x in such situations is rarely 
an option. Negotiation only works when one can negotiate.

Goal 5, amongst other things stated before in this thread, has helped XML

   5. The number of optional features in XML is to be kept to the
      absolute minimum, ideally zero.
      -- http://www.w3.org/TR/REC-xml#sec-origin-goals

Options do tend to get in the way of interoperability.

>>The ASN.1 equivalent of a simple XML parser in terms of 
>>universality would have to properly decode (and likely 
>>handle negotiation for) BER, PER, CER, DER, XER, and 
>>probably LWER, OER, and SER. That's a bit of a 
>>behemoth to implement!
> 	It may be hard to implement, however, it has been done -- at
> least for BER, PER, CER, DER, XER, CXER, and E-XER... At least by the
> commercial suppliers like OSS Nokalva.

Is it possible to reliably auto-detect which ER is being used?

> Yes, building an
> open source equivelant would be a challenge... But, it is just a
> question of being "hard." 

A SMOP? ;)

> At least there aren't any patent issues like
> there are with something like "binXML" or the other binary encodings
> people are inventing these days.

Do you have specific examples or are you saying that everyone except 
X.694 is encumbered? Has ISO/ITU-T performed patent searches covering 
X.694? It was brought to my attention as I used that very same argument 
that X.694 was in fact covered by some patents :(

Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway      http://expway.com/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS