[
Lists Home |
Date Index |
Thread Index
]
- From: Tyler Baker <tyler@infinet.com>
- To: "Hunter, David" <dhunter@Mobility.com>
- Date: Sun, 26 Sep 1999 03:49:07 -0400
"Hunter, David" wrote:
> From: Tyler Baker [mailto:tyler@infinet.com]
> Sent: Tuesday, September 21, 1999 8:45 PM
>
> > Several compression formats would in effect eliminate any
> > significant difference between using
> > elements or attributes. One compression format that comes to
> > mind is LZW, but it is too bad
> > that it is patented by the people "Who eat, sleep, and drink
> > this stuff" (-:
>
> I'm not sure that we can dismiss this argument on the basis of compression.
> The "attributes only" version was only about 65% the size of the elements
> version; with larger element names and larger more realistic XML examples, I
> can easily see this coming closer to 50% difference. In fact, I'm working
> on an application right now where we have an object model to capture all of
> our information, which serializes itself to XML. We're using all elements
> for our XML, no attributes. I took some typical XML and it was 4.68KB,
> whereas if I go through the XML and change all of the elements to
> attributes, with the only elements now being child objects, my XML size goes
> down to 2.64KB, which is very close to the 50% mark indeed. So even if you
> compress the files, the attribute version will be able to compress to 50%
> smaller than the other file. Again, 2KB isn't a lot, but if we're talking
> megabytes in size, 50% is a lot.
Well if you think of each element name or attribute name mapping to a one or two byte word
symbol, then the difference between an attribute name and two element names is in effect one
byte when compressed. Even with very, very, very large documents you should get excellent
compression with XML. A simple huffman tree implementation would suffice to get you some good
compression across the wire. I would try using some compression algorithm that is ideal for
large numbers of repeating words and see what happens.
XML is not exactly what I would think of as the ideal format for very large files that need to
be accessed randomly. XML is simple, easy to use, human readable (except when you deal with
namespaces), and easier for other programmers to work with since they don't have to use your
API's to process your data (they just need an XML parser and a standard API like SAX).
Tyler
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|