W3C home > Mailing lists > Public > public-xsl-wg@w3.org > February 2016

Polyfills

From: Michael Kay <mike@saxonica.com>
Date: Mon, 8 Feb 2016 08:47:42 +0000
Message-Id: <5C20C893-7F74-40E3-BDE5-9B37898DA0F2@saxonica.com>
To: Public XSLWG <public-xsl-wg@w3.org>
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
Received on Monday, 8 February 2016 08:48:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:43:27 UTC