Re: reference needed - w3.org versioned documents

Others such as Richard have responded well to it, but I worry that new  
people on this take it at face value.

On 2008-04 -03, at 13:02, Jonathan Rees wrote:

>
>
> On Apr 3, 2008, at 10:40 AM, noah_mendelsohn@us.ibm.com wrote:
>
>> Let's accept what you say above as true.  In that case do you believe
>> there is there significant value in sticking to the TAG's position on
>> httpRange14?  You're making the case that even with the existing
>> restriction that status code 200 is only for "information  
>> resources", a
>> typical Semantic Web application will still pretty much be  
>> depending for
>> success on the URI owner publishing further information about the
>> resource.  If that's the case, then why the fuss about 200? ...
>
> At the risk of drawing out the httpRange-14 debate, which so far I  
> have tried to avoid...
>

Well, thanks for trying. :)

> I agree with most of what you say, and your question is a perfectly  
> fine one. My answer is that IMO there is value in httpRange-14, even  
> if there isn't significant practical value.

Excuse me?  There was serious practical need to resolve the  
architecture.  Many things
were held up, but now can go (and have gone) forward given the  
resolution.

> I think that if we had some accepted way to provide metadata for 200- 
> responders then the need for httpRange-14 would be reduced, since  
> there would be another way to say what httpRange-14 wants a 200  
> status code to mean. Such an alternative would be superior since  
> unlike 200 it would not be overloading a message that people are  
> already using in some cases to mean something different.
>

People are not, in general, using the message to mean something  
different.  Remember that the web has been around for many years, and  
has been working, and people have been using URIs.


> httpRange-14 is useful in that if a 200 comes from a server that  
> adheres to it, AND you know that the server adheres to it, then you  
> learn that the thing is an IR, and therefore not a hen's egg or  
> doorjamb or protein function.

It was only when the semantic web community arrived and wanted to use  
these URIs in a consistent knowledge representation system  --  
relatively recently -- that one had to make it clear that when there  
was a web page about an egg, the URI denoted the page not the egg.

For some of us that has been clear for years, but it hadn't be written  
down clearly enough.

> The preconditions are a tall order,

Well, the URI is deemed to refer to the web page.    This applies to  
10^11 web pages already out there.   The architecture is such that the  
URI of a web page denotes it.   It is deemed to denote it.  It isn't a  
function of whether the server "adheres" to the idea, just as the  
ASCII 0x41 denotes 'a' is not a function of whether or not the writer  
of an ASCII document 'adheres' to the idea.

> and the result not terribly informative, and probably not useful to  
> a computational agent. But it's better than nothing, and might give  
> guidance to a human trying to understand the URI.

There is a huge loss if a system is built which confuses an egg and a  
page about an egg.    This resolution avoids the confusion, for those  
who might be confused.

> The utility of httpRange-14 is significantly reduced as long as not  
> all minters of URIs for non-IRs adhere to it. I have no idea what  
> the penetration of httpRange-14 is, but my guess is that it is and  
> will remain low.

It is huge. When you design a global system, you have some global  
parts of the design which everyone has to agree to.  That's the sort  
of thing the W3C and the ATG are there for.
As semantic web systems which actually infer things in a general way  
about the thing denoted, ad are capable of talking about pages and  
about eggs, are fairly new those designing them are are generally up  
date on HTTP-Range-14.  As Richard says, systems which break the rule  
(make statements inconsistent with HTTP-Range-14) mess up all kinds of  
software, and so they tend to be found and fixed.

Perhaps you move in circles less acquainted with the web architecture,  
and inclined to invent new systems without reference to existing  
conventions.

> The big win of httpRange-14, as I see it, is that it is a positive  
> affirmation of what was probably the intent of RFC2616, that a 200  
> response reflects some inherent connection (maybe even identity,  
> sometimes) between the information received and the referent of the  
> name (whatever it is, even if its identity is a secret), and not  
> just something that a third party has said about the referent. (The  
> correct thing to say here may be different, but that's OK, any kind  
> of positive statement is fine by me.) Even if it has no practical  
> effect, I think it's a bit of pedantry that provokes thought and  
> helps to influence people to be honest.

Wow.  Just so that I gauge the way you use terms, would you say that  
the statement that in the US the voltage between two flat power pins  
is 110v alternating current is also a bit of pedantry that provokes  
thought and helps to influence people to be honest?

They are both commonly shared agreements which allow things to work as  
opposed to break.

I can't work out whether you are trying to attack HTTP-Range-14  
because you don't like it, or really you are confused about how it  
works and why it is important, or whether you were trolling to stir  
things up.

Tim

> My two cents.
> Jonathan
>

Received on Monday, 7 April 2008 02:29:28 UTC