Saxon

Legacy ID: #7314244 Legacy Poster: Michael Kay (mhkay)

I would have thought a transformation done at source level (using the document() function to follow xsl:include/xsl:import links would be just as effective, and avoid a dependency on Saxon internals. Either way, the new stylesheet won't be equivalent to the original - for example xsl:apply-imports won't have the same effect. There is no way of preserving the import precedence of the original rules, which means that template priorities will be different from the original.

Legacy ID: #7318361 Legacy Poster: kendall shaw (queshaw)

Oh, I hadn't thought this through I guess. The reason for wanting to do this is as an aid to analyzing stylesheets, so it doesn't need to be equivalent. So, apply-imports and next-match not working, is okay I guess. But, I suppose another problem you are referring to is that templates with different patterns matching the same nodes could get dropped from the result, which would be unacceptable. Is there another thing involving import precedence that would not work? I suppose that's an XSLT question. Also, when I use the code above it doesn't merge attribute sets. The reason why I didn't write a transformation is that I thought it would be easier to get saxon to do it.

Legacy ID: #7318742 Legacy Poster: Michael Kay (mhkay)

>But, I suppose another problem you are referring to is that templates with different patterns matching the same nodes could get dropped from the result No, Saxon doesn't in general know at compile time whether two patterns overlap: it keeps both. It does drop templates/variables that have the same name but lower precedence than another, but I'm not sure if it does that before or after you're capturing the data. >Also, when I use the code above it doesn't merge attribute sets. Saxon doesn't do very much with attribute sets at compile time. They aren't used very often, so little attempt has been made to optimize them.