[
Lists Home |
Date Index |
Thread Index
]
> First, you have to realize that most binary proposals to not in fact
> posit that.
Sure. Let's further constrain ourselves to the kind of "binary XML"
that the W3C would work on. Since, after all, we're talking about the
XML Binary Characterization WG, it makes sense to leave out other
efforts (e.g., X.fws by Sun, over at ISO).
> 1. Patents are beginning to invade this space, closing off
> interoperability and open software.
This would not be an issue.
> 2. The data that's transmitted in this binary format is less inspectable
> than data in the regular XML format.
Yes, while it's in binary. The importance of this issue isn't clear to
me, however. For example, you can't readily inspect an XML document
after it's been eaten by a DOM or Java object, or being processed by a
C# reader. You have to call explicit API's.
So the only time inspectable is an issue is when it's setting on a disk,
or when it's in transit over the network. As I said, the importance of
that, vs having cell-phones or military equipment be a part of the XML
universe is TBD.
> 3. Software vendors will publish tools that only consume the binary
> data; and therefore systems will refuse to accept the textual data.
That is possible. Such systems will either need a shim that does the
XML to binary conversion, or they will probably fail to gain general
market acceptance.
> 4. Binary parsers often forgo well-formedness checks such as name
> characters that textual parsers make. They incorrectly assume that
> nobody can or will inject broken data into the system.
You mean like expat did up until the billion laughs attack? :) I don't
see anything in binary a priori that makes it more susceptible in this
regard.
> Anyway, that's just four issues. But really this is a moot point. The
> vast majority of proposals do not provide bijections between real XML
> and their custom format.
I am not concerned about the vast majority of proposals. I am
interested in what the W3C might do, and I do not expect any possible
binary format to give up the "round trip" capability.
> Just about anything more XML aware than these, though, is unlikely to be
> bijective.
Baloney. Or, if you prefer, FUD.
It seems to me that of your four issues only one is valid.
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
|
