Re: [binaryXML-30] Binary XML problem statement.

Elliotte Rusty Harold writes:

>> You could have created the right technology 
>> for your needs, without impacting anyone 
>> else who didn't need it. If it happened to 
>> look a lot like XML, no big deal.

I'm sympathetic to this argument (remember I said that I'm not particular 
at this point an advocate of binary XML).  However, I think the problem is 
a bit more subtle than the above might imply.

Yes, many of the advantages of XML come from not being all things to all 
people.    XML solves certain problems at moderate performance using 
text-based approaches.

What I think is more subtle is that my employer (and our competitors as 
far as I can tell) are trying to >unify< their application models.  The 
requirement to build binary serializations of XML is not primarily for 
applications that are independent of the traditional uses of XML, it's for 
the same or related applications.  Let's say you take in orders over the 
public network using traditional XML 1.0 documents.  The cost of character 
parsing is well justified by the known advantages of XML:  platform 
independence, self-description, tremendous availability of tools, etc. The 
problem is that once those orders get inside your organization you have to 
deal with large numbers of them.  You also have to build related 
applications (inventory perhaps) that have high-volume data processing 
requirements and that work on some of the same data that's in the orders. 
The point is that the high-volume applications are processing the same 
data that's coming in and out using traditional XML.  Even if they weren't 
directly processing the same data, it's quite compelling to have the same 
data models, same typing system, and where possible the same tools to 
operate on that data.  While it's true that the serializers and parsers 
are different, many other tools can be shared.  Most notably these include 
XML-aware databases, message queueing systems, modelling systems and to 
some degree data binding logic. 

Organizations such as IBM are committed to building high performance, high 
throughput applications using XML-compatible data models.  The only 
questions I see are whether this can best be achieved by optimizing the 
processing of traditional character serializations, whether there are 
times when binary serializations are a better tradeoff, and if so whether 
it's better on balance to standardize those representations.  I do agree 
that these are not easy tradeoffs and that the answers aren't immediately 
obvious.

So, for better or worse, these are key reasons why I see some push toward 
binary serializations of the XML model.  It's not just to build 
applications that are similar to XML but with higher performance, it's to 
get architectural synergy between the higher and lower performance design 
points.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Elliotte Rusty Harold <elharo@metalab.unc.edu>
Sent by: www-tag-request@w3.org
02/20/03 08:33 AM

 
        To:     Michael Mealling <michael@neonym.net>
        cc:     www-tag@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: [binaryXML-30] Binary XML problem statement.
Categories: 
 





At 7:47 AM -0500 2/20/03, Michael Mealling wrote:

>We looked at just about everything we could find. ASN.1 had its typical
>problems with encapsulation of unkown data types. Most of the other were
>to simplistic since we had to deal with things such as limited use of
>namespaces, encodings, schemas, etc. In other words, to handle the
>applications we're after we would've ended up creating something almost
>exactly like XML 1.0 in a binary form, just not called XML. That
>would've been a rather silly thing to do given perfectly reasonable
>solutions that already exist.

Actually, that's exactly what you should have done. You could have 
created the right technology for your needs, without impacting anyone 
else who didn't need it. If it happened to look a lot like XML, no 
big deal.

>I find it much more productive to start with something that solves all
>of the required problems except one and fix that rather than throw out a
>perfectly good solution and build one from scratch. For now I've decided
>to use WBXML since its about as good as you can get for our application.
>But if the W3C were to come up with a better or more accepted standard
>we would use that (if it solved the problem, of course. gzip doesn't).

The problem is that this so-called binary XML may save you time, but 
it pollutes the space for the rest of us. Maybe it's a net-gain for 
your project. It's a net loss for the community, though.

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Received on Thursday, 20 February 2003 09:48:54 UTC