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] Xqueeze: Compact XML Alternative

[ Lists Home | Date Index | Thread Index ]

On Tue, 4 Feb 2003 07:59:03 -0500, Elliotte Rusty Harold 
<elharo@metalab.unc.edu> 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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS