This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We appreciate the achieved simplifications of EBV. We still would prefer if EBV could be simplified further by disallowing numeric and string value and only provide that semantics for fn:boolean which then could be used by the XPath 1.0 backwards compatibility mode to deal with the XSLT expectations. We would like to see EBV to be: · If $arg is the empty sequence, EBV is false. · If $arg is a sequence whose first item is a node, EBV is true. · If $arg is a singleton value of type xs:boolean or a derived from xs:boolean, EBV is $arg. · In all other cases, EBV raises a type error [err:FORG0006]. Then define fn:boolean() as · If $arg is a singleton value of type xs:string or a type derived from xs:string or xdt:untypedAtomic, fn:boolean returns false if the operand value has zero length; otherwise it returns true. <= Raise an issue, recommend EBV to not do it, and let XSLT stylesheets use fn:boolean() instead for backwards-compat. · If $arg is a singleton value of any numeric type or a type derived from a numeric type, fn:boolean returns false if the operand value is NaN or is numerically equal to zero; otherwise it returns true.<= Raise an issue, recommend EBV to not do it, and let XSLT stylesheets use fn:boolean() instead for backwards-compat. · In all other cases, fn:boolean results in the EBV of $arg.
1.0 compatibility mode exists to deal with the cases where we have had no choice but to introduce incompatible changes. It doesn't give us free license to introduce incompatible changes whenever we can think of ways of improving the design. We have a responsibility to keep the cost of transition from 1.0 to 2.0 to a minimum, not just to provide a compatibility mode that allows people an easy path for the first half of that transition. I don't think this change in the design has sufficient benefit to justify the high costs it will impose on many of our existing users, and the resulting damage to our reputation. Michael Kay
Michael, A joint meeting of the Query and XSLT working groups considered this comment on July 20, 2005, and decided not to make a specification change. Factors influencing this decision included the backward compatibility issue raised by Michael Kay in comment #1, and reluctance to introduce an inconsistency between Effective Boolean Value and the fn:boolean function. Please let us know whether you consider this to be an acceptable response to your comment. Regards, Don Chamberlin (for the joint working groups)
Microsoft Corporation has raised a formal objection to the working group's resolution of this issue. Michael Rys has explained this position in http://lists.w3.org/Archives/Member/w3c-xsl-query/2005Sep/0055.html "We understand the backwards-compatibility implications of the proposed change, but we feel that the improved semantics and simplicity of the proposal as outlined in the comment would improve the usability and adoption of XQuery. We are of the opinion, that we have now the chance of fixing some of the warts of the earlier design to not affect XQuery 1.0 going forward, and we are disappointed that the XQuery WG decided to not take the step of providing the best forward-looking semantics while still providing some form of backwards-compatibility option as outlined in bug 1430."
Writing as scribe for the joint XQuery/XSL working group: The working groups considered Microsoft's objection at a joint meeting on 29 September 2005 and there was no other support for changing the disposition of the original comment.