Is there anyone working on a binary version of XML?

[Stephen D. Williams]

Can you make available what you are working on?  That was the reason for my starting
this thread in the first place.

I'm happy to build upon or learn from existing designs...  It appears you have had many of the
same conclusions that I have.  Let's pool our design features and make something that can be
used as a common
solution

Thanks
sdw

"Anders W. Tell" wrote:

> Rick Jelliffe wrote:
>
> > I have done a few tests on how much compacter forms of XML (e.g.
> > shortrefs) impact arrival characteristics of document packet-groups
> > under TCP/IP compared to compression.  If your packet size is small, and
> > you really need to get at data in the first packet (so that you can
> > piggy back request for auto-linked resources in with the ACK for the
> > first packet group), then more compact forms of markup may make a
> > difference. But in general, compression is more effective. (It also
> > depends on where the bottlenecks are in your data path.)
>
> It seems that there are more use-cases which should benefit from having a
> compressed or a binary format.
>
> I made some tests using following XML data.
> <xmltest>
>    <xi4 value="0" name="VALUE"/>
>    <xi4 value="32768" name="VALUE"/>
>     ...
> </xmltest>
>
> The resulting sizes was:
> XML       602830     (Standard XML text)
> FML       131143     (Fast ML, a binary ml that Im working on)
> XML.gz    75528      (gzip'ed XML text using -9 as compression rate)
> FML.gz     20886     (gzip'ed Fast ML using -9 as  compression rate)
>
> The facinating result here is the dramatic reduction in size obtained by first
> converting to FML and the GZIP the markup stream.
>
> > And select your element and attribute
> > names so that their length is inverse to their frequency, as much as
> > possible: so use "a:s" not "abracadabra:shazamarama" (you may even make
> > two versions of your DTD: an authoring one and a transmission one.) One
> > pof the main bottleneck on many SOHO systems is the modem speed:
> > reducing the end-to-end character count means fewer packets, and more
> > data arrives earlier, so more auto-links are followed earlier.
>
> On the other hand there is a big drawback  using "manual tag compression"
> which is Readability.
>
> /Anders
> --
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> /  Financial Toolsmiths AB  /
> /  Anders W. Tell           /
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

--
OptimaLogic - Finding Optimal Solutions     Web/Crypto/OO/Unix/Comm/Video/DBMS
sdw at lig.net   Stephen D. Williams  Senior Consultant/Architect   http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 5Jan1999



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)