Re: Proposed rewrite for section 3.1

Hi Xiaoshu,

I am editor of the document, comments below

It was Xiaoshu Wang who said at the right time 26.03.2008 11:42 the 
following words:
> 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. 
In terms of the specification of the HTTP protocol, there are guidelines 
how web browsers and other agents interpret the result of a HTTP call.
In terms of the end-user sitting in front of the screen, you are right.

> 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.
We changed the document a little to reflect that, but you should also 
NOT focus on section 3.1 for all-truth-that-there is. In fact, the rest 
of the document gives many tips when to use 303 and when to use 200, and 
in practice the #-uris are the preferred thing by TimBl.
Also, you can look into the references to practical implementers that 
are already using the proposed 303 solution (its been published since 
18.6.2005), so we are talking about something that works for some time 
already.

You are right in saying "its not easy to make the decision", but we see 
the document as the first of its kind explaining the proposed standards, 
surely more explanations and use cases will follow when more people have 
adopted the proposal.


>
> 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.
I am the editor of the document explaining the proposed http-range-14 
solution,
you suggest to rethink this solution  as such.
This does not affect the document "cool uris for the semantic web" that 
explains the solution - if TAG finds a new solution, there will be a new 
editor writing a new document.
But still, and this you probably know and agree on,
we need to explain the proposed http-range-14 solution
as is to help future participants in this discussion

best
Leo

> Xiaoshu
>


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann@dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________

Received on Friday, 28 March 2008 11:11:15 UTC