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: "Binary XML" proposals




> At 12:22 PM 08/04/01 +0600, Danny Ayers wrote:
> > Ok, so if you put all this together,
> >what would you be gaining? Say an order or two of magnitude of speed?  (and
> >the same kind of gains for data storage)
> 
> The world may have a place for binary XML, but the above is not an
> argument for it.  First of all, an argument that unpacking a 
> binary format (particularly on a machine whose binaries are
> different and you have to bit-swizzle) is significantly faster than
> XML parsing a la expat or MSXML, needs to supported by actual 
> empirical data rather than by assertion.  And suppose, as a thought
> experiment, that this were true; if you were to speed up the
> XML parsing/generating part of an XML-using application, how much
> would that speed up the whole application?  You'd need to know 
> what proportion of its time it spends parsing/generating XML.  In
> some apps, this proportion is going to be very small.
> 
> As for the data storage volume issue, uh, isn't the world awash
> in admirable compression technology that works pretty well on
> most data formats, and particularly well on redundant textual
> stuff like XML?
> 
> Absent some good strong empirical evidence, neither processing
> nor storage cost are a priori arguments for going binary.

The ozone/XML project uses "binary XML" to transfer XML from the
clients to the database server and back through a socket connection. 
It is based on some work of Stefano Mazzocchi from Apache/Cocoon.
He called it 'XML compiler' and it compiles/compresses SAX events.

This approach is definitly faster than sending text-based XML through
the connection and reparse it on the other side, especially when
you've got many request with small amounts of XML to be transfered,
since the XML parser overhead is to much in this case.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    gerd@smb-tec.com     
SMB GmbH                                  http://www.smb-tec.com