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 ]

Rick Jelliffe wrote:
> From: "Robin Berjon" <robin.berjon@expway.fr>
>>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). 
> 
> I kinda don't get it.  XML is a web technology, and HTTP allows compression.
> If people don't turn on compression on their webservers, that is their problem.
> If people want more efficiency, they could write serializers that generate
> compressed data directly, and the reverse at the parser end. 

Hmmm, well I don't know what you're not getting because what you're describing 
is exactly what we're doing :) When HTTP is used BiM can be used as a simple 
content coding. When the XML is not already in textual form (but instead in SAX, 
DOM, etc) we write serializers that generate binary infosets directly.

I was simply pointing out the fact that XML's verbosity is an acknowledged 
problem in a number of spaces, that it is perceived to have sufficiently 
interesting features to look into using it nevertheless, and that solutions that 
address the vrebosity exist.

> I still have never seen any numbers that suggest that the cost of parsing
> XML is not trivial compared to the cost of object creation.

On what platforms have you seen the numbers you did see?

> Especially when it is quite possible to write light-weight parsers that omit
> most WF checks.   If you can trust that your data is WF, you don't *need* to
> check for name-correctness, for example. You can just tokenize
> using space separators: this is appropriate for tightly-coupled systems or 
> routing systems, for example.  

Yes, but unfortunately that's not always the case as some systems have a wide 
variety of content creators.

> XML was designed for this: perhaps the emphasis on Draconian error-handling 
> for WF and validity has obscured that XML was designed also to be useful for 
> the Desparate Perl Hacker

True, but for that to be generally admitted we need to wait for Perl to take 
over the world ;)

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