Thanks for the comment. We're well past the closing date for comments on the Candidate Recommendation, I'm afraid. We're still interested in reports of errors or inconsistencies, but not in suggestions for improvement.

>I don't see any reason why it shouldn't also return true() on supported XSLT declarations.

It was defined this way in XSLT 1.0, and is retained that way (a) for backwards compatibility, and (b) because there is no overriding motivation to change it. I've never been sure whether it was a deliberate decision to confine it to instructions in 1.0 (if there was, one might have expected the function to be named "instruction-available"), but certainly that's the way the spec was written, and the use-case for which the construct was designed was entirely concerned with conditional execution of instructions, in stylesheets designed to run under more than one version of XSLT, or in stylesheets invoking vendor extensions (which can only take the form of instructions). The point was to allow a stylesheet to write:

<xsl:choose>
  <xsl:when test="element-available('xsl:sequence')">
    <xsl:sequence select="$x"/>
  </xsl:when>
  <xsl:otherwise>
    <xsl:copy-of select="$x"/>
  </xsl:otherwise>
</xsl:choose>

and thus to write stylesheets which will work on both XSLT 1.0 and 2.0 processors, while still taking advantage of 2.0 facilities when available.

You can't wrap a conditional around a declaration in this kind of way.

What you can do in 2.0 is to use xsl:use-when. For example if XSLT 3.0 introduced a new declaration xsl:input-format, you could write

<xsl:input-format use-when="system-property('xsl:version')='3.0')"/>

>By the way, aren't the following elements instuctions?
xsl:matching-substring
xsl:non-matching-substring
xsl:otherwise
xsl:output-character
xsl:sort
xsl:when
xsl:with-param

No, they aren't. There are four kinds of elements in the XSLT namespace: those that are instructions, those that are declarations, those that are both (for example xsl:variable) and those that are neither (like those you have listed above).

Michael Kay
(personal response)

OK. They are neither. Then shuoldn't this type of category have it's own name (just for formality...)? Maybe something like "Instruction/Declaration Settings" or just "Settings"? I don't know... something.

Oh, and for the use-when attribute.

1. Using the system-property() with it will work if all XSLT 2.0 processors and future XSLT 3.0 processors support all declarations or at least all that can be detected with system-propertyes like xsl:supports-serialization. It will help distinguish the XSLT 2.0 behaviour from the XSLT 1.0 and future XSLT ones. However, if a certain declaration is not supported in an implementation, it becomes impossible to make a cross-processor stylesheet, unless explicitly using system-property('xsl:product-name').

2. Even if we suppose all XSLT 2.0 processors support all standart declarations and future XSLT 3.0 processors support all of the new ones as well (making point 1 invalid), detecting extension declarations ("user-defined data elements") is still impossible, or at least, I can't think of a way to detect them without a function like element-available() or a new system-property for detecting user-defined data elements.

Allowing element-available() to at least detect user-defined data elements would cure this.

By the way, personally, I think backdraw compatability is not that much of an issue. MSXML 3.0 (with IE6 and IE7), Transformiix (with Firefox 1.5.0.7 and earlier), Opera 9 and Xalan-C (tested in Dreamwaver 8) already return true() to all supported elements. MSXML 4.0+ and libxslt 1.1.15 don't, but then again, if one aimed for a cross-processor stylesheet, (s)he would probably not rely on only the buggy processors' unstandart behaviour to begin with. In other words, using element-available() to detect standart top-level-elements is probably not used that much (in comparrison to detecting availability of extension top-level-elements anyway).

Personal response to your reply:

>>1. Using the system-property() with it will work if all XSLT 2.0 processors and
future XSLT 3.0 processors ... However, if a certain declaration is not supported in an implementation.

Unfortunately, if processor chooses not to conform to the specification, there is very little we can choose to do about it. In particular, we can't include clauses like "if you don't support this element which all conformant processors are required to support, then you must do XYZ." A vendor who ignores one conformance rule in the spec is likely to ignore others as well. 

2>> detecting extension declarations ("user-defined data
elements") is still impossible

It's not necessary to detect them, as it is for extension instructions, because by default a processor will ignore them anyway. 

It's not clear in any case what something like element-available('saxon:collation') would mean. You can always have a top-level element called saxon:collation - the element is always available. The only question is whether the processor attaches any special meaning to it: and you can determine that by testing  system-property('xsl:vendor').

3>> By the way, ... MSXML 3.0 (with IE6 and IE7), Transformiix (with Firefox 1.5.0.7 and Opera 9 and Xalan-C (tested in Dreamwaver 8) already return true() to all supported elements. MSXML 4.0+ and libxslt 1.1.15 don't

We're aware that conformance to some aspects of XSLT 1.0 has been patchy, and we have sometimes taken such evidence into account when deciding how critical it is to be backwards compatible. I would accept that this is a case where if we decided that a change was clearly desirable, we would not let backwards compatibility get in the way.

>2>> detecting extension declarations ("user-defined data
>elements") is still impossible
>
>It's not necessary to detect them, as it is for extension instructions, because
>by default a processor will ignore them anyway.
OK. So how exactly does one trigger an instruction workaround for an unsupported user-defined data element?

> The
>only question is whether the processor attaches any special meaning to it: and
>you can determine that by testing  system-property('xsl:vendor').
Using system-property('xsl:vendor') and/or system-property('xsl:product-name') is exactly the thing I meant that shouldn't be done for such sorts of detection. True, some extension might be vendor specific, but others (take EXSLT for most part) will be available to more then one processor.

If I ,as an author, wanted to make a cross-processor stylesheet that uses extensions, I would of course want it to be working on all processors, though partically or slowly in some (is there an unportable cross-processor stylesheet anyway?). A stylesheet isn't completely portable when it's detecting the vendor instead of the availability.

An author will have to edit the (hypothetically big) stylesheet every time a new processor arises, or otherwise, just like JS browser detects, new processors with support for the declaration might not use it as intended and will instead get a fallback template, that we could suppose is slower or simply not working. Or worse. They might execute both the workaround and the declaration, slowing the process even further or making the output look funny. Which one of the two of course depends on how the tests were made.

Thank your for taking the time to comment on XSLT 2.0.  The WG held a special telcon last week to consier your request (our CR comment period has been closed for several months).  After thorough review we determined that your comment consitutes an "enhancement request".  We recognize that any language can always use many interrogatives and we will consider your request as a possible requirement for the potential next release of XSLT.

We appreciate your idea.but will close this bug marking it for consideration for a later release.

Thank you.

Sharon Adler
XSLT WG Chair