[
Lists Home |
Date Index |
Thread Index
]
From: Michael Champion [mailto:michaelc.champion@gmail.com]
>> Hmm. So, a trivial binary standard is the sweet spot for
>> standardization;
>I don't follow, the quoted piece says "more significant improvements
>can be otatined by adopting optimized stream based XML parsers."
Simple. The paper makes an argument (if not the case) that a
trivial binary (binarize the structure), does show improved
performance, does not tightly couple, and is trivial to
implement. More significant improvements in performance
are possible. So a binary standard for a trivial binary
might be worth having. Otherwise, the question I asked
when this all came up was if it is possible that one
binary fits all cases or if the performance metric is
serious enough for some XML applications that a separate
binary standard is worth having? In both, the answer is yes
based on the results of this paper.
Again: we will have binaries. Application developers are
already pursuing these and some outside the W3C as standards.
Will these aggregate by class (eg., can SVG benefit from
the binary for X3D)? Maybe. I think they will we if keep the
conversation going and that seems certain too.
Application binaries will continue
to emerge and they will have to be dealt with on the backend
such as storing the beasties in XML datatypes (or not). That the
W3C does or does not pursue a standardization effort is
more or less irrelevant to the certainty of that, just
the stability of the results overall.
>> compression is a separate issue needing further
>> study, and schema-based binarization tightly couples but is
>> possibly the best approach in the cases where high performance
>> is traded against tight coupling (effectively, a new media type)
>I strongly agree with both those points.
Righto.
>
>> The claim that view source is the reason for the growth of the
>> web is overhyped. Applications such as Flash became ubiquitous
>> without it and making it view sourceable now doesn't change the
>> historical facts.
>Interesting point I hadn't thought of before ... Still, my bottom
>line is that XML interop is not so much a function of it being
>textual, but it being the common denominator. That is problematic
>enough with the various encodings, the various schema languages, the
>substantial percentage of "XML" being processed by SOAP tools that
>don't recognize anything defined by a DTD, etc. The last thing we need
>is to double the number of permutations by adding another "common"
>format.
I don't disagree that commonality is the driver. SGMLers said long
ago that it is the fact of the agreement, not the precise technology,
that is the partying point. Contracts R Us. OTOH, we don't get to
say "no permutations". That's like the Viking king ordering the
tide not to rise and fall. We build around it, heck we make money
doing exactly that: customizations. If we can do that
with some common bits, all the better. What the paper seems to
say is that for a specific sharable binary standard, the trivial
one is the most sharable. That's all. Is it worth it? It doesn't
seem to be as odious as the more exotic approaches, and for some
short lifecycle docs, it may be useful. Meanwhile, also as predicted,
some common practices in the application binaries are being outed.
It may not be a great result for standards, but for programmers who
like Books Of Five Ring Patterns and Aunt Mary's Chicken Soup Recipes,
it's useful.
In short: not wasted effort. We're learning and coming to consensus.
len
|
