This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2545 - EBV (fn:boolean) and xs:anyURI
Summary: EBV (fn:boolean) and xs:anyURI
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows 2000
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-11-21 16:07 UTC by Mary Holstege
Modified: 2006-11-16 18:49 UTC (History)
0 users

See Also:


Description Mary Holstege 2005-11-21 16:07:06 UTC
It would be more consistent if EBV of xs:anyURI values worked
as if they were xs:string values, rather than throwing type

Inasmuch as EBV is defined by reference to fn:boolean,
and xs:anyURI values can in general be promoted to xs:string,
this would seem to be the case. On the other hand, the rules
given for fn:boolean speak of specific argument types and say that
in any other case, a type error is raised.

We believe an explicit clarification for xs:anyURI is in order here.
Comment 1 Frans Englich 2005-11-21 16:42:35 UTC
Whether the EBV extraction of xs:anyURI("") yields a type error or  
not, I think can be concluded like this:  
The argument type of fn:boolean is item()*. For this reason is no atomization 
or type promotion invoked, as according to the Function Conversion Rules in 
XPath20. Thus, the body of fn:boolean is passed an xs:anyURI instance, and  
according to fn:boolean's definition xs:anyURI are not EBV-extractable and 
hence yields an error.  
* Saxon accepts "<xsl:if test="xs:anyURI('')">" and evaluates it to  
true, so this is an indication in another direction.  
* Type promotion, especially involving xs:anyURI, is vague in other areas as  
well. It looks like these are editorial bugs, not design problems or  
unconsidered aspects.  
It will be interesting to hear what the WG members say. If one looks on prior 
cases(such as #2324), it wouldn't surprise me if EBV extraction from xs:anyURI 
should be allowed. I wonder if it makes sense though for xs:anyURI. 
A similar case is:  
I agree clarification would be helpful. An example involving xs:anyURI and 
fn:boolean would likely settle all confusion. 
Comment 2 Michael Kay 2005-11-21 17:19:02 UTC
I think there's no doubt that in the current specs it's a type error to get the
EBV of an xs:anyURI value. I don't feel strongly either way about changing it.

Contrary to what Frans reports, Saxon 8.6 does report this error on xsl:if -
though only at run-time (the static type checking can't yet handle a required
type of this complexity)

Michael Kay
Comment 3 Michael Kay 2005-11-21 17:47:32 UTC
Frans is right about Saxon after all, it is sometimes (incorrectly) allowing an
anyURI in an EBV context.
Comment 4 Mary Holstege 2006-01-03 17:12:40 UTC
Resolved to fix this issue by adding an explicit reference to xs:anyURI
to bullet 4 in the description of fn:boolean in F&O (15.1.1) and where 
that text is repeated in the language document in the description of 
EBV (2.4.3)
Comment 5 Michael Kay 2006-01-03 18:17:00 UTC
An observation, in case anyone missed it (it didn't come up in discussion): this
change also affects the rules for evaluating predicates, which are very similar
to the EBV rules (and defined by relation to the EBV rules).

Michael Kay
Comment 6 Ashok Malhotra 2006-01-08 11:01:47 UTC
Fixed by adding an explicit reference to xs:anyURI
to bullet 4 in the description of fn:boolean in F&O (15.1.1) as
decided on the 2006-01-03 telcon.
Comment 7 Michael Kay 2006-01-08 14:11:54 UTC
Before closing this, please check that the changes to the language book (which
repeats the rules for EBV) have also been made.