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

Re: XML Binary Characterization WG public list available


modulo xml
Elliotte Rusty Harold wrote:

>The target is an issue of debate. :-) Whether to optimize for space 
>or speed or both or one at the expense of the other is a big 
>splitting point. As with almost any optimization issue, a lot depends 
>on the very specific use case. Some people need space. Some need 
>speed. Sometimes you can get both. Sometimes doing either one is a 
>challenge. As usual regular XML makes a nice compromise position for 
>most use cases.
>
>Even space vs. speed depends on which space and speed. If network 
>bandwidth and speed are the issues, you can optimize both space and 
>speed very effectively with gzip. However, that pays a memory space 
>and CPU speed penalty on both ends of the transmission. Unlike a lot 
>of the custom proposals though, it's really easy to integrate into 
>the existing infrastructure, and to configure on a case-by-case 
>basis, especially if you're using HTTP. It has a much lower impact on 
>the overall environment than some of the custom binary proposals I've 
>seen.
>
>I think we may have this set of choices:
>
>1. Minimum size
>2. Maximum Speed
>3. Interoperable
>
>Pick any one. :-)
>
>  
>
I know we've had this discussion before, but let me ask again (nicely) - 
do you have fundamental objections to encodings of parsed XML data being 
transported, rather than the original text of documents? I'm thinking 
here in terms of formats such as XBIS, which AFAIK preserves (or at 
least, can be extended to preserve) all significant aspects of the 
document (significant as defined by the XML recommendation).

I've got an article coming out soon that runs comparisons of using XBIS, 
text, and gzip for transport of XML, looking at both size and speed. 
gzip delivers the best size in general, but also has a substantial speed 
penalty (as most people would expect). XBIS, on the other hand, provides 
a reasonable size reduction for most documents while also working much 
faster than either text or gzip. As for interoperability, the current 
XBIS implementation is written in Java but could easily be ported to 
other languages.

The big difference between these choices is that XBIS works with 
document parse event streams or equivalents. That certainly makes it 
more "invasive" than gzip, in that it requires a parsed representation 
of the document as a starting point. Is that necessarily a bad thing, 
though? If someone wants the original document text on the receiving end 
(modulo XML normalizations and such) they can easily get it.

  - Dennis

-- 
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA  425.885.7197



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.