Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: How would we get xml tags in xsl if we have same element name

From: Peter Flynn <peter.nosp@-.--------.-->
To: NULL
Date: 7/15/2007 12:39:00 AM

kamkaro wrote:
[...]
>> My question is still there, i have two 'filed' in my xml and
>> according to your reply " <xsl:template match="field">" how do i
>> know which field is calling ?? I do know if we have different
>> parent name so i can give path expression but if we have same
>> parents name so how would we do it, plz explain me.

I think what you are asking is, how to express the difference between 
two element types with the same name in different locations.

The answer is partly in design and partly in code.

The example you gave is a very good example of very bad design. It 
reproduces the visual (tabular) arrangement of the data with 
inconsistent identity. The best solution to this class of problem is 
always to get the XML redesigned so that it identifies the data 
correctly, but this is not always possible, especially when the data 
comes from a database which itself does not identify the data accurately.

To overcome this with code (eg in XSLT) you can use the environment of 
an element to identify the one you want, using XPath to express the 
element's parent, ancestor, sibling, or child or descendant elements, or 
its attributes or those of its parents, ancestors, siblings, children, 
or descendants, or any combination.

For example, in the first field, the first cell of the table contains 
the element type "gi", whereas the first cell in the second field table 
contains the element type "db". So cell[gi] refers to the first cell of 
the first field table, and cell[db] refers to the first cell of the 
second field table. Unfortunately cell[db] also refers to the second 
cell of the first field table, and others, so you need to find a more 
accurate expression, perhaps based on the type of field, eg 
cell[db][ancestor::field[title='Encoding Nucleotide']] for the first, 
and cell[db][ancestor::field[title='Database Cross-references']] for the 
second and later ones. You need to know the data and the markup fairly 
intimately to be successful with this.

Deliberate and wilful inconsistency in the use of markup like this is a 
form of "tag abuse", where one do-it-all element (cell) identifies 
absolutely nothing at all except some visual placement on the screen, 
but gets [ab]used for all kinds of irrelevant things. It's a very 
attractive shortcut way of producing XML, especially to database people 
who don't understand what markup is, but in the long term it is 
unreliable, especially when the data or its arrangement changes, which 
means it is not suitable for doing business with. The following:

<record>
   <field gi="38511418" db="gb" accession="BC061645">
     <title>Encoding Nucleotide</title>
     <content>Mus musculus peptidylprolyl isomerase
       (cyclophilin)-like 3, mRNA (cDNA clone MGC:67795
       IMAGE:5032617), complete cds</content>
   </field>
   <field>
     <title>Database Cross-references</title>
     <xrefs n="3">
       <xref db="GENE" id="70225"/>
       <xref db="SPTR" id="Q9D6L8"/>
       <xref db="SPTR" id="Q812D2"/>
     </xrefs>
   </field>
</record>

contains exactly the same information, but it is much easier to see what
the data really represents, which in turn makes it much easier to write 
XSLT to manipulate it. There are doubtless other optimizations which can 
be made if you know the data.

///Peter
-- 
XML FAQ: http://xml.silmaril.ie/


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent