W3C home > Mailing lists > Public > www-tag@w3.org > April 2009

Re: ISSUE-60: Name of draft should be changed to refer to URI's not URL's

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 6 Apr 2009 14:32:12 -0400
To: John Kemp <john.kemp@nokia.com>
Cc: "www-tag@w3.org WG" <www-tag@w3.org>
Message-ID: <OF90EAD73F.C79BEB42-ON85257590.0065397F-85257590.00657B3C@lotus.com>
John Kemp writes:

> My citing of 2141 was somewhat of a red-herring,

OK, no problem, maybe that's what threw me off a bit.  I now understand 
you to be saying that you're sympathetic with the change from URL -> URI 
in general, but are observing that some of the particular statements in 
the draft don't apply to all URI schemes.  I agree with that.  So, this 
all will be good input to Raman for subsequent revisions to the draft. 
Thank you for the clarification;  I'm sorry I didn't understand your 
concern the first time.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








John Kemp <john.kemp@nokia.com>
04/03/2009 08:49 AM
 
        To:     "ext noah_mendelsohn@us.ibm.com" 
<noah_mendelsohn@us.ibm.com>
        cc:     "www-tag@w3.org WG" <www-tag@w3.org>
        Subject:        Re: ISSUE-60: Name of draft should be changed to 
refer to URI's not URL's


Hi Noah,

On Apr 2, 2009, at 7:08 PM, ext noah_mendelsohn@us.ibm.com wrote:

> John: on today's call, I promised a bit of a followup.

Thank you for doing so.

>
>
> John Kemp wrote:
>
>> What would a '#' mean in a URN? RFC2141[1] suggests that '#' is a
>> reserved character, and would thus
>> require escaping.
>
>
> I'm not quite sure why URNs are coming up as a big consideration 
> wrt/ this
> change.  RFC 3986 [1] is the syntax for all Web identifiers, 
> including for
> example those using the http scheme.  So, the main reason that some 
> of us
> pushed to change URL to URI in the title and content of the draft is 
> that
> it's the preferred initialism for the identifiers we're discussing,
> including those that use http.

Yes, I understand that. As I noted in my email review [1] of the 
document, I even suggested myself that this change be made.

[...]

>
> [1] http://www.ietf.org/rfc/rfc3986.txt

I am not arguing with RFC 3986. I understand that document to be quite 
emphatic in its guidance.

My citing of 2141 was somewhat of a red-herring, but reading that 
document is what caused me to actually think a bit about the change 
from URL to URI.

My concern is about the draft of 'Hash in URIs' [2], which says, 
taking just a couple of examples:

'Designers of URIs have traditionally used ?  to encode server-side 
parameters' - what do 'server-side parameters' actually mean in the 
context of URNs (or non-HTTP URIs even)? Do they have meaning always? 
Does the document describe uses _beyond_  the use of ? as HTTP query 
parameters?

and,

'At its inception, the Web also introduced fragment identifiers 
(preceded by # ) as a means of addressing specific locations in a 
document.' - again, how does this apply in situations where a URI does 
not specify a retrieval algorithm?

What does:

'Create URIs for intermediate pages in a Web application so that the 
back button does the right thing' mean, when the client is not a Web 
browser (or even an HTTP user-agent)?

All of the examples given appear to use http: URIs. My sense is that 
this draft is currently talking mostly, and perhaps exclusively, about 
http: URIs, usually accessed within a Web browser context.

My suggestion is simply that the document ought to say exactly that (I 
think it's useful even if it does only talk about http: URIs), unless 
relevant use-cases beyond http: URIs can be elaborated in the 
document, and the language changed appropriately.

Regards,

- johnk

[1] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0144.html
[2] http://www.w3.org/2001/tag/doc/hash-in-uri.html
Received on Monday, 6 April 2009 18:31:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:13 GMT