Description of Problem: I don't know XSL well enough to know if this is really a bug, but it seems odd at the last. Version-Release number of selected component (if applicable): 1.0.5-1 How Reproducible: 100% I would expect the output from the following attachments run as xslt keys.xsl keys.xml to be this: <?xml version='1.0'> C-h C-f but instead it is <?xml version=1.0'> Ch Cf
I mean xsltproc of course.
Created attachment 34041 [details] keys.xsl
Created attachment 34042 [details] keys.xml
No bug that I know of. I have a really hard time trying to understand what (and how) you're trying to achieve, keycombo is both the top node and its first child element (bad design or error ?).To check how xsltproc evaluate the stylesheet run with -v: xsltproc -v keys.xsl keys.xml Daniel
The XML comes straight out of DocBook, and the XSL from docbook-xsl-1.45. xsl:for-each is killing the template processing of the child keycombo nodes; is it meant to?
Oh, you're right; I've learnt a little more XSL now. This is a docbook-xsl bug. (Hmm, no bugzilla component for that..)
Fixed in docbook-style-xsl-1.47-1.