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] Binary XML == "spawn of the devil" ?

[ Lists Home | Date Index | Thread Index ]

Bullard, Claude L (Len) wrote:
> This is likely the nut of the problem to be resolved.  It is possible 
> that binarization gets the best results for each application 
> by becoming non-interoperable across applications.

Yes, that is definitely something to be given thought to. However the same can 
be said of virtually anything meant to interoperate. A number of features could 
be dropped from XML for instance, but the hard thing there would be to find 
which parts to drop.

It is likely that an interoperable bInfoset format would be less efficient than 
a highly specialised one. I'm pretty sure I could cook up something that would 
compress better than most bInfoset formats (like XbMill) and lose speed, dynamic 
update, etc. But if I'm only gaining 10% on the interoperable format, it's not 
worth it. It's all in figuring out the right trade-off, and I certain it's very 
well possible to find something generic.

Besides, considering losing interoperability may be an option in some systems 
today, but I see it as an increasingly costly decision as "webization" proceeds 
from outside documents (making things HTTP-accessible) to within them (usage of 
mixed-namespace documents). As the workings of multiple-namespace documents are 
increasingly well understood, I wouldn't be surprised to see some interesting 
mixes of SVG, XForms, X3D, various voice MLs, some music and sound control ML, 
XHTML, all of those shooting off or carried inside Web Service message, with 
lots of RDF sprinkled over. In fact, with the exception of X3D and the music 
stuff, all of that is already visible in the SVG world.

You aren't going to go far in there without an interoperable format :)

> Considering all text nodes to be of the same content and 
> equal in value is false. The binarization approach taken 
> to indexed face set content (see X3D) and <p> may be 
> completely different.

Very true. I'm tempted to place that as issue number one, the rest (encoding of 
the structure) can multiple solutions but it ought to be simple enough to pick 
the best. Adressing the encoding of text nodes leads one to think of pluggable 
codecs, and all the associated interoperability issues. Some groups however have 
been working on the issue (I believe notably around X3D) and I'm pretty sure we 
can find something inside (abtract codecs) or outside (content negotiation) of 
the format.

In fact, if HTTP 1.1 content codings took parametres, we'd have the answer 
already. Damn :)

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
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