Open JohnGlauert opened 2 months ago
@JohnGlauert Thanks for reporting. Convoluted cases is exactly what we need to make this library better.
AArrgghh!
I have sent you the wrong starting point for the stylesheet so the results will not make sense. In the actual process we use, the input:
<hns_sign gloss="simple">
<hamnosys_manual>
<hamflathand/>
</hamnosys_manual>
</hns_sign>
is transformed by an earlier stage to:
<sign gloss="simple">
<hamnosys_sign>
<sign2>
<minitialconfig2>
<handconfig2>
<handshape2>
<handshape1 handshapeclass="ham_flathand"/>
</handshape2>
</handconfig2>
</minitialconfig2>
</sign2>
</hamnosys_sign>
</sign>
This is then handled by the stylesheet as mentioned.
I have updated the original submission.
Apologies.
I have a case where xsl:choose gives unexpected results but an equivalent pair of xsl:if elements works (using a browser solution with XSLTProcessor).
NOTE: I have corrected the text here. See later comment.
A cut down stylesheet working on:
should yield:
but yields:
Here is the (failing) stylesheet - cut back a lot:
There are several alternatives in template 'handShapeValue': One using a complex XPath expression - works; one using xsl:if - works; some using xsl:choose - don't work.
Looking at the high level code, xsl:if looks simpler and straightforward, while xsl:choose seems to use a different evaluation context, which maybe does not work in my case.
There may be other cases where xslt-processor is not working with my stylesheet as some output is duplicated. However, this seems to be a simple case where I am doing something wrong or there is an issue. I could convert all xsl:choose cases to xsl:if (even using XSLT!) but would rather not. The underlying stylesheet is very old and has been used without problems for many years - but it is several thousand lines long.