Re: [xsl] Speed difference attributes vs elements

Subject: Re: [xsl] Speed difference attributes vs elements
From: omprakash.v@xxxxxxxxxxxxx
Date: Wed, 28 Sep 2005 19:31:00 +0530
         Iam presently working on a JSF like framework that generates a UI
from XML and have had to decide between attributes and elements quite
often. Iam using DOM and owing to a limitation of DOM or not Iam not sure,
I have to specify an attribute that specifies whether to descend into child
nodes or not etc when 2 elements of the same name have different structure.
The problem is there  with attributes as well.

<row >
<col edit="yes"/>
<col edit="no"/>
<col edit="yes"/>

For eg. In the above structure, every 'col' needs to have an edit attribute
whether required or not as otherwise it throws a NPE. Im sure this can be
avoided with checks to see if the attribute exists first but  I feel that's

Just thought Id share my experience.


                      Mukul Gandhi                                                                                              
                      <gandhi.mukul@gm         To:      xsl-list@xxxxxxxxxxxxxxxxxxxxxx                                         
            >                 cc:      (bcc: omprakash.v/Polaris)                                              
                                               Subject: Re: [xsl] Speed difference attributes vs elements                       
                      09/28/2005 07:12                                                                                          
                      Please respond                                                                                            
                      to xsl-list                                                                                               

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..


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.

This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. 
If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately.
You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit Us at

Current Thread