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 / HTML Transport size

[ Lists Home | Date Index | Thread Index ]

Mike Champion wrote:
> On Mon, 18 Nov 2002 15:06:45 +0100, Robin Berjon 
> <robin.berjon@expway.fr> wrote:
>> is it because I've been doing research in binary XML for the past few 
>> months or do these questions seem to occur more frequently than they 
>> used to? From what I gathered from the recent conferences I've been to 
>> it may be a result of the boom of web services, but I'm unsure I have 
>> sufficient data to assert that with certainty.
> I have seen the same thing.  Perhaps it's because XML has been driven
> so deeply into the infrastructure.  In an XML application, the bandwidth
> costs and parsing overhead are generally trivial compared to the other
> processing requirements and the benefits that the network effect offers.
> In XML infrastructure that does NOTHING BUT move around and parse/serialize
> XML, these overheads become significant bottlenecks.  So while "XML is 
> inefficient" is an antipattern at the application level, it's an 
> increasingly obvious truth at the infrastructure level.

That's partly true, but I'm not sure it's as clearly cut. Obviously the 
typical case in which an infrastructure does nothing more than move 
around some XML describes SOAP pretty well (I guess that's why the WG 
clearly specified that the wire format needn't be XML).

However if you look at the broadcast industry, there are cases in which 
the application does a lot more than just throw some XML around and yet 
using textual XML would be a serious hog (in fact impossible). The 
reason for this is either that you're sending a lot of metadata (eg 
describing many of your video frames) or because even though you may not 
have all that much data, you have to send it continuously (eg sending TV 
guide information, localized overlay data such as sport results, song 
titles for the radio... The TV or radio has no way to request the data 
because the broadcast is one-way, yet someone tuning in at any random 
moment needs to have that information. Thus, you're condemned to 
continuously send it.)

Thus I think it's not just XML being driven into the infrastructure 
(though you're imho right that it's a big part of it), but XML being 
driven into pretty much everywhere, including places no one ever dreamt 
it would go. The reason for this is that people are finding more value 
in having as much of an XML pipeline as possible, even if it means 
they'll have to deal with issues they wouldn't have had otherwise. They 
seem to be considering that having to solve the inefficiency is less of 
a problem than having to take care of an ad hoc binary format.

> [Ducking the inevitable flames ... sorry folks, I followed the dogma
> as long as I could .... ]

Flames? What flames? :-) Seriously though, I'm not sure that this is as 
anti-dogma as it used to be. The textuality of XML is and always will be 
fundamental. Binary XML is no more than an encoding for XML. Realising 
that is the key as I don't think you'll find someone that will tell you 
with a straight face that they don't gzip large XML documents because it 
ruins the textuality of the content.

Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


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

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