Re: Uniform access to descriptions

Xiaoshu Wang wrote:
> 
> Stuart,
> 
> Hold on.  Let's go one step at a time.
> 
> We agree that there are legacy data, yes?  Let's make its URI x, whose 
> owner is Joe.
> Case 1. Joe is lazy.
> Then, no LINK, no Conneg. Is this fair?

Not really. The site owner (who may be != Joe) could configure the 
server to return a Link header, without having to touch the resource itself.

(BTW: this can be used in practice to assign CSS stylesheets to "legacy" 
HTML content -- as far as I recall this works in FF and Opera).

> Case 2: Joe is not lazy.
> (a) Joe makes LINK(x)=metadata.
> (b) Joes make Conneg(x)=metadata (can easily GET x Accept 
> application/rdf+xml).

As others have pointed out, conneg is for negotiating different 
representations for the *same* resource, not for indicating relations to 
other resources.

Take the CSS example from above -- how would you implement that using 
Conneg???

> I think your later use case is assuming Joe is lazy toward (b) not not 
> (a).  I don't understand why it has be so.  In fact, Joe should be lazy 
> toward (b) because Conneg is in the current HTTP spec but not LINK.
> If Joe doesn't have any preference, see if all you later provide use 
> case can be solved with Conneg.  If you give me a use case with the 
> assumption that requires Joe to use LINK, then, what can I say?
> 
> I said to Harry before, if the LINK is in current HTTP spec, my position 
> will be reversed.  It is not about if LINK won't work.  It is about if 
> existing system can still make it work.

Well, the "Link" header is in RFC 2068, but not in RFC 2616 (which is 
the "current" spec).

However, as Roy pointed out, the only reason why Link is in RFC 2068 and 
not in 2616 was for procedural reasons, not by a conscious design 
decision. Also, it *is* implemented in the real world.

As such I'm not really sure how it matters where it is defined (for 
*this* discussion).

BR, Julian

Received on Saturday, 12 April 2008 07:27:59 UTC