[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: An unclear point with W3C XML 1.0 Specification

• To: Ronald Bourret <rpbourret@r...>
• Subject: Re: An unclear point with W3C XML 1.0 Specification
• From: david.lyon@c...
• Date: Thu, 6 Jan 2005 20:33:34 +1100
• Cc: xml-dev@l...
• In-reply-to: <41DCDC1C.7090906@r...>
• References: <20050106042113.CF2B828C04D@m...> <1104986792.41dcc2a835b87@65.39.203.11> <41DCDC1C.7090906@r...>
• User-agent: Internet Messaging Program (IMP) 3.2.6

Hi Ron,

Yes, it may appear a little strange at first. But there
is logic behind it all.

What you have shown are two good examples of traditional
XML 1.0. No problems with those at all. Bog standard.

The answer to the question is that when multiplied out
a few tens of thousands of times, every extra character
and every parsing ambiguouity can slow the process of digesting
the data down, dramatically.

There isn't much difference between:

    <product_item>
      <part_description>3 1/2" Spanner</part_description>
    </product_item>

and:

    <product_item>
      part_description&="3 1/2^" Spanner"
    </product_item>

Counted, this gives 51 characters on the first part description
style, and 35 on the second according to my counting style (which
can make mistakes).

Add in the two tags to be fair, this gives (51+29)=80 characters, and
(35+29)=64 characters per inventory item.

But with 40,000 line items, an easily achievable inventory pricelist,
we get a saving of 760,000 bytes, or about 80% of the size of the
xml 1.0.

But make it more realistic, add in some more fields:

    <product_item>
      <part_description>3 1/2" Spanner</part_description>
      <sell_price>18</sell_price>
      <cost_price>15.50</cost_price>
      <InStock>False</InStock>
      <Arrival_Date>2005-02-15</Arrival_Date>
    </product_item>

and:

    <product_item>
      part_description&="3 1/2^" Spanner"
      sell_price$=18
      cost_price$=15.50
      InStock?=False
      Arrival_Date@=2005-02-15
    </product_item>

Style 1, 51+27+30+24+39+(29)=200
Style 2, 35+14+17+14+24+(29)=133

Once again, multiply by 40,000 items and the respective
file sizes are approximately:

Style 2 = 5320000 bytes
Style 1 = 8000000 bytes

In XML 1.0, we have a larger file with no type information
and in the computergrid format, we have type information as
well as a saving of around 35% or 2,680,000 bytes.

I guess they are the benefits of being strange as best as I
can explain it. I will stick to what I have got but thanks
for your comments anyway.

Best Regards

David



----------------------------------------------------------------

• Follow-Ups:
  • Re: An unclear point with W3C XML 1.0 Specification
    • From: Bob Foster <bob@o...>
  • Re: An unclear point with W3C XML 1.0 Specification
    • From: Elliotte Harold <elharo@m...>
  • RE: An unclear point with W3C XML 1.0 Specification
    • From: "Michael Kay" <mike@s...>

• References:
  • An unclear point with W3C XML 1.0 Specification
    • From: "Collin Hsu" <collin@w...>
  • Re: An unclear point with W3C XML 1.0 Specification
    • From: david.lyon@c...
  • Re: An unclear point with W3C XML 1.0 Specification
    • From: Ronald Bourret <rpbourret@r...>

• Prev by Date: Re: An unclear point with W3C XML 1.0 Specification
• Next by Date: Re: The Airplane Example (was Re: StreamingXML)
• Previous by thread: Re: An unclear point with W3C XML 1.0 Specification
• Next by thread: RE: An unclear point with W3C XML 1.0 Specification
• Index(es):
  • Date
  • Thread