It's difficult for me to say anything useful on this without seeing your
code. It doesn't match any known bug in 6.5.2.
Is there just one xsl:key declaration with the given name?
Is there only one source document? A common problem with the key()
function is calling it when the context node is in a temporary tree, not
in the principal source document.
Do you get the expected results if you replace the call on key('k', $v)
with the expression //MATCH[USE=@v]? In most cases, this expression
should give the same results as calling key().
When you say that there are incorrect entries in the key tables, is this
based on low-level inspection of Saxon's index structures, or on
stylesheet-level behavior of the key() function?
Without seeing your code, I would expect that the most likely
explanation is calling key() when the context node is in the "wrong"
> -----Original Message-----
> From: saxon-help-admin@...
> [mailto:saxon-help-admin@...] On Behalf Of
> W. Eliot Kimber
> Sent: 30 July 2003 03:00
> To: saxon-help@...
> Subject: [saxon] Apparent Bug in 6.5.2 Key Processing
> I have run into what appears to be a bug in the xsl:key processing in
> 6.5.2 but I have not been able to find the cause, although I can
> reproduce the problem. I have not yet created a small,
> test case that demonstrates the problem.
> The style sheet that exposes the problem is one that is
> making multiple
> passes over a multi-language document to generate successive output
> documents, one for each language, by successively doing
> "apply-templates" with the pattern "/mydocelement/foo" to
> re-process the
> various parts of the book, passing the current language code in as a
> parameter to apply-templates.
> The failure comes in the processing done to produce a
> index. If I process a single-language document or process only one
> language of a multi-language document, then everything works fine.
> However, if I process all of the languages in a document,
> then only the
> first language processed (in document order) has correct
> entries in the
> key tables--subsequent languages will either be missing
> entries or there
> will be multiple rows for the same key (or maybe multiple
> index objects
> for the same group name--it's hard to tell from the XSLT
> code). In the
> source document the multiple languages are all interleaved together.
> What I have done to try to isolate this so far is:
> - Traced the construction of the indexes in the KeyManager class to
> verify that each key table is constructed only once.
> - Verified that all expected elements match the use= and match= values
> - Verified that a given language will not have any lookup
> failures when
> run in isolation or as the first language processed but will when
> processed as the 2nd or subsequent language processed.
> - Verified that all the key table construction is done at the
> start of
> the processing of the first language and is not, for example,
> for subsequent languages (not that I was expecting it to be).
> - Observed that the set of values actually set into the table
> will vary
> depending on which language is processed first--this is the
> weird part.
> What's mystifying me is that I can't see from either my XSLT
> code or the
> Saxon KeyManager implementation how things could go wrong--Saxon is
> simply iterating over all the nodes in the document and
> populating the
> tables--this should not be affected by anything in the XSLT--that is,
> there's nothing I can or should able to do in the XSLT style sheet to
> somehow limit the scope or context in which nodes are
> evaluated for key
> table population.
> I'm happy to continue trying to debug and fix this issue--I have a
> critical need to get this working ASAP and I have too many Saxon
> extensions to quickly move to 7.x (and my customer would not
> be keen on
> changing XSLT implementations in mid project if it can be
> avoided)--however, I need some pointers or ideas on where I
> should look
> to try to find a solution to this problem. I'm not sufficiently
> conversant with the 6.5 code to know where to go from here.
> I'm really
> at a loss.
> W. Eliot Kimber, eliot@...
> Consultant, ISOGEN International
> 1016 La Posada Dr., Suite 240
> Austin, TX 78752 Phone: 512.656.4139
> This SF.Net email sponsored by: Free pre-built ASP.NET sites
> including Data Reports, E-commerce, Portals, and Forums are
> available now. Download today and enter to win an XBOX or
> Visual Studio .NET.
saxon-help mailing list