This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: keys and idrefs - XSLT2 request?
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] keys and idrefs - XSLT2 request?
- From: "cutlass" <cutlass at secure0 dot com>
- Date: Wed, 10 Oct 2001 10:57:26 +0100
- References: <9B66BBD37D5DD411B8CE00508B69700FE7A580@pborolocal.rnib.org.uk>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > -----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