RE: [xsl] problem with an xml/xsl transformation

Subject: RE: [xsl] problem with an xml/xsl transformation
From: "Gary Fix" <gary.fix@xxxxxxxxxx>
Date: Mon, 5 Apr 2004 13:07:36 -0700
Thanks Ken!
I used the mode="do-owner-stuff" attribute and that worked!

As far as "always use an XSLT processor that reports template 
conflicts", I use XMLSpy and it didn't seem to report any conflicts
(or I'm not using it correctly).
Can you recommend tools that would report these conflicts?

thanks again!
gary


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx]
Sent: Monday, April 05, 2004 9:20 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] problem with an xml/xsl transformation


At 2004-04-05 08:55 -0700, Gary Fix wrote:
>Here's my input xml:
>...
>                                 <ClaimsPartyInfo>
> 
><ClaimsPartyRoleCd>VEH</ClaimsPartyRoleCd>
> 
><ClaimsPartyRoleCd>DRV</ClaimsPartyRoleCd>
> 
><ClaimsPartyLocCd>INSVEH</ClaimsPartyLocCd>
>...
>and my xsl:
>...
>         <xsl:template 
> match="ClaimsSvcRq/ClaimsNotificationAddRq/ClaimsParty/ClaimsPartyInfo[descendant::ClaimsPartyRoleCd='VEH' 
> and descendant::ClaimsPartyLocCd='INSVEH']">
>                 <xsl:element name="OwnerName">
>                         <xsl:call-template name="GetName"/>
>                 </xsl:element>
>         </xsl:template>
>
>         <xsl:template 
> match="ClaimsSvcRq/ClaimsNotificationAddRq/ClaimsParty/ClaimsPartyInfo[descendant::ClaimsPartyRoleCd='DRV' 
> and descendant::ClaimsPartyLocCd='INSVEH']">
>                 <xsl:element name="DriverName">
>                         <xsl:call-template name="GetName"/>
>                 </xsl:element>
>         </xsl:template>

Both of the above template rules match the same <ClaimsPartyInfo> element.

Pushing the ClaimsPartyInfo element with an <xsl:apply-templates> will 
trigger a "template conflict", which the XSLT Recommendation describes as 
an error.

>what the transform looks like:
>
><?xml version="1.0" encoding="UTF-8"?>
><UdtFNOLArray>
>         <VehicleData>
>                 <DriverName>C J Pounder III &amp; Brock Pounde</DriverName>
>                 <DriverName>C J Pounder III &amp; Brock Pounde</DriverName>
>         </VehicleData>
></UdtFNOLArray>

Right ... because the same template rule is being fired for the same node 
in both cases.

>and what it should look like:
>
><?xml version="1.0" encoding="UTF-8"?>
><UdtFNOLArray>
>         <VehicleData>
>                 <OwnerName>C J Pounder III &amp; Brock Pounde</DriverName>
>                 <DriverName>C J Pounder III &amp; Brock Pounde</DriverName>
>         </VehicleData>
></UdtFNOLArray>

How do you want to distinguish the two template rules since they both match 
the same node?  When you figure out what the distinction is, you will be 
able to change your match accordingly.

>The Driver element gets repeated.

Right ... as I would expect when both template rules match the one node.

>If I switch locations of the Owner and Driver xsl sections, the Owner gets 
>repeated. I'm thinking this is do to similar templates having only the 
>"descendant::ClaimsPartyRoleCd='VEH'" being different and the last one "wins".

Not quite, it is because both template rules match the one node and your 
processor is not reporting template conflict rule errors so is, by 
specification, using only the latter in document order of the stylesheet of 
all template rules that match.

>But I'm having difficulty coming up with a different method that works.

You will have to establish the criteria and use either modes or priority.

For example, using modes:

<xsl:template match="ClaimsPartyInfo" mode="do-owner-stuff">
   ...
</xsl:template>

<xsl:template match="ClaimsPartyInfo" mode="do-driver-stuff">
   ...
</xsl:template>
...
   <xsl:apply-templates mode="do-owner-stuff" select="..."/>
   <xsl:apply-templates mode="do-driver-stuff" select="..."/>

If the determination is by other criteria in your source tree, use priority 
instead.

The above techniques remove the template conflict, so there isn't an error.

But, you shouldn't be developing using a processor that doesn't report 
template conflicts.  I advise all of my students that during development 
they should always use an XSLT processor that reports template 
conflicts.  Consider the situation where you write the above stylesheet and 
it just happens to do what you want because of the fallback behaviour ... 
you ship it to your customer ... your customer happens to be using an XSLT 
processor that reports template conflicts and abends ... all of a sudden 
your "working" stylesheet does not work (spectacularly!) for your customer.

I hope this helps.

.......................... Ken

--
Public courses: Spring 2004 world tour of hands-on XSL instruction
Each week:   Monday-Wednesday: XSLT/XPath; Thursday-Friday: XSL-FO
Hong Kong May 17-21; Bremen Germany May 24-28; Helsinki June 14-18

World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/s/bc

Current Thread