My problem ist that there might be different contexts, in which the
two stylesheet-modules are used. So there might be a stylesheet C,
using some xsl:keys of A, without importing B, because it
don't needs
it directly. Stylesheet D imports only B, because it uses
no key of A.
In this case I would have to keep in mind, that they depend on each
other, so that importing one of them requires to import the other,
too.
There are two things to bear in mind about keys, that are a little different
from other top-level declarations. Firstly, a key declaration that isn't
used does no harm. Secondly, you can have multiple keys with the same name,
and the effect is additive: one key doesn't override the other, you simply
use both.
This actually raises an interesting point that I hadn't thought of before.
If the key declaration
<xsl:key name="k" match="m" use="u"/>
appears in several stylesheet modules, and you then do
key('k', '1234')
then I think that in Saxon, one index is going to be built for each key
definition, the indexes will all be searched, and duplicates in the result
will then be eliminated. So although it does no functional harm to repeat
the key declaration, there will be a performance cost! This applies
regardless whether you do xsl:include or xsl:import.
I haven't actually encountered this problem in practice. I think my advice
would be to modularize the code so that all access to a particular part of
the data is channeled through functions and templates in one stylesheet
module - treat the module as encapsulating that part of the data; knowledge
of (and need for) keys on that part of the data will then be confined to
that module.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--