[
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.
len
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.
|
