This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The tests hof-908 "local:f#1 eq 3" and hof-909 "number(local:f#1)" only accept the error FOTY0013 "Raised by fn:data, or by implicit atomization, if the sequence to be atomized contains a function item" It seems that an implementation that performs type checking (e.g. during static analysis) can recognize that the function item has an invalid type for the operator/function , before doing any atomization, and thus raise XPTY0004 "It is a type error if, during the static analysis phase, an expression is found to have a static type that is not appropriate for the context in which the expression occurs,..."
You can't argue for a particular error code based on the description of the error code. Many codes have descriptions that are over-general, e.g. err:FORG0006, Invalid argument type. You have to go to the specifics of the expression you have written and the errors associated with that expression. The failure here occurs when you attempt to atomize a function item, and the code for that is FOTY0013. The fact that you detect the error statically is irrelevant: it's still the same error.
> The failure here occurs when you attempt to atomize a function item, No, before it even attempts to atomize anything, it checks what the allowed types for the function/operator are, and a function item is not in the list of allowed types. >Many codes have descriptions that are over-general, e.g. >err:FORG0006, Invalid argument type. It's full description is actually under-general
>No, before it even attempts to atomize anything, it checks what the allowed types for the function/operator are, and a function item is not in the list of allowed types. That might be what your implementation does, but it's not what the rules say. The rules say you atomize first, and then check what the allowed type is. The rules are in XPath 3.1.5.1. * first identify the function to be called: no controversy. * then evaluate the arguments. The argument is a function item. * then apply the function conversion rules (3.1.5.2) * the function conversion rules tell you to atomize the value (Bullet 2, rule 1). (this fails with error FOTY0013) * if atomization succeeds, you go on to check that the actual type matches the required type (bullet 4), and raise XPTY0004 if it doesn't. But we never get this far.
Thanks Benito. The Working Group discussed this on 2015-02-10 and agreed that no changes are necessary to these test.