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 following text in "3.1.1 Literals" implies, but does not state, that fn:true() and fn:false() can be used to represent Boolean literals: "The xs:boolean values true and false can be represented by calls to the built-in functions fn:true() and fn:false(), respectively." This comes immediately after a list of examples of literals, and immediately before this text: "Values of other atomic types can be constructed by calling the constructor function for the given type." Do we intend to allow these to be used as literals? The grammar does not support them. We need to clarify this text one way or another.
The function calls true() and false() are not literals, but they fulfil the same role as literals, in that you can use them in an expression anywhere you can use a literal. I think that's what the text is trying to say.
Related to this, in section 4.15 Annotations it states: "An annotation always has a value. If no explicit value is provided, the value is fn:true(). " But the grammar for an annotation is: [27] Annotation ::= "%" EQName ("(" Literal ("," Literal)* ")")? So it seems that a user can not set the value of an annotation to fn:false() which is strange given the default value is fn:true()?
The Working Group decided to fix this by removing the last sentence in the following excerpt: (In reply to comment #2) > Related to this, in section 4.15 Annotations it states: > > "An annotation always has a value. If no explicit value is provided, the value > is fn:true(). " Editorially, the following may be clarified: "The xs:boolean values true and false can be represented by calls to the built-in functions fn:true() and fn:false(), respectively."
This has now been fixed.