Re: [xsl] keys and idrefs - XSLT2 request?

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Hi Dave,

>> In other words, an XSLT 2.0 processor might look at the 'controls'
>> attribute, go "aha, an IDREFS attribute" and treat it as a sequence of
>> IDREF values. *If* that were the case, then:
>> 
>> <xsl:key name="control" match="process" use="@controls" />
>
> My preference certainly, the backwards compatibility issue, wouldn't
> that be addressed by the stylesheet version?

Possibly. Perhaps I'm thinking more about *forwards* compatibility. An
XSLT 1.0 processor confronted with an XSLT 2.0 stylesheet is expected
to run as much of it as it can. If it sees elements at the top level
of the stylesheet that it doesn't recognise, or attributes that it
doesn't recognise anywhere, then it should ignore them (and should
probably give a warning of some kind). If it sees instructions inside
a template that it doesn't recognise, then it looks for xsl:fallback.
If it doesn't see an xsl:fallback then it will halt with an error.
Most importantly, if it comes across an XPath expression that doesn't
look like XPath 1.0, then it will halt with an error.

*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.

In the schema-aware world, there's quite a lot of scope for changes
that mean that an XPath 2.0 expression behaves very differently from
an XPath 1.0 expression. For example, if you had:

  <foo xsi:type="xs:double">0.1E1</foo>

in your instance document, then:

  foo = 1

would be false in XPath 1.0 but could plausibly be true in XPath 2.0
(which would interpret 0.1E1 as the number 1 because it knows that
it's a double rather than a string). Presumably that's why it's
important to have casts or constructor functions - if you had to
write:

  xf:double(foo) = 1

or:

  cast to double(foo) = 1

then at least the XSLT processor would moan that it didn't recognise
the function or didn't recognise the syntax rather than giving you the
'wrong' result. (Note that this explicit casting is also preferable in
cases where you don't know whether the schema is accessible or not.)

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...

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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