Default User wrote:
I'm working on a research and development project involving binary XML.
Binary XML (misnomer!) is not a recommendation yet; it's exploratory
work. Past experiments have generally suggested that:
1) The advantages of "binary XML" are less than a naive view claims.
Zip-style data compression is better at saving bytes, and a good parser
is surprisingly efficient -- even more so if it leverages some of the
work IBM has done on using schema information to create optimized
parsers. (A schema-validating parser can actually be _faster_ than a
non-validating parser!)
2) No two parties agree on exactly which competing needs "binary XML"
needs to be optimized for.
3) Anyone who really worries about performance winds up using XML as a
portability/interchange representation, and switching to a more
specialized data representation within their tools, with code and data
tailored to each other. That's true even if you're doing general XML
infoset storage and manipulation; you decide in advance which needs are
most important and optimize for them.
There is still an effort in progress to see if some common compromise is
possible... but frankly I expect it to fail. XML's textual
representation -- the fact that it is accessible to the "desperate perl
hacker" with minimal investment in education, and that a moderately
clueful student can implement a moderately efficient system moderately
quickly -- really does turn out to be a key strength.
Don't take my word for it. Maybe someone out there really does have a
new insight that will make this concept worthwhile. But personally, I
recommend that you take a step back, ask what problems you're really
trying to solve, and think hard about whether binary XML -- especially
in its current unstable forms -- is seriously helpful or just a buzzword
and distraction.
--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry