29850
2016-09-21 13:42:13 +0000
[FO31] Functions having the "same signature"
2016-12-16 19:55:24 +0000
1
1
1
Unclassified
XPath / XQuery / XSLT
Functions and Operators 3.1
Candidate Recommendation
PC
All
CLOSED
FIXED
P2
normal
---
1
mike
mike
public-qt-comments
oldest_to_newest
127484
0
mike
2016-09-21 13:42:13 +0000
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.
127485
1
mike
2016-09-21 13:43:57 +0000
I have provisionally added this definition to the spec. I have included a short precis of the note:
Note: Under this definition, a union type with <code>memberTypes="xs:double xs:decimal"</code> is identical to a union type with <code>memberTypes="xs:decimal xs:double"</code>.
127486
2
mike
2016-09-21 13:59:04 +0000
I have extended the Note to say:
<noteUnder this definition, a union type with <code>memberTypes="xs:double xs:decimal"</code> is identical to a union type with <code>memberTypes="xs:decimal xs:double"</code>. However, two functions whose signatures differ in this way will probably be deemed non-identical under rule (e) below, because the two functions are likely to have different effect when invoked with an argument of type <code>xs:untypedAtomic</code>.</p></note>
This might appear to be a bit convoluted. We could try and define a relation between types in which the order of member types of a union type is significant. But I would much prefer to make maximal use of the definitions we already have, and this definition seems to work for the (very limited) purposes for which it is needed.
127565
3
mike
2016-09-27 20:37:50 +0000
The WG reviewed the proposed text (which is already in the latest editor's draft) and agreed it.