[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Binary XML == "spawn of the devil" ?
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! 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
|