- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Mon, 28 Sep 2009 11:53:38 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org" <public-html@w3.org>
On Sep 27, 2009, at 4:18 AM, Maciej Stachowiak wrote: > > On Sep 27, 2009, at 3:53 AM, Ian Hickson wrote: > >> On Sun, 27 Sep 2009, Julian Reschke wrote: >>> >>> [...] there are parts of HTML5 which *do* use the traditional >>> definition: >>> >>> "A URL is a string used to identify a resource." -- HTML5, Section >>> 2.5.1, <http://dev.w3.org/html5/spec/Overview.html#terminology-0> >>> (the >>> fragid may be instable...) >> >> This is actually intended to refer to "bag of bits". It identifies >> a bag >> of bits in the same way that a telephone number identifies a >> person. Sure, >> if you call a number at different times you might end up with >> different >> people, but you're still using a phone number to identify a person, >> you >> just don't know which one until you try to use the phone. >> >> It may be that you disagree with the meaning used for the word >> "identify" >> here as well; it's being used in the sense of "give enough >> information to >> obtain", not the sense "provide a name for" (the latter being the >> meaning >> often used in Semantic Web circles for the word "identify"). > > It seems like it would be more painstakingly accurate to say "A URL > is a string used to retrieve a resource" completely wrong because you may not bring back any resource at all. Think of the tel: or mailto: URIs which are perfectly legal to use in HTML. > or "A URL is a string that provides the address of a resource." This is the standard definition of URL and I don't see why a new one is required. It is about as painstaking as spelling A, B, C, D. > But even that is not quite accurate, because in the case of HTTP, > it's the full HTTP request (including method and headers) that > determines what resource you get, if you take resource to be the > concrete octet sequence you get back. Again this is misleading since without the URL, which provides the address, the rest of the HTTP request is meaningless. Besides, you are unnecessarily limiting yourself to HTTP, when URLs are beyond just HTTP. > > In any case, I don't think this kind of wording discussion is best > handled through the issue tracker. > What is then the best way to handle this? We already ruled out bug tracker, now issue tracker. What are we left with then? LC comments? Nikunj http://o-micron.blogspot.com
Received on Monday, 28 September 2009 18:56:26 UTC