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] XML Binary Characterization WG public list availabl e

[ Lists Home | Date Index | Thread Index ]

No disagreement with that assessment.  Robin's 
announcement asked that flamefests be held here 
and not on that list, but the list asked for 
discussions that will inevitably lead to flamefests. 
I'd not seen the term 'optimized XML' before and 
wondered how that related to 'binary', a term 
I am familiar with.

This is clearly an alternative format to XML 
as we know it.  I won't argue the merits for 
that here today.  The case is made in some 
domains for 'alternatives' but as we've repeated 
here several times, no one knows if that 
really is a plurality.


From: Michael Champion [mailto:mc@xegesis.org]

On Apr 9, 2004, at 9:18 AM, Bullard, Claude L (Len) wrote:

> This will open Pandora's Box.
> Some applications do need a binary, such as X3D,
> and are moving smartly to design one.  Terms such
> as 'optimized XML' scare me.

Pandora's box was opened in 1997.  XML 1.0 is optimized for SGML 
compatibility, and that turns out to be a decent compromise between 
human readability and machine processability for a lot of common use 
cases. All sorts of other use cases might be optimized: Wiki-like 
markup languages are optimized for human editability; there are XML 
serializations that are optimized to save space, (see  
http://xml.coverpages.org/xmlAndCompression.html) and there are XML 
serializations that are optimized to be quickly parseable (e.g. 
http://www.ximpleware.com/).  XML has reached a point in it's evolution 
where people with some of these use cases are wondering whether XML's 
non-optimality for one thing or another outweighs the very real 
benefits, and are trying to figure out how to refactor things to get 
most of XML's benefits with fewer of its costs.

My experience is very different from Elliotte Rusty Harold's -- I am 
*frequently* asked  to help sort out the tradeoff between  XML's 
standardization, loose coupling, etc. and the very real overheads it 
imposes... Indeed at this very moment I should be writing up a 
rationale for why XML makes sense for a particular prospect's 
application even though performance will suffer (or more hardware 
required).   Others, e.g. with wireless applications, choke on the 
reality that XML is a "fat" format, GPRS has serious latency issues 
that are exacerbated when XML is in the picture, and exploiting a 
wireless device's processor for conventional compression algorithms 
just drains the battery all the faster.

The question is whether there is one, or a manageable number greater 
than one, alternative format(s) that can cover a signficant range of 
use cases and still parse into the XML Infoset.  "Optimized" is the 
right word, IMHO, because it forces one to ask "optimized for what?", 
and that forces one to measure time and space overheads in real use 
cases with real code. That's my understanding of what the "binary 
characterization WG" is doing, and I think it's a great idea to do this 
collectively and publicly so that further work can proceed from a 
common knowledge base.


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

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