Subject: Re: [xsl] keys and idrefs - XSLT2 request? From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Wed, 10 Oct 2001 10:23:49 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] keys and idrefs - XSLT2 r, DPawson | Thread | RE: [xsl] keys and idrefs - XSLT2 r, DPawson |
Re: [xsl] Serializing external XML , Jeni Tennison | Date | Re: [xsl] validating a schema at ru, Jeni Tennison |
Month |