W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2003

[FO]: OB01 escape-uri

From: Oliver Becker <obecker@informatik.hu-berlin.de>
Date: Mon, 1 Dec 2003 17:05:07 +0100 (MET)
Message-Id: <200312011605.hB1G57c9023841@mail.informatik.hu-berlin.de>
To: public-qt-comments@w3.org

The wording in 7.4.10 fn:escape-uri of the Functions and Operators WD
seems to suggest that the percent sign '%' is not escaped if $escape-reserved
is false. (Because '%' is neither a reserved character in RFC2396 nor in

If I'd be picky then the wording

"If $escape-reserved is false, the behavior differs in that characters referred 
to in [RFC 2396] and [RFC 2732] as reserved characters, together with the NUMBER 
SIGN '#' character, (See [Uniform Resource Identifiers (URI): Generic Syntax]) 
are not escaped. These characters are ..."

tells me that *only* these reserved characters will be not escaped.

The rules would be easier to understand if it could be rephrased along
the lines:
- Regardless of $escape-reserved the following characters will be escaped: ..
- If and only if $escape-reserved is false then additionally the following 
  characters will be escaped: ...
Last comment: the sentence (at the beginning of this section)

"The effect of the function is to replace any special character in the string by 
an escape sequence of the form %HH, where HH... is the hexadecimal 
representation of the octets used to represent the character in UTF-8."

could be interpreted as to generate one % and then the hex representations
of all UTF-8 octets. Especially the "HH..." seems to suggest this 
interpretation. Perhaps the phrase "an escape sequence of %HH parts" or
something like that makes the intention clearer and unambiguous.

Oliver Becker

|  ob|do        Dipl.Inf. Oliver Becker                             |
|  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
|  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
Received on Monday, 1 December 2003 11:05:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:15 UTC