This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Citing from the XQuery F&O document (15.1.1) " fn:boolean($arg as item()*) as xs:boolean ... If $arg is a sequence whose first item is a node, fn:boolean returns true.", that information contradicts the static type semantics of the fn:boolean() function (XQuery FS, 7.2.4) that demands the type (empty | node+ | xs:boolean | xs:string | xdt:untypedAtomic | fs:numeric) for the argument of fn:boolean. Apparently, a mixed sequence of nodes and atoms is allowed by the former (only the first item must be a node), while the latter disallows such sequences.
I think you have a valid point; "If $arg is a sequence whose first item is a node, fn:boolean returns true" implicitly states that after the first node in $arg, anything can follow, such as atomic values. Which makes me bet on that the second bullet point in F&O's section 15.1.1 fn:boolean is wrong. Perhaps it should be changed to read "If $arg is a non-empty sequence of nodes, fn:boolean returns true." That would be the most consistent with what is my impression of how fn:boolean() is supposed to behave. If so, 2.4.3 Effective Boolean Value in XPath20 would need an update as well, as usual. Regards, Frans
I believe that the spec is the way it is by design. For systems doing dynamic type-checking, it is not reasonable to expect them, given an expression such as <xsl:if test="//item">, to read the whole input sequence in order to check that all the items are nodes. They can return true as soon as they have found that the sequence contains at least one item and that item is a node. For systems doing static type-checking, it's reasonable to allow them to treat a heterogeneous sequence as an error, so that they can treat the boolean() function effectively as polymorphic: they can decide statically which of four different boolean() methods is being used. This means that there are some cases that will work (return a result) with a dynamic typing implementation that fail (return an error) with a static typing implementation, but that's a normal state of affairs. The most common such cases are not those involving sequences that are actually heterogeneous, but those where the static type permits heterogeneity - and users of static type systems will be very familiar with such error messages. Michael Kay http://www.saxonica.com/ personal response
Michael, your arguments make sense to me. With the current specification in the Formal Semantics, however, things are slightly more subtle. > For systems doing static type-checking, it's reasonable to allow them to treat > a heterogeneous sequence as an error, so that they can treat the boolean() > function effectively as polymorphic: they can decide statically which of four > different boolean() methods is being used. Right now, the FS specification uses $arg <: (empty | node+ | xs:boolean | ...) to restrict the type of fn:boolean()'s argument. This does, however, *not* mean we can infer the implementation of fn:boolean() statically. Consider the query for $x in (<a/>, 42) return fn:boolean($x). The static type of $x is (element | xs:integer), which is a valid argument to fn:boolean() according to the FS. Yet, we cannot statically decide on an implementation of fn:boolean(). Would the constraint on $arg be $arg <: empty OR $arg <: node+ OR $arg <: xs:boolean OR ... , such a decision would be possible (with positive effect on performance, at least in our case). Would that make a reasonable replacement for the static type semantics of fn:boolean()?
My understanding of the issue is the same as Michael Kay's. I believe the specs are the way they are by design. I actually do not believe there is a contradiction. The static typing rules are clearly sound, although not the most accurate you could write. I believe each of the proposed rules (more precise, as in the spec, or more restrictive as Jens suggests) would work. I would have a personal preference for Jens's suggestion, however, changing the rules at this point may be a problem for some implementations. - Jerome
Jens, The XML Query and XSLT working groups has discussed your proposal for a more restrictive rule, and there are some concerns about whether that would outlaw too many common cases. One of the issue is that effective boolean value is used implicitely in the semantics of many expressions. At this point, the working groups believes that the current rules covers most of the cases that people care about and is a reasonable 80/20 cut. As a result the working groups prefer to keep the current rule as is. Please let us know if you have any more concerns on this. Best Regards, - Jerome Simeon, On behalf of the XML Query and XSL WGs