Re: [xsl] Speed difference attributes vs elements

Subject: Re: [xsl] Speed difference attributes vs elements
From: Mukul Gandhi <gandhi.mukul@xxxxxxxxx>
Date: Wed, 28 Sep 2005 19:12:02 +0530
Hi Cas,
   I think if there is a associative relationship between things, keep
the relationship as attributes in XML. And if the relationship is
composition or aggregation, keep the information as child elements in
XML. We can take this as a rough guideline..

Regards,
Mukul

On 9/26/05, Cas Tuyn <Cas.Tuyn@xxxxxxxx> wrote:
> Hi,
>
> I'm designing a new schema and have googled extensively for reasons to
> use elements or attributes to store info. The general opinion is that
> removing attributes leaves the content intact. So <book title="..."> is
> wrong and <book language="..."> is OK.
>
> With that rule in mind I designed a diagnostic schema that contains
> configuration information like which models and software releases
> experience a problem, as follows:
>
> <problem
>    models="long list"
>    software_releases="long list"
>  >
>
> instead of
>
> <problem>
>    <models>
>       <model>...</model>    (many times)
>    </models>
>    <software_releases>
>       <rel>...</rel>    (many times)
>    </software_releases>
> </problem>
>
> Now my model list can be up to 50 words of 10 characters each, and my
> software release list can be up to 20 3-digit releases like 3.2.1.
>
> Q1: Is there a performance penalty for either design?
> Q2: Does the answer depend on the XSLT processor?
>
> At the moment we are batch-transforming XML to HTML using Sablotron, but
> in the future we want to serve XML to the browser (Firefox and IE6
> currently).
>
> Regards,
>
> Cas
>
>
> --
> The information contained in this communication and any attachments is
confidential and may be privileged, and is for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify the sender
immediately by replying to this message and destroy all copies of this message
and any attachments. ASML is neither liable for the proper and complete
transmission of the information contained in this communication, nor for any
delay in its receipt.

Current Thread