- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Wed, 26 Mar 2008 10:42:28 +0000
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- CC: Richard Cyganiak <richard@cyganiak.de>, leo.sauermann@dfki.de, www-tag@w3.org
Henry, > Our recommendation is to err on the side of caution: Whenever an > object of interest is not clearly and obviously a document (all its > essential characteristics can be conveyed in a message), then it's > better _not_ to respond with a 200 to a request for the URI > identifying it. > The issue about the above paragraph is this: no one will ever know if all its essential characteristics is conveyed in the message because beauty is in the eye of beholder. When we publish something, the intent is for someonelse's to judge. Hence, how do we know if others think that we conveyed *all* characteristics? For instance, Pat Hayes thought he did with his famous URI, but obviously, not every agree with that. To avoid the potential *mistake*, we should always 303 - that makes us always correct but also unknown because every HTTP-GET is an eternal 303 loop. If there is no one to judge it, such as by the proposed 200="IR", then it is fine but also makes the 303 irrelevant. But if we intent to invoke that logic, hence, for any content publisher, s/he has too choices. (1) To make it always correct, then always 303 but 200. This makes web useless. (2) To not afraid making mistakes, then why 303 when we can 200? There is no middle ground. Adopting TBL's concept is fine too - that is to use # to identify something external to web and "/" in the web, which makes any slash URI not logical-judge-able. Although this partitioned URI space in two parts - one is logical judge-able (# URI) and the other not (slash URI). But that can still work. The only way that cannot work is the current compromised solution. The concept of IR and httpRange-14 has caused more damage to the web than anything-else. All the new httpXXX-nn issues are all derived by it. But what problem that httpRange-14 has solved? None. All the newly proposed solution is to *avoid* httpRange-14 but *embracing* it, I think we should realized how *bad* the httpRang-14 is. I sincerely wish TAG to reconsider httpRange-14. Settling down on a clearly defined and usable concept of IR (or simply abandon it) before doing anything-else. Ambiguous definition can only lead to ambiguous solutions. Hence, all those solution to httpXXX-nn issues will be proven in the long term a waste of time. Because they either (1) avoided the httpRange-14 in such that no-one ever to use httpRange-14, but this leads to the cause of their solutions a non-cause, or (2) their own solution will eventually conflict with httpRange-14 again, hence eventually TAG has to settle the latter. But if the latter is eventually settled, then it makes all other previous effort a waste of time. My suggestion to TAG and other people on this list. To halt our effort on other issues derived from httpRange-14, and resolve the httpRange-14 NOW. Xiaoshu
Received on Wednesday, 26 March 2008 10:43:14 UTC