XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (90 page)

Most types in XML Schema are rather specific about exactly what is allowed in the value space of the type (for example,
xs:boolean
has two values,
true
and
false
), and how these values may be written in a source document (the lexical representation: with
xs:boolean
the values
0
,
1
,
true
, and
false
are permitted). Most types also define a
canonical lexical representation
for each value in the value space, which is the representation that will be chosen when a typed value is converted to a string.

For the
xs:anyURI
type, these definitions have been fudged. Though the wording makes it clear that the intention is for
xs:anyURI
items to hold a URI as defined in the relevant internet RFCs (the most recent is
http://www.ietf.org/rfc/rfc3986
), they stop short of saying that a schema validator is expected to check that the contents actually conform with these rules. There is good reason for this reticence: many commonly used URIs don't actually conform with the rules in the RFC, and in any case, the rules in the RFC are not always clear.

I have read some books on XML Schema that suggest that in the value space of
xs:anyURI
, the value is always escaped (as in the example
file:///My%20Documents/biog.doc
) and that conversion from the lexical form used in a source document to the value space should therefore cause this escaping to happen. This would mean that when you compare two
xs:anyURI
values, differences caused by one of them being escaped and the other not don't matter. This appears to be an incorrect interpretation of the spec. In practice schema processors often allow any string to be used as an
xs:anyURI
value, and they leave the string unchanged when converting it to its internal representation. This interpretation is endorsed by the draft XML Schema 1.1 specification, which clarifies the intention.

Although
xs:anyURI
is a primitive type in XML Schema, the XPath type system treats it almost as if it were a subtype of
xs:string
. In particular, you can pass an
xs:anyURI
value to any function or operator that expects a string, and it will be implicitly converted. Many of the functions in the standard library that you might expect to take
xs:anyURI
arguments (an example is the
resolve-URI()
function) in fact have a function signature that requires a string to be supplied. The special rule for promotion of
xs:anyURI
to
xs:string
ensures that either type is accepted.

Similarly, the promotion rule means that it is possible without formality to compare an
xs:anyURI
value to a string literal. The only downside of this pragmatic approach is that comparisons between
xs:anyURI
values are performed using the default collation, which might be quite inappropriate for comparing URIs. But this applies equally to some types derived from
xs:string
, such as
xs:NCName
. If you want a strict comparison, you can use the function
codepoint-equal()
instead of the
eq
or
=
operators.