xml-dev - RE: standard compressed XML format?

["Simon St.Laurent" <simonstl@simonstl.com>]

At 07:24 PM 3/16/00 -0500, Schneider,John C. wrote:
>	I work for an independent not-for-profit government lab and am very
>interested in placing the encoding concept we devised into the public domain
>as one input to an XML standard.  This would accelerate the development of a
>capability my customer's need and result in a less costly, higher quality
>product than if they contracted someone to develop it as a proprietary
>capability.  As an open standard, it would also increase the likelihood of
>it integrating well with the other tools they already use.  If a W3C WG
>existed to address this issue with the relevant IPR disclaimers in place,
>I'd love to share the concept.  I'm hesitant to share it in this forum for
>fear that a vendor would attempt to gain proprietary control of it.  [IMHO,
>the concepts are actually quite simple and I'm surprised I haven't seen some
>incarnation of them yet].

Well, maybe it'll shock some people on XML-Dev, but I'd be happy to see the
W3C address this issue. I haven't heard anyone from there leap forward with
"we really should be working on this", but it's early in the discussion
yet.  With any luck, they're listening, hopefully even intrigued.  It could
also be an IETF kind of issue - those lines seem to keep moving.

I'm coming to this issue from a combination of my work on XML MIME types on
a rather contentious IETF mailing list and discussions I keep hearing on
various other even more contentious XML and Web development lists.  The
MIME type discussion feeds my interest in the infrastructure problem, while
the more immediate 'how big are these SVG files going to be anyway?'
questions keep popping up and slapping me in the face.  I'm tired of trying
to explain to designers why SVG has to be so big to be so great, and at the
same time I'd also like to see verbosity removed as an issue from SVG's
design.

>	One of the concepts we devised fits the description you give below and,
>with sufficient tweaking, could form the basis of an efficient XML encoding
>scheme.  The algorithm does not rely on character redundancy and, as such,
>works equally well for small information objects that tend to get larger
>using algorithms like zip.  In addition, it's design permits it to be
>read/written directly from an appropriately modified DOM implementation
>instead of incurring the cost of a separate compression/decompression step.

This would help meet my criteria of such a thing being invisible, or at
least transparent.  Nice stuff!

It sounds exciting to me, and I'm very glad to hear I'm not the only one
thinking about this stuff!  From the last few posts, it's clear that lots
of folks are pondering how to reduce XML's verbosity, in lots of different
ways.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************