W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2005

[Bug 1502] [F&O] escape-uri encompasses & s/b split into 2 distinct functions

From: <bugzilla@wiggum.w3.org>
Date: Fri, 17 Jun 2005 03:55:47 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1Dj7xL-00034O-Aq@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1502





------- Additional Comments From mike@saxonica.com  2005-06-17 03:55 -------
TimBL>Michael (Kay), the two functions are *quite different* as I understand it.
 It is not that one operates on 
part and the other on a whole URI.  You can feed a whole or part URI to either.

MHK>I don't think there is any disagreement that the two operations are
different, or about the definition of the two operations, or about the reasons
why we need to provide both. The question is how to package the two operations
to maximize ease of use. 

That's why I suggested names based on the recommended use cases for the two
functions. One of them is there to allow you produce a URI from a wannabe-URI (I
wish we had a better name for the thing), the other is there to enable you to
produce a component of a URI from an arbitrary string. 

We've always had to recognize that the name of a function can't encapsulate the
entire semantics of what the function does; the main aim is to choose names that
users will find easy to remember and distinguish. 

>From that perspective, I don't think that "clean" is a good name, because it
doesn't even hint that the function has anything to do with URIs, and it's quite
unrelated to the terminology of the RFCs that describe the operation in more
detail. 

"encode-for-uri" is a more reasonable suggestion, since it's related to the term
"percent-encoding" used in RFC 3986 (replacing "escaping" in RFC 2396). But the
verb "escape" to describe this operation is well-entrenched in other W3C
specifications (XSLT 1.0, HTML, XLink) and therefore in the consciousness of the
user community, while the verb "encode" reminds one of the unfortunate history
in which the result of this operation at one time depended on the character
encoding of the containing document. I don't think one can argue that "encode"
is a better name for the operation because it's reversible: most escape
conventions are reversible too.

If we're going to insert a preposition to emphasize that it's the output that's
a URI, not the input, then "as" would be a better choice than "for".

TimBL:>Why would you want to perform both operations?

MHK>You wouldn't want to do so, I didn't intend to suggest that you would.

Michael Kay
Received on Friday, 17 June 2005 03:55:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:38 GMT