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...




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 

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 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:52 UTC