29470 2016-02-16 08:42:59 +0000 [xslt30] Polyfills 2016-10-06 18:42:31 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC All CLOSED WORKSFORME P2 normal --- 1 mike mike abel.braaksma public-qt-comments oldest_to_newest 125069 0 mike 2016-02-16 08:42:59 +0000 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 125070 1 mike 2016-02-16 08:44:37 +0000 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) 125090 2 mike 2016-02-16 13:47:32 +0000 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. 125181 3 abel.braaksma 2016-02-20 15:06:14 +0000 (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