[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML / HTML Transport size

• To: <xml-dev@l...>
• Subject: Re: XML / HTML Transport size
• From: "Rick Jelliffe" <ricko@a...>
• Date: Tue, 19 Nov 2002 11:47:28 +1100
• References: <MHEKJACEHBDICMHDOHNDAEKBCIAA.Gerben@C...> <3DD8F3F5.2020609@e...> <oprf2avxw3ezizxn@localhost> <3DD90F21.4040404@e...>

From: "Robin Berjon" <robin.berjon@e...>


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

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.   

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.  

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--i.e., that for inhouse, tightly-coupled or controlled
uses, WF processing of XML is not appropriate. 

I have just spent the best part of a year working on various lightweight partial 
parsers used in our products, and I have never seen anything to suggest that
parsing causes performance problems: object creation and architecture
are the overheads.  For example, if you want to route a compressed
file using meta data in a header, and efficiency is important, don't
uncompress the whole file, just as much as you need. 

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

Yep.

Cheers
Rick Jelliffe

• Follow-Ups:
  • Re: XML / HTML Transport size
    • From: Robin Berjon <robin.berjon@e...>

• References:
  • XML / HTML Transport size
    • From: "Gerben Rampaart (Casnet Mechelen)" <Gerben@C...>
  • Re: XML / HTML Transport size
    • From: Robin Berjon <robin.berjon@e...>
  • Re: XML / HTML Transport size
    • From: Mike Champion <mc@x...>
  • Re: XML / HTML Transport size
    • From: Robin Berjon <robin.berjon@e...>

• Prev by Date: RE: OT - Re: The perils of P18S (was Re: Why RDF is hard )
• Next by Date: Re: RDF for unstructured databases, RDF for axiomatic
• Previous by thread: Re: XML / HTML Transport size
• Next by thread: Re: XML / HTML Transport size
• Index(es):
  • Date
  • Thread