Javascript programmers have become used to the idea that the function library gradually grows, with different functions being available in different implementations, and the availability of a particular function sometimes preceding and sometimes following standardisation. The solution to the diversity among implementations is the concept of a "polyfill" - a user-written implementation of a standard function designed to fill a gap in a vendor-supplied function library. The result is imperfect, but it goes some way towards achieving the goal of interoperability without stagnation.

We've got a similar concept with <xsl:function override-extension-function="yes"/> which is explicitly designed to allow users to define an implementation of a function that is present in some implementations but not others. However, we have rather crippled the capability by the fact that the function can't be defined in a reserved namespace.

Suppose there's a new standard (either XSLT or XPath or some completely separate spec) that decides to define an array:put() method (an omission which I was suprised to discover this morning). This will immediately be added to some products but not to others. Users can work around this using use-when and function-available. They could even bind a variable conditionally to either array:put#3 or my:put#3 and then do dynamic function calls (assuming everyone implements higher-order-functions...). But how much simpler if they could simply write:

<xsl:function name="array:put" override-extension-function="yes">
 <xsl:param name="array"/>
 <xsl:param name="index"/>
 <xsl:param name="value"/>
 <xsl:sequence select="$array => array:remove($index) => array:insert-before($index, $value)"/>
</xsl:function>

I would suggest the following changes to our rules: 

(a) a user-written function is allowed to be defined in a reserved namespace provided that the override-extension-function attribute is present (it can say either "yes" or "no", but must be explicit).

(b) an extension function is allowed to be defined in a reserved namespace [OPTION: provided that it conforms with a specification that has been published, proposed, or accepted by the authority for that namespace]. Note that such an extension function can always be overridden by a user function under rule (a).

With these rules, we (that is, anyone acting under W3C process) could put together a one-page spec for an array:put function, publish it as a free-standing W3C spec, and implementors could then legally add it to their processors, without any need for a change in the XSLT spec.

I don't propose changing the spelling of the override-extension-function attribute to reflect the revised semantics.

Because this change does not require any changes to existing implementations or stylesheets (it permits such changes but does not require them), I see no difficulty with making it during CR.

Michael Kay
Saxonica