Re: Proposed rewrite for section 3.1

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