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] XML-enabled databases, XQuery APIs

[ 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.


>> 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"

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.



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

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