Re: id attribution in template match

> The schema correctly identifies all id attributes as type xs:ID, and all
> idref attributes as type xs:IDREF.
>
> So that's question 1, is there a hidden trap with id(@idref) type
> expressions here?

Are you transforming the validated input?  It sounds like the problem
you were having before - your transform relies on the input being
validated for the processing to succeed, but instead you are
validating the input then discarding the "output" of the validation,
and continuing to process the original input.

I guess that's a big difference that might not be obvious - if the XML
references a DTD, when you process that XML you will (nearly) always
process it after validation, with all ids created, defaults inserted,
entities expanded etc.  If the XML references an XSD, you will
(nearly) always process it without it being modified by the validation
process.

So with DTDs unless you explicitly "turn it off" you will get the post
validation input, and with XML Schema unless you explicitly "turn it
on" you will get the pre validation input.

My own view is that the validation process should not modify the input
in any way, it just creates a coupling that causes problems for all
consumers of that XML.  I would rewrite out the validation dependent
parts of your transform..


> Question 2 follows from my using the above workaround, because it isn't
> obvious how to apply it in template matches.
>
> For example I have a template declared like so:
> ----
>  <xsl:template match="jump[@idref][local-name(id(@idref))='footnote']">
>  ..
>  </xsl:template>
> ----
>
> This is no longer matching jumps which point to footnotes, so I tried the
> same technique as above:
> ----
>  <xsl:template match="jump[@idref][local-name(//*[@id =
> ./@idref])='footnote']">
>  ..
>  </xsl:template>
> ----
>
> I know this won't work because the . in the last predicate matches the
wrong
> element. I can't put the idref in a variable and use that because I would
> have to do that outside the template. Is there a particular technique that
> would allow me to evaluate this test properly

Use current() instead of .


--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/