This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 2.4.5, URILiterals, says: "...however, no escaping normalization is applied." It's not obvious to me what "escaping normalization" is but I suspect it's something to do with representing special characters as %HH (an operation we are now required to call encoding rather than escaping, for reasons that, er, elude me). I think that the above phrase has nothing to do with ampersand-escaping. Specifically, I think that an ampersand in a URILiteral must be written as & just as an ampersand in a string literal is written. It might be useful (after CR, I guess) to add some clarification here. Michael Kay previously raised at http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2005Oct/0006.html
Here's a concrete proposal to resolve the problem: replace the sentence (in 2.4.5) The value of a URILiteral is whitespace-normalized according to the rules for the xs:anyURI type in [XML Schema]; however, no escaping normalization is applied. by As in a string literal, any PredefinedEntityRef (for example, &), CharRef (for example, •) or EscapeQuot or EscapeApos (for example, "") is replaced by its appropriate expansion. Certain characters, notably the ampersand, can only be represented using a PredefinedEntityRef or CharRef. The URILiteral is subjected to whitespace normalization as defined for the xs:anyURI type in [XML Schema]: this means that leading and trailing whitespace is removed, and any other sequence of whitespace characters is replaced by a single space (#x20) character. Whitespace normalization is done after the expansion of CharRefs, so writing a newline (say) as 
 does not prevent its being normalized to a space character. The URILiteral is not automatically subjected to percent-encoding or decoding as defined in [RFC3986]. Any process that attempts to resolve the URI against a base URI, or to dereference the URI, may however apply percent-encoding or decoding as defined in the relevant RFCs. Michael Kay
The WG accepted this proposal.