[
Lists Home |
Date Index |
Thread Index
]
The problem is difficult, but it is not impossible to solve. Many
people have come up with pieces of the solution and some of us think we
see a solution package that is flexible enough to handle such disparate
cases.
Everyone understands that XML and XML+gzip are suitable for different,
overlapping use cases. In a sense, document analysis-based compression
is an optional feature of "XML with optional gzip". Similarly, it is
possible for other methods to be used in an incremental way, possibly
changing in mix on an element by element basis. In this way, you can
unify something obvious like a TLV (token, length, value,or for elements
and attributes, token, name, length, value) with what I generalize as
"externalization" of structure and metadata for something similar to
ASN.1+PER (or XML Schema->ASN.1->PER+). (Note that I am not an advocate
of ASN.1 anything and I'm not specifically an adovcate of XML Schema for
the One True externalization method.) TLV, or rather TNLV, is
self-describing and can be completely equivalent to XML 1.x text
encoding. A completely externalized, and therefore able to be most
compact, mode is less XML-like unless you consider the out of band "XML
completing" metadata/metastructure as a kind of compression of the
instance. This seems like a unifying concept and makes it reasonable to
think that you could have a format that supports an arbitrary mix as
needed and maintain equivalence to text-based XML.
I strongly believe that we need the ability to have a completely
self-contained instance with equivalence to XML 1.x, but I also see a
clean way to also support various externalization and compactness
techniques to approach absolute compactness when desired. I've publicly
mentioned the idea of a metastructure descriptor instance as a new take
on externalization. I'll publish more about it soon.
sdw
Michael Champion wrote:
> ...
>
>
>I do think that the burden of proof is on those who would break things
>that actually work without compelling evidence that would make us much
>better off down the road. To be fair to the XBC people, until we
>really and truly see XML 1.0 working for the use cases that they laid
>out, I'm planning to keep an open mind about how to make the XML
>family of technologies work better for all the users and potential
>users. For now, various "binary XML" technologies definitely have
>their place in specialized domains and scenarios, but nobody has come
>anywhere near demonstrating that a "binary XML" standard would do more
>good than harm. For that matter, I don't see how it is plausible to
>believe that a consensus can be reached on a format that trades off
>the needs of the wireless people for cheap compression and the needs
>of the enterprise messaging people for processing speed.
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
|
