This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm unable to spot the type check error in this test case. From the comment, I suspect it relatese to xs:QName(<f>local:f</f>) Applying 3.1.5.2 Function Conversion Rules, 1. Atomization is applied to the given value, resulting in a sequence of atomic values. This gives xs:QName(xs:untypedAtomic("local:f") 2. Expected type of constructor function xs:QName in xs:anyAtomicType?. This is not namespace-sensitive. Therefore XPTY0117 is not raised. 3. Result is xs:QName(xs:untypedAtomic("local:f")) (not an error in XQ30). Am I missing something? BTW, I'm not sure this test really depends on schema validation. <test-case name="FunctionCall-015"> <description>Test that arguments are atomized - but not the argument of casting to QName</description> <created by="Michael Kay" on="2011-10-31"/> <dependency type="spec" value="XQ30+"/> <dependency type="feature" value="schemaValidation"/> <test><![CDATA[ declare function local:f($in as xs:integer) as xs:integer { $in + 1 }; let $f := function-lookup(xs:QName(<f>local:f</f>), 1) return $f(12)]]></test> <result> <error code="XPTY0004"/> </result> </test-case>
I think the reasoning is: (a) the equivalent cast expression is an error under http://www.w3.org/TR/xpath-30/#id-cast rule 1 (b) Section 17.1 of F+O states "The semantics of the constructor function " xs:TYPE(arg) " are identical to the semantics of " arg cast as xs:TYPE? " But I agree, your argument seems reasonable, that the argument to the constructor function should be atomized in the same way as for any other function. So I think we have a spec issue.
(In reply to comment #1) > I think the reasoning is: > > (a) the equivalent cast expression is an error under > http://www.w3.org/TR/xpath-30/#id-cast rule 1 > > (b) Section 17.1 of F+O states "The semantics of the constructor function " > xs:TYPE(arg) " are identical to the semantics of " arg cast as xs:TYPE? " > > But I agree, your argument seems reasonable, that the argument to the > constructor function should be atomized in the same way as for any other > function. > > So I think we have a spec issue. I had suspected that, but checked 3.13.2 Cast. 1. The input expression is evaluated. 2. If the result contains a node, and the target type is namespace-sensitive, a type error [err:XPTY0117] is raised. Since the target type (xs:anyAtomicType) is not namespace-sensitive, the semantics of the cast are equivalent to the constructor.
But the equivalent cast expression is <f>local:f</f> cast as xs:QName and the "target type" is therefore xs:QName.
(In reply to comment #3) > But the equivalent cast expression is > > <f>local:f</f> cast as xs:QName > > and the "target type" is therefore xs:QName. Ooops - yes. How unfortunate! I'll mark this as a bug against the specification.
I'm inclined to think that the cleanest solution is to abandon the special rule (cast rule 1) that says atomization doesn't happen if the target type is namespace sensitive. It's a paternalistic rule that prevents people doing things whose effects might be surprising, but it causes orhogonality problems. The orthonogality problems are bearable for cast expressions, but are very disruptive if we try to carry the same rule through to constructor functions; and we really don't want to introduce a difference between casts and constructors.
I agree with the solution proposed in Comment #5.
(In reply to comment #5) > I'm inclined to think that the cleanest solution is to abandon the special rule > (cast rule 1) that says atomization doesn't happen if the target type is > namespace sensitive. It's a paternalistic rule that prevents people doing > things whose effects might be surprising, but it causes orhogonality problems. > The orthonogality problems are bearable for cast expressions, but are very > disruptive if we try to carry the same rule through to constructor functions; > and we really don't want to introduce a difference between casts and > constructors. The Working Group has agreed to this change.
I presume that this removes the raising of XPTY0117 in section 3.1.5.2 Function Conversion Rules. Thus XPTY00117 is now redundant.
(In reply to comment #8) > I presume that this removes the raising of XPTY0117 in section 3.1.5.2 Function > Conversion Rules. Thus XPTY00117 is now redundant. No, I don't think that was the intent. There's a problem with the function conversion rules that doesn't apply to casts and constructors: there's no obvious choice of static context to get the namespaces from. Using the static context of the function itself doesn't work for system functions and external functions (perhaps it doesn't even work for user-defined functions, as it's only expressions that have a static context). Using the static context of the caller raises lots of problems with dynamic function invocation, function coercion, and the like. The rule would also need to cover cases where the (ill-named) function conversion rules are used for things other than converting function arguments, e.g. conversion of function results, or conversion of variable bindings in XSLT. So I think the rule is still that conversion of untypedAtomic to QName does not happen in the function conversion rules.