[
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.
|
