This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
Suggested specification outline: Rules for Polyfill functions A polyfill is a user-written function in a reserved namespace A polyfill SHOULD NOT be defined unless it implements a specification issued by the authority for that namespace A polyfill function MUST specify a value (yes or no) for the override-extension-function attribute [which is interpreted as override-vendor-function...] Something about having package scope... ?Allow xsl:original Notes Valid reasons for using a polyfill include: The vendor has not implemented the function (e.g. xs:dateTimeStamp) The vendor's implementation of the function is non-conformant The vendor's implementation of the function does not meet performance requirements The specification of the function leaves aspects implementation-dependent or -defined, and this causes interoperability problems (e.g. the vendor's implementation of normalize-unicode does not provide a required normalization form)
While recognizing the benefits, we also found some complications: (a) It's not clear what the effect on static expressions would be (b) It could be disruptive for some implementations that make built-in assumptions about the behaviour of built-in functions (c) We might need rules about compatibility of signatures between a polyfill function and the built-in version. So we're abandoning the proposal for now.
(In reply to Michael Kay from comment #2) > So we're abandoning the proposal for now. For reference, discussion continued in the Public XSLWG Mailing List: https://lists.w3.org/Archives/Public/public-xsl-wg/2016Feb/0009.html