[
Lists Home |
Date Index |
Thread Index
]
On Sat, Sep 20, 2003 at 12:33:26PM -0700, Mike Champion wrote:
> [Quoting from Bray, St. Laurent, and de Hora ...]
>
>>>>Pelegri-Llopart said "The main point here is there is almost
>>>> is almost an order of magnitude between straightforward Web
>>>> services using XML encoding and an implementation that takes
>>>> care of binary encoding."
> Is anyone disagreeing with that assertion? I hear it from a lot
> of apparently independent sources.
> Presumably we'll see data at the "Binary Infoset
> Serialization" workshop next week.
I don't think I'd be giving away any secrets if I said you can
reasonably expect Sun to present their paper and measurments :-)
As far as I can tell, people *are* using binary representations
of XML in various ways, for various purposes, already. They aren't
going to stop just because W3C doesn't tell them how to do it, or
just because xml-dev doesn't like it :-)
So the question as I see it becomes, is there a way to specify a
binary format, or binary interfhange framework of some kind, in
such a way that a significant majority of the people currently
using binary formats agree to implement and use it?
If so, we are possibly increasing interoperability, and should
investigate it further.
If not, people may need to focus on generic compression combined
(in some cases) with better parsers.
Mike Champion also asked,
> is the more-or-less-indisputable fact that one can get an XML
> distributed app up and running much faster than a proprietary-format
> distributed app due to the standards-ness of XML or the text-ness
> of XML?
I think it's a combination...
* widespread support in tools and toolkits
* standardised in a way that makes most obvious errors be fatal,
so that syntactic variants are pretty much non-starters
* over-hyped in its infancy, which gave XML lots of momentum
The textness helped people write the tools, and helps with the
documents, I agree. However, examples of non-text formats include
* Microsoft Office save files, widely used becuase of market dominance.
A text-based alternative, RTF, has interoperability problems, possibly
because the standard wasn't formal enuogh and there were no conformnce
tests, but I don't know if that's true.
* TCP/IP network packets... tcp/ip took off because of freely
available toolkits, at a time when the major competitor from ISO
was expensive, and yuo even had to pay for the specifications,
which were large and complex.
* most image formats, because of compactness -- although the "pbm"
and "xpm" text-based formats are widely used because they are
amenable to Unix pipelines with many different tools, e.g. awk.
RTF and HTML are both examples where standardisation was difficult
because competing vendors were trying to innovate by introducing
features that required format-level changes.
One answer is to move to punt features to a higher layer -- e.g. a
document formatter is unlikely to request changes to the XML spec,
but may want changes to XSL/FO or CSS. This sounds at first as if
it doesn't help, but it does help, because not all users of XML are
using it for the same things, so changes in one area needn't affect
users in another... and the layering means that documents need not
be changed directly so often.
In the same way, I think any binary XML interchange format needs to
be exactly that - a layer that's used to transmit, store, process
and interchange information without directy affecting higher layers
of processing.
I admit I am still not certain it's possible, but then, that's
why I think having a workshop might be useful :-)
> As best I know, the big win for truly binary XML
> serializations is in avoiding the overhead of the
> Unicode-encoded text to UCS-character translation.
For some people, avoiding parsing at all can be a win --
e.g. transmitting a "tree".
> Of course, the big downside for all alternative
> serializations is that they seriously limit
> interoperability. But remember that the whole POINT
> of this "efficient alternate serialization of the
> Infoset" stuff is to buy performance at the cost of
> some interoperability, to be used in specifically in
> situations where the pain of worse performance is
> worse than the pain of lower interoperability. And the
> whole point of standardizing a small number of
> alternative serializations would be to get some of
> that interoperability back.
Agreed completely.
Liam
--
Liam Quin, W3C XML Activity Lead, liam@w3.org, http://www.w3.org/People/Quin/
Ankh's list of IRC clients: http://www.valinor.sorcery.net/clients/
http://www.holoweb.net/~liam/ -- Tread barefoot on the land
|
