> I'm refactoring some XSLT stylesheets and encountering issues with keys in
> Xalan-C++ but not Xalan-Java. I don't know the version number on Xalan-C++
> at this time, but what I am about to suggest is more general, and in fact
> applies to all XSLT processors. My colleagues think the issues arise when
> the data to be keyed would result in an empty "key table" structure.
>
> Let's say the key is defined this way:
> <xsl:key name="MyKey" match="section" use="@refnum"/>
> If there are section elements with refnum attributes in the source, then
> the key table gets populated. I think we wrote test cases long ago for the
> key function where
>
> (A) No section elements have @refnum of the specified value
>
> (B) Exactly one section element has a matching @refnum
>
> (C) More than one section element has a @refnum of the specified value
> ...and the calls to key() would return node-sets of 0, 1, and however-many
> nodes, respectively. I am concerned that we may not have tests for
>
> (D) There are no section elements at all
>
> (E) There are section elements, but none have @refnum
> Beyond that, tests where the use expression is a sub-element or union
> would be nice, so that there is coverage of additional multi-match
> scenarios with no matches, extending scenario E.
>
> A particular concern is that scenarios D and E should still result in the
> creation of a key table, albeit one having no "rows" in it. A call to
> key('MyKey',value) should not throw a no-such-key error, but rather return
> the same as scenario A.
>
> A shift of context to a different document changes the set of "rows" that
> are in scope for possible fetching of nodes that key('MyKey',value) will
> return. The stylesheet should be able to switch among various documents,
> specifically between populated and zero-row scenarios, and not lose the
> key table.
> .................David Marston
>
Thanks David,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
