Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Reusing XPath statements (defining once and only o
 Original XSL note from: David Mitchell (on Thu, 17 Apr 2003 at 16:36:25 -0500) In reviewing the code I realized that the original transform should have failed if it ever found a "Host" element that the additions needed to be made to. I have added some comments to the transform's code below. I ran the transform with instant saxon 6.5.2 using the "trace" facility. It complained as documented in the following: [.... many lines of trace information have been removed here.....] <Instruction element="xsl:apply-templates" line="34"> <Source node="/Server[1]/Service[2]/Engine[1]/Host[1]/@name" line="-1" mode="*default*"> <Instruction element="xsl:template" line="11"> <Instruction element="xsl:copy" line="12"> Error at xsl:copy on line 12 of file:/C:/MRIS/SAXONN~1/identity2.xsl: Cannot write an attribute when there is no open start tag Transformation failed: Run-time errors were reported The transform (with comments) as provided to the XSLT list originally:
<xsl:template match="Host">
<xsl:copy>
<xsl:apply-templates select="@*" />
<!-- here you copy the attributes of the
host element to the result tree. -->
<xsl:if test="@appBase='webapps'">
<xsl:choose>
<xsl:when test="Context[@path='/axis']" />
<xsl:otherwise>
<Context debug="0"
docBase="c:\xml-axis-10\webapps\axis" path="/axis"
reloadable="true" />
</xsl:otherwise>
</xsl:choose>
</xsl:if> <xsl:apply-templates
select="@* | * | comment() | processing-instruction() | text()" />
<!-- the '@*' alternative in the preceding select eventually
causes the system to attempt to add an attribute node
to the result tree ... the attributes have already been
placed in the output result tree -->
</xsl:copy>
</xsl:template>
</xsl:stylesheet>If the suggested change is made (i.e., removal of the "@*" alternative the transform performs as expected. I can't resist asking ... What XSL processor were you using? I been thinking that perhaps your XSL processor is one that allows the "illegal" construct but discarded the erroneous attributes later when the result tree was serialized. Am I off the mark here? Perhaps Mike can explain if Saxon's behavior is instead in error. (Also why the trace output does not have a matching start tag for the "trace" end tag?!) I have to admit the little code snippet proved to be as interesting as a cross-word puzzle! Frank -- Dr. Frank Mabry Dept. of EE&CS U.S. Military Academy West Point, New York, 10996 Work Phone: 845-938-2960 work email: df6954@xxxxxxxxxxxxxxx home email: fmabry@xxxxxxxxxx "The great use of life is to spend it for something that will outlast it." - William James
Work Phone: 845-938-2960 work email: df6954@xxxxxxxxxxxxxxx home email: fmabry@xxxxxxxxxx "The great use of life is to spend it for something that will outlast it." - William James XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
