W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: ISSUE-81 (resource vs representation)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 07 Oct 2009 17:24:33 +0200
Message-ID: <4ACCB2B1.6040804@gmx.de>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: Larry Masinter <masinter@adobe.com>, Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>
Aryeh Gregor wrote:
> On Wed, Oct 7, 2009 at 3:56 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Incorrect. Many URIs can identify the same XXXX.
> 
> Then I'm not understanding here.  In what sense are those XXXXs then
> "the same", if their URLs differ?

It depends on the applied comparison function.

For instance...

<http://www.w3.org/>

<HTTP://www.w3.org/>

<http://www.w3.org:80/>

all identify the same resource.

Now you could claim that these URIs are indeed the same, and that also 
depends on which type of comparison you choose (see 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2>).

But of course servers can expose the same resource under many more names 
that differ just in the path or query component (for instance, consider 
a server that servers files from the file system, and the file system 
supports hard links). In those cases the same resource will appear with 
different path values.

>> If that is a good thing, why aren't we changing stuff like:
>>
>>> A DOCTYPE must consist of the following characters, in this order:
>>>
>>>   1. A U+003C LESS-THAN SIGN (<) character.
>>>   2. A U+0021 EXCLAMATION MARK (!) character.
>>>   3. A string that is an ASCII case-insensitive match for the string
>>> "DOCTYPE".
>>>   4. One or more space characters.
>>>   5. A string that is an ASCII case-insensitive match for the string
>>> "HTML".
>>>   6. Optionally, a DOCTYPE legacy string (defined below).
>>>   7. Zero or more space characters.
>>>   8. A U+003E GREATER-THAN SIGN (>) character.
>> ???
> 
> I don't know.  That could certainly be made a lot more concise without
> sacrificing precision.

See? I'm all for precision and conciseness, I just do not see that rule 
applied in this particular context :-)

BR, Julian
Received on Wednesday, 7 October 2009 15:25:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:50 GMT