[Bug 29850] New: [FO31] Functions having the "same signature"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29850

            Bug ID: 29850
           Summary: [FO31] Functions having the "same signature"
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.1
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

Section 1.7.4 (rule 5(c)) talks of two functions "having the same signature"
without saying precisely what this means.

(The exact details are not in fact that important, because while "having the
same signature" is a necessary precondition for two functions to be
"identical", the question still ends up being to some extent
implementation-depedendant. But if we use the term, we should say what we mean
by it.)

We use the same concept in XSLT 3.0 (to define constraints on overriding
functions in another package), where we include the definition:

[Definition: Types S and T are considered identical for the purpose of these
rules if and only if subtype(S, T) and subtype(T, S) both hold, where the
subtype relation is defined in Section 2.5.6.1 The judgement subtype(A, B)
XP30.]

I propose to use the same definition.

The XSLT 3.0 spec adds the notes:

Note:

One consequence of this rule is that two plain union types are considered
identical if they have the same set of member types, even if the union types
have different names or the ordering of the member types is different.
Consider a function that accepts an argument whose declared type is a union
type with member types xs:double and xs:decimal, in that order (we might write
this as union(xs:double, xs:decimal)). Using the same notation, this can be
overridden by a function that declares the argument type as union(xs:decimal,
xs:double). This does not affect type checking: a function call that passes the
type checking rules with one signature will also pass the type checking rules
with the other. It does however affect the way that the function conversion
rules work: a call that passes the xs:untypedAtomic value "93.7" (or an untyped
node with this as its string value) will be converted to an xs:decimal in one
case and an xs:double in the other.

While this rule may appear formal, it is not as straightforward as might be
supposed, because the subtype relation in XPath has a dependency on the “Type
derivation OK (Simple)” relation in XML Schema, which itself appeals to a
judgement as to whether the two type definitions being compared “are the same
type definition”. Both XSD 1.0 and XSD 1.1 add the note “The wording of [this
rule] appeals to a notion of component identity which is only incompletely
defined by this version of this specification.” However, they go on to say that
component identity is well defined if the components are named simple type
definitions, which will always apply in this case. For named atomic types, the
final result of these rules is that two atomic types are identical if and only
if they have the same name.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 21 September 2016 13:42:27 UTC