Re: Uniform access to descriptions

Xiaoshu Wang wrote:
[snip]
>> Actually, having Link headers with an URI extensible link relation makes
>> any request for "Link 2" or "Link 3" moot, since one can just use a Link
>> header. Also, you seem to be ignoring the fact that adding something
>> back that was accidentally deprecated and is actually supported by
>> existing software is a bad thing. Look, by your argument of "never
>> extend the protocol" we'd still all be on ARPANet. The idea is to make
>> the protocol cover the use-cases and not break and follow trends in
>> existing deployments.
>>   
> How so? i.e., to make "Link2" and "Link3" moot.  Your POWER usecase is
> for GRDDL profile.  What if there is another XRDDL profile that
> becomes popular a few years later?  What will the LINK be?  To abandon
> GRDDL? Or create a new LINK2?
You use the Link header to specify whatever type you want using link
relations to "type" the link as necessary in a decentralized manner.
Therefore, one could link to a GRDDL transform by saying

Link: <http://www.example.org/mytransfer>;
rel="http://www.w3.org/2003/g/data-view"

If in the future, there is some new technology (XRDDL?) that replaces
GRDDL, it can use the same Link header with a new URI in the link relation.

Link: <http://www.example.org/mytransfer>;
rel="http://www.example.org/xrddl"

Note that this topic has already been extensively discussed by the IETF
HTTP WG [1]. Please catch up on that discussion and by actually reading
Mark's latest draft [2].

In fact, the use of the Link header actively *prevents* the creation of
application-specific custom HTTP headers and adding of new content
types. Please read this example about how Gnutella added a new custom
HTTP header and how the exact same functionality could have been done
with a Link header [3]. I might add if you use Google you can find other
use-cases for the Link header, many by people who are abiding by RFC
2068. For example, here is someone using it to link to a CSS stylesheet
[4].

>> Look, of course a link is going to take another request, that's
>> why it's called a link to *another resource* not the same resource.
>>   
> No. You are arguing against yourself.  Href is the link when people
> read the content and make their choice.  But not the link
> automatically dereferenced.  What I am arguing is if people/client
> knows what kind of content-TYPE, not content, then s/he should know
> already know what they want.

 There is no reason why a person might not want multiple links to
different resources with the same content type. That's in the spec: "An
entity MAY include multiple Link values."

[snip]
>> Well, obviously the Web should work based on your likes and dislikes :)
>> However, HTTP headers do things other than parse the payload, ala
>> Location (which like Link can take a URI) and Age.
>>   
> But the meaning is different.  The redirect link tells you the content
> is not available.  i.e., the message is empty, and if you still want
> it, follow this link.  It is a different matter to say.  Oh, here is
> what you want.  But you may also want this!

Ah, perhaps this is a genuine misunderstanding rather than sheer
stubborn-headed argumentation for no good reason. Read Mark's latest
draft [2]. It is "Here is what you want, but you may also want this!" I
hope this clears up any misunderstanding. If you think the wording is
unclear, please send e-mail not to this list but the IETF HTTP WG list
and Mark Nottingham.

The wording probably could be improved. I believe the likely offensive
sentence is this one from RFC 2068 Sec 19.6.1.2. about the LINK method,
"The difference between LINK and other methods allowing links to be
established between resources is that the LINK method does not allow any
message-body to be sent in the *request* and does not directly result in
the creation of new resources." Although do notice the difference
between *request and response* - i.e. LINK is talking about POST here,
not replacing conneg or LOCATION. And this is about a LINK Request
method (and the UNLINK one), not the Link response header.

If you read Mark's draft, that rather difficult sentence is not in
Mark's draft, which is *only about the Link response header*, instead
there is just this simple sentence also directly taken from RFC 2068
"The Link entity-header field provides a means for describing a
relationship between two resources, generally between that of the entity
associated with the header and some other resource."



> Can you use LINK to automate a GRDDL transformation?  Wouldn't it be
> more meaningful and precise to designate a GRDDL mime-type and bound
> it transformation sheet to the same URI?  Instead of inventing some
> additional header?  Then, you can do so with any kind of X-RDLL
> language and the approach is always the same, which one is better?
Yes, obviously every new application should get a new mime-type :) I
think URI-extensibility and decentralization are good things, and in the
long-run prevent excessive adding of new mechanisms to HTTP, HTML, etc.
If you do not, that's fine, but I disagree.

> So, if it is so useful, why has it been dropped- because there is no
> use-case?  If there is still no valid use-case to suggest that
> existing HTTP spec is not sufficient, it also means that there is no
> argument for putting it back, right?
Again, don't comment about use-cases for putting it back till you
actually read the draft and catch up on the use-cases mentioned in the
various relevant forums which I have provided you links to. It creates
unnecessary traffic on this list (and a drain on my time, which is
unfortunately limited). Hope this helps.

[1]http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
[2]http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt
[3]http://changelog.ca/log/2006/06/17/gnutella_does_not_need_the_x-alt_http_header
[4]http://www.martinpayne.me.uk/experiments/www/HTTP/Link/HTTP-Link-example.html


> Regards,
>
> Xiaoshu


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Tuesday, 25 March 2008 01:35:09 UTC