Re: keys and idrefs - XSLT2 request?

> > -----Original Message-----
> Jeni wrote:
>
> > *But* if you have an element that looks the same as one in XSLT 1.0,
> > has XPath expressions that look like XPath 1.0, but actually behaves
> > completely differently, then the XSLT 1.0 processor won't warn you,
> > won't give you an error, it will just go ahead and process the thing,
> > but give completely different results.
>
> I was hoping that the processor would see 2.0, know it was a 1.0
> processor, and stop, right there, or at least give a warning.
>
> For this particular case it would only process the first token
> from the idrefs list, as it does today.
>
>
> > I don't know what/whether the XSL WG have decided to do about
> > backwards compatibility in XPath - it probably depends on how much
> > they feel they have to nanny us authors to make sure that we're told
> > when our stylesheets are running under the wrong processors...
>
> If the WG are going to wrap us in so much cotton wool, I wouldn't be
> best pleased.
>
> A warning (this particular case) would be the softest I would appreciate,
> it would at least let me know that something is awry.

i would hope that this, in the future could be trappable by the xsl:fallback
function, btw is there a 'built-in fallback template' for this defined
behavior in the spec ?

this is a topic i raised with respect to interoperability of xml
technologies; but with xslt we would at least expect the version of XPATH to
be bounded to its version of XSLT ( at least the 2 technologies can expect
whatever behavior ),

at the moment its obvious, that if there is going to be any graceful
handling of versioning problems, there is a requirement to make the
xsl:fallback function fine grained enough to deal with a mixture of versions
( of xml vocabularies..and technologies ), and deal gracefully with each
case.

cheers, jim fuller


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list