Hi Michael,
 
OK, you are right once again. It was Xalan that was causing a nuisance this time. I have removed Xalan.jar from CLASSPATH and it was smooth sailing with Saxon 9.1 as far as using empty() is concerned. I will use other approaches to associate Saxon 9.1 to this application to gain optimum performance. In the meantime, I now get 2 <hobbie> elements regardless of whether it exist or not. In other word, the default <hobbies>Unknown</hobbies> element is always generated.
 
The changes made to the original stylesheet are as follows:
 
<xsl:template match="/">
<employee>
<xsl:apply-templates select="//ns:p"/><xsl:variable name="hobbies" select="ns:p[ns:strong='Hobbies:']"/>
<xsl:apply-templates select="$hobbies"/>
<xsl:if test="empty($hobbies)">
<hobbies>Unknown</hobbies>
</xsl:if>
</employee>
</xsl:template>
<xsl:template match="ns:p[ns:strong='Hobbie:']|ns:p[ns:strong='Hobbies:']"> 
<xsl:for-each select="ns:a">
<hobbie><xsl:value-of select="."/></hobbie> 
</xsl:for-each> 
</xsl:template> 
 
As a result, how to change the stylesheet to create a default (<hobbies>Unknown</hobbies>) element only when "ns:p[ns:strong='Hobbies:']" is invalid? Would a <xsl:choose be suitable in this case but I can't seems to wrap it around the second match template.
 
Thank you very much once again for your invaluable guidances.
Jack



________________________________
From: Michael Kay <mike@s...>
To: Jack Bush <netbeansfan@y...>
Cc: xml-dev@l...
Sent: Friday, 6 February, 2009 8:21:09 PM
Subject: RE: [xml-dev] XSTL stylesheet workarounds for exceptions


Do
 
System.err.println(hobbiesTransformer.getClass())
 
to see what XSLT transformation engine you have loaded. All the evidence suggests it's a 1.0 transformer - probably Xalan, possibly Saxon6.
 
Relying on the classpath to pick up the right XSLT engine is notoriously error-prone. If your code depends on having an XSLT 2.0 processor, the safest thing is to instantiate Saxon directly:
 
hobbiesTransformer = new net..sf.saxon.TransformerFactoryImpl();
 
This is incidentally much faster than searching the classpath. (In extreme cases, searching the classpath to find a TransformerFactory can take longer than the entire transformation).
 
If you don't want a compile-time reference to Saxon in your code, you can either (a) instantiate the factory using reflection, or (b) set the system property
 
System.setProperty("javax.xml.transform.TransformerFactory", "net.sf.saxon.TransformerFactoryImpl")
 
Michael Kay
http://www.saxonica.com/


________________________________
From: Michael Kay <mike@s...>
To: Jack Bush <netbeansfan@y...>; butlerdi@g...
Cc: xml-dev@l...
Sent: Thursday, 5 February, 2009 12:26:02 AM
Subject: RE: [xml-dev] XSTL stylesheet workarounds for exceptions

<xsl:template match="ns:p[ns:strong='Hobbie:']|ns:p[ns:strong='Hobbies:']">


Now the only question left is the second half ( ii ) of the original post
included below:

    

    ( ii ) I also like to add a default generic value for any missing
element. Say if there are no 

    <p><strong>Hobbies:</strong></p> in such document, yet I still would
like to generate a 

    null element such as <hobbies>Unknown</hobbies>.  

    
You need to do this at the next level up, where you are applying-templates
to the p elements. Something like

<xsl:variable name="hobbies" select="ns:p[ns:strong='Hobbies:']"/>
<xsl:apply-templates select="$hobbies"/>
<xsl:if test="empty($hobbies)">
  ... default output goes here ...
</xsl:if>

Michael Kay
http://www.saxonica.com/ 


________________________________
Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more.
________________________________
Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more..
________________________________
Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more.


      Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more