Re: Pushing all the buttons
On Sat, Sep 20, 2003 at 12:33:26PM -0700, Mike Champion wrote: > [Quoting from Bray, St. Laurent, and de Hora ...] > >>>>Pelegri-Llopart said "The main point here is there is almost >>>> is almost an order of magnitude between straightforward Web >>>> services using XML encoding and an implementation that takes >>>> care of binary encoding." > Is anyone disagreeing with that assertion? I hear it from a lot > of apparently independent sources. > Presumably we'll see data at the "Binary Infoset > Serialization" workshop next week. I don't think I'd be giving away any secrets if I said you can reasonably expect Sun to present their paper and measurments :-) As far as I can tell, people *are* using binary representations of XML in various ways, for various purposes, already. They aren't going to stop just because W3C doesn't tell them how to do it, or just because xml-dev doesn't like it :-) So the question as I see it becomes, is there a way to specify a binary format, or binary interfhange framework of some kind, in such a way that a significant majority of the people currently using binary formats agree to implement and use it? If so, we are possibly increasing interoperability, and should investigate it further. If not, people may need to focus on generic compression combined (in some cases) with better parsers. Mike Champion also asked, > is the more-or-less-indisputable fact that one can get an XML > distributed app up and running much faster than a proprietary-format > distributed app due to the standards-ness of XML or the text-ness > of XML? I think it's a combination... * widespread support in tools and toolkits * standardised in a way that makes most obvious errors be fatal, so that syntactic variants are pretty much non-starters * over-hyped in its infancy, which gave XML lots of momentum The textness helped people write the tools, and helps with the documents, I agree. However, examples of non-text formats include * Microsoft Office save files, widely used becuase of market dominance. A text-based alternative, RTF, has interoperability problems, possibly because the standard wasn't formal enuogh and there were no conformnce tests, but I don't know if that's true. * TCP/IP network packets... tcp/ip took off because of freely available toolkits, at a time when the major competitor from ISO was expensive, and yuo even had to pay for the specifications, which were large and complex. * most image formats, because of compactness -- although the "pbm" and "xpm" text-based formats are widely used because they are amenable to Unix pipelines with many different tools, e.g. awk. RTF and HTML are both examples where standardisation was difficult because competing vendors were trying to innovate by introducing features that required format-level changes. One answer is to move to punt features to a higher layer -- e.g. a document formatter is unlikely to request changes to the XML spec, but may want changes to XSL/FO or CSS. This sounds at first as if it doesn't help, but it does help, because not all users of XML are using it for the same things, so changes in one area needn't affect users in another... and the layering means that documents need not be changed directly so often. In the same way, I think any binary XML interchange format needs to be exactly that - a layer that's used to transmit, store, process and interchange information without directy affecting higher layers of processing. I admit I am still not certain it's possible, but then, that's why I think having a workshop might be useful :-) > As best I know, the big win for truly binary XML > serializations is in avoiding the overhead of the > Unicode-encoded text to UCS-character translation. For some people, avoiding parsing at all can be a win -- e.g. transmitting a "tree". > Of course, the big downside for all alternative > serializations is that they seriously limit > interoperability. But remember that the whole POINT > of this "efficient alternate serialization of the > Infoset" stuff is to buy performance at the cost of > some interoperability, to be used in specifically in > situations where the pain of worse performance is > worse than the pain of lower interoperability. And the > whole point of standardizing a small number of > alternative serializations would be to get some of > that interoperability back. Agreed completely. Liam -- Liam Quin, W3C XML Activity Lead, liam@w..., http://www.w3.org/People/Quin/ Ankh's list of IRC clients: http://www.valinor.sorcery.net/clients/ http://www.holoweb.net/~liam/ -- Tread barefoot on the land
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