W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2016

[Bug 29470] New: [xslt30] Polyfills

From: <bugzilla@jessica.w3.org>
Date: Tue, 16 Feb 2016 08:42:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29470-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 29470
           Summary: [xslt30] Polyfills
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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)"/>

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

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 16 February 2016 08:43:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:59 UTC