OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xml-bin] RE: Another binary XML approach



On Thu, 12 Apr 2001, Bullard, Claude L (Len) wrote:

> >embedded devices, high-volume transactions, efficiency, compression ratio,
> 
> No proof has been offered that the solutions for items one and two converge 
> in the qualities of items three and four.  Anecdotal evidence has been 
> offered from developers that the time spent in parsing and the  
> compression ratio gained does not warrant the effort.  

That depends a lot on what you're doing. Most people here are doing stuff
like database -XML-> XSLT -XHTML-> Client, where the stages in the
pipeline do lots of work and the snippets of data aren't that big anyway.

However, try designing a firewall for SOAP requests that needs to do some
checking in the request before forwarding. A seekable binary format would
enable the relevant XPath queries to run maybe a hundred times as fast for
messages of a few hundred elements, and maybe more if you get good gains
from native integer representation. Which would mean that your firewall
engine (not necessarily the bottleneck, I agree - except on gigabit
Ethernet!)  could process a hundred tims as many messages per second for
the same price.

Look at the thought going into the design of IPv6 headers. They carefully
selected the fields that routers need to access the most and made them the
most easily accessible by ordering the fields so as to align them better
in memory. Which is vital for the economical implementation of gigabit
routers. Can we honestly say that XML does not need to be usable in such
environments? What would we suggest people use instead when they come to
our doors asking "You're the new standard for data representation, aren't
you? I want to interoperate"? Do we say "No, we're only for this domain
over here - text-oriented data processing where you don't need to seek
into things much or be implementable in hardware efficiently"?

> to take this offlist, but at some point XML-Dev list members 
> might reasonably expect results of the discussions to be 
> brought back for consideration.  

Yep, definitely.

> Len

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software