Re: Xqueeze: Compact XML Alternative
On Tue, 4 Feb 2003 07:59:03 -0500, Elliotte Rusty Harold <elharo@m...> wrote: > Without any comments, positive or negative, on the idea of binary XML in > general or your specific implementation of that idea, I will note that > over the last few years I've seen an average of approximately one such > binary XML tool per month announced here or elsewhere. To date, none of > them have garnered any significant interest or adoption in the community. > This may perhaps say something about whether this a frutiful area in > which to invest your time. Or one could say it's one of the hard unsolved problems that would garner great rewards for its conqueror :-) Efficient XML transmission/parsing is one of those things that only becomes a problem if XML is pervasive. As lots of people note (especially Sean's article he pointed to earlier today) XML parsing is seldom a bottleneck in today's applications, especially document-oriented ones. Thus the knee-jerk "XML is too slow" reaction is a bad case of "premature optimization." But what if XML's success creates demand levels that we haven't seen before? Post-maturity optimization may be necessary :-) Here's just a couple tidbits from today's surfing http://www.bea.com/events/webservices/Bosworth_WSRC_Jan03.pdf -- an Adam Bosworth "vision thing" piece. Note p. 43 about XML databases (and obviously the middleware and applications they support) serving up XML messages/fragments/state thousands of times per second. How sure are we that bandwidth/parsing performance is not a bottleneck in such a scenario? http://www.cysive.com/news/2003/2-03-03.htm OK, I'm sure you'll all be shocked and astonished to hear that Web services invocations of code are slower than native invocations of code, but this indicates that some people are trying to make money in this space. I'm all for loose coupling, pipelining, platform/language-independence ... but we will be increasingly shown that it comes at a performance cost; the solution is clearly NOT to give up the benefits of these things, but to work to drive down the cost. That said, the Xqueeze approach of using a dictionary based on a pre- arranged schema has been tried repeatedly, no? (e.g. WAP/WML?) Also, that significantly tightens the coupling between the sender and receiver of the XML. Maybe that is acceptable at the application level, but that middleware that is crunching thousands of XML messages/second isn't going to want to know about every schema of every application that is throwing data at it. So, I agree that nobody has shown a good solution here, but I don't agree that it means there there's no problem. There may not BE a good solution outside a given application (another point I believe Sean has made) because the parameters and constraints on them (message size, markup overhead, whether or not the vocabulary is known in advance, whether the "SOAP profile" of XML is in use or whether entity expansion must be supported, what kind of bandwidth and processor speed can be assumed, etc.) are so variable. But that doesn't mean that possible solutions shouldn't be explored, IMHO.
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