29686 2016-06-04 15:54:29 +0000 [xslt3.0] Imprecise language for rules on xsl:override 2016-10-06 18:42:23 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC All CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 126672 0 mike 2016-06-04 15:54:29 +0000 We say for xsl:override of functions, "The types of the arguments are pairwise identical.... The return types are identical." It would be more precise to say what we mean by "the type of", e.g. to talk of "the declared type, defaulting to item()*" 126714 1 mike 2016-06-09 16:23:34 +0000 Abel asks: does XPath have a definition of type equality, e.g. is union(A,B) identical to union(B,A)? 126717 2 mike 2016-06-09 17:49:02 +0000 The answer to the question in comment #2 is that we do have a definition of "identical types" in 3.5.3.3: [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.] This rule means, for example, that union(double, decimal) is the same type as union(decimal, double). 126719 3 mike 2016-06-09 22:15:49 +0000 The language has been tightened up a little: The <phrase diff="chg" at="T-bug29686">declared types of the arguments (defaulting to <code>item()*</code>)</phrase> are pairwise <termref def="dt-identical-types">identical</termref>. The <phrase diff="chg" at="T-bug29686">declared return types (defaulting to <code>item()*</code>)</phrase> are <termref def="dt-identical-types">identical</termref>. 126786 4 mike 2016-06-16 16:21:52 +0000 Reopened because there was discussion about whether this definition of "identical" actually works - e.g. if untypedAtomic is supplied to union(double, decimal) the effect is different from when it's union(decimal, double). 126828 5 mike 2016-06-24 13:03:30 +0000 I have added a test case override-f-031 126841 6 mike 2016-06-27 07:55:59 +0000 The WG discussed this on 23 June 2016. I was given an action to add a note going into more detail about the consequences of the rule on "identical" types, which I have done as follows: Consider a function that accepts an argument whose declared type is a union type with member types <code>xs:double</code> and <code>xs:decimal</code>, in that order (we might write this as <code>union(xs:double, xs:decimal)</code>). Using the same notation, this can be overridden by a function that declares the argument type as <code>union(xs:decimal, xs:double)</code>. This does not affect type checking: a 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 <code>xs:untypedAtomic</code> value <code>"93.7"</code> (or an untyped node with this as its string value) will be converted to an <code>xs:decimal</code> in one case and an <code>xs:double</code> in the other. 126842 7 mike 2016-06-27 07:58:14 +0000 The WG discussed this on 23 June 2016. I was given an action to add a note going into more detail about the consequences of the rule on "identical" types, which I have done as follows: Consider a function that accepts an argument whose declared type is a union type with member types <code>xs:double</code> and <code>xs:decimal</code>, in that order (we might write this as <code>union(xs:double, xs:decimal)</code>). Using the same notation, this can be overridden by a function that declares the argument type as <code>union(xs:decimal, xs:double)</code>. This does not affect type checking: a 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 <code>xs:untypedAtomic</code> value <code>"93.7"</code> (or an untyped node with this as its string value) will be converted to an <code>xs:decimal</code> in one case and an <code>xs:double</code> in the other.