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] Pushing all the buttons

[ Lists Home | Date Index | Thread Index ]

[Kevin Jones]
 >Obviously size is not the only issue, loading performance appears to be 
at least as
 >important to most people using binary infoset formats and gzip alone just 
increases
 >the receivers loading costs. There is a good paper linked from
 >http://citeseer.nj.nec.com/cheney01compressing.html that discusses why
 >compressing binary infoset representations can yield better compression
 >results than gzip of XML.

In situations where load time is the critical issue, then using native 
object marshalling with
lossless ToXML/FromXML utilities (item 3) on my list above, is the way to 
go in my opinion.

Example. A very high volume wireless portal product that we built in 
Propylon uses wall to wall XML.
Users, devices, transport protocols,  locations, you name it - are all XML 
instances.

For every HTTP request, about six XML files need to be parsed, turned into 
native objects and then
some of them need to be written back out again.

When I first built the thing it took about 5 minutes to do a single HTTP 
request/response. We got
this down to something more than adequate without resorting to knee-jerk 
removal of the textual
nature of the XML underfoot.

The way we did it was analagous to the way Python compiles source files 
into bytecode.

In the system, each XML File Loader/Saver is responsible for maintaining a 
native object serialisation for
each XML instance (in my case, Python/Jython pickles).

At load time, the marshalled object is read *if* the XML has not changed.
If the XML has changed, it is loaded and a new marshalled object is created.
At save time, the marshalled object is created first, then the plain text XML.

It works a treat and is fast enough to work within the tight confines of a HTTP
request/response pair thread on a heavily loaded portal.

No binary XML required, just a wee bit of thought about loading/saving XML and
prudent use of native object marshalling to get the best of both worlds.

Sometimes, I do the same by picking Pyxie trees. Also works a treat. Would work
just fine with DOM's etc.

With a binary XML you would still need to map to your native object model.
The whole perceived need for a binary XML notation goes away if we just
ensure that any object models - be they DOMs or application
specific - come with ToXML/FromXML utilities.

The benefits of that binary thing in the middle being
platform/product/application neutral are overstated in my opinion.

Sean

http://seanmcgrath.blogspot.com






 

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

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