Lists Home |
Date Index |
> (a) the longer the tags or the shorter the data elements, the
> less sense it makes to transport the data via XML and (b) the shorter the
> tags or the longer the data elements, the more sense it makes to
> the data via XML. Anyone disagree?
Another design philosophy I've heard is something along the lines of:
"Design to preserve as much information as possible. When performance
issues are encountered evaluate specific solutions to optimizing." These
solutions may involve shortening markup or other approaches, depending on
what best suites the specific optimization.
I first heard this in relation to normalizing relational DBs but I think
it applies to XML markup as well?
> -----Original Message-----
> From: Peter Hunsberger [mailto:email@example.com]
> Sent: Monday, December 06, 2004 5:24 PM
> To: Stephen E. Beller
> Cc: firstname.lastname@example.org
> Subject: Re: [xml-dev] Data streams
> On Mon, 06 Dec 2004 16:35:48 -0500, Stephen E. Beller <email@example.com>
>> In consideration of Elliotte's reply, I went back and looked at the XML
>> Excel generated. Here's what I found ...
>> Every one of the XML data elements had this tagging structure:
>> <Cell><Data ss:Type="Number">1</Data></Cell>
>> In contrast, the CSV had this structure: 1,
>> That's a 50 characters to 1 difference for each data element.
>> I doubt that all those XML tags are necessary if you're rendering the
>> in something other than a spreadsheet. But if you are planning to use a
>> spreadsheet, then the 50 to 1 ratio is valid, it seems to me.
> Use the number 10, now the difference is 51 to 2 or a ratio of ~26 to
> 1. Use the number 100 and the ratio is 52 to 3 or ~17 to 1. Six
> digits? 56 to 6 or ~10 to 1. Now add multiple columns of data (as any
> realistic example would do) and the ratio falls even farther.
>> So, this benchmark test still points to a huge difference in file size
>> in unzipping and parsing time when you compare a large data array in CSV
>> compared to XML.
> Maybe, maybe not, the bench mark needs to be more realistic before you
> draw any conclusions about "huge".