- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Fri, 11 Apr 2008 21:28:21 +0000
- To: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "wangxiao@musc.edu" <wangxiao@musc.edu>
- CC: Jonathan Rees <jar@creativecommons.org>, Phil Archer <parcher@icra.org>, Pat Hayes <phayes@ihmc.us>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org WG" <www-tag@w3.org>
> From: noah_mendelsohn@us.ibm.com
> [ . . . ]
> So, I think the best we can do is to make a statement that says:
>
> If HTTP(x)=200 then either
> (a) x=IR
> - or -
> (b) the resource has been
> deployed incorrectly
> - or -
> (c) x falls into an edge
> case about which users
> of the Web disagree
That sounds more like the choices that a particular application might make -- not what the archiecture should say. The *architecture* can and should be clear:
If HTTP(x)=200 then x is an IR.
However, a given application may choose to recognize that the architecture is sometimes violated, and hence may choose to assume that case b is a possibility, perhaps because of c. But from an architectural perspective, the rule above can and should be absolute.
If indeed the URI owner erred, and meant to use the URI to denote a non-IR, and even published a URI declaration or other statements saying that the URI denotes a non-IR, then from an architectural perspective all that has happened is that the URI owner has published conflicting information:
- as evidenced from the HTTP 200 response; and
- as evidenced from the URI declaration or other statements.
>From an architectural perspective, it would be considered a URI collision:
http://www.w3.org/TR/webarch/#URI-collision
David Booth, Ph.D.
HP Software
+1 617 629 8881 office | dbooth@hp.com
http://www.hp.com/go/software
Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Friday, 11 April 2008 21:30:13 UTC