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] Re: Where does the "nothing left but toolkits" myth come f

[ Lists Home | Date Index | Thread Index ]

On Thu, 10 Feb 2005 07:27:33 +1100, Rick Marshall <rjm@zenucom.com> wrote:
> even though i have heard of some excellent use cases for "binary xml"
> i'm still not sure that technology won't fix that.

That's probably true in the long run.   In the short-to-middle term,
there are very serious technological constraints on bandwidth and
batteries (which are drained all the more quickly by additional CPU
usage) on mobile devices. [1] For the "XML is too slow to parse" use
cases, I agree that technological fixes -- dear old Moore's Law, or
specialized hardware of the sort Tarari, Datapower, Sarvega, etc.
makes -- may well make this problem irrelevant.  Of course, the market
will determine whether customers want faster XML hardware or
smaller/easier XML-ish data.  I'll guess that XML text will win
(outside the wireless domain, anyway) when interop is a consideration,
but developers of multi-component XML software systems (e.g. a DBMS
with a client side library, or a "service bus" where different web
services are offered in a pipelined manner) will be taking "binary
XML" *very* seriously as a way of communicating between their internal

> so bloatedness does matter, but is xml bloated? no. does it have
> redundant information? yes, because it can be compressed. now much?

The usual response from binary XML advocates is "at what cost".  If
you are trying to minimize actual latency to the user, compression
seldom actually helps.  Also, popular compression schemes don't work
until they have a few K bytes of data.  For relatively small messages
over a slow channel, conventional compression does not hit the sweet
spot.  Also,if you decompress at the cost of draining the battery in a
few minutes, you will probably have dissatisfied customers.   Of
course, these are all ultimately business decisions about engineering
tradeoffs, not hard and fast rules.

> so here's a real problem - will things like xslt have to cope with both
> formats? 

No, XSLT, XQuery, DOM, all work off an XML data model, not the raw
syntax. At worst, only the code that builds and serializes the
internal data structures must adapt to a binary format that has the
same information as XML text.   In some prototypes, the binary XML
format is analogous to a stream of serialized events produced by an
XML 1.x parser.  A simpler and more efficient parser can take this
format and generate the same  events that the original XML text would
have.  The same  event handlers that were written for text input can
be re-used for the binary input ... since they have never had any idea
of what series of bytes triggered the event.

[1] Of course some magic technology breakthrough could come along and
change the constraints such that plain ol' XML text is good enough for
domains such as wireless.  FWIW one of the keynoters (David Yach of
RIM) at the VLDB conference last year spent a good bit of time
explaining why that is unlikely, and DB people will just have to come
to grips with the reality that handhelds play by different rules that
the client apps we are used to. 


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

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