[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Binary XML == "spawn of the devil" ?


xbmill
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@e...>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.