Re: Uniform access to descriptions

Harry Halpin wrote:
> Xiaoshu Wang wrote:
>   
>>> I have not seen you give an argument about how the use of a "Link"
>>> breaks *anything* much less HTTP. In fact, Link was part of an earlier
>>> HTTP RFC 2068, and was apparently left out as an editorial oversight.
>>>   
>>>       
>> There are a few issues here.  Of course, adding things don't break
>> things.  It never does.  But it steers you away from standardization. 
>> What we would eventually want people to do is to just take one of the
>> few methods and get what they want.  Not by infinitely extending a
>> protocol.  Hence, proposing LINK, in fact, contradict what the title
>> of this discussion does - which is the "Uniform access".  I guarantee
>> you if we grant this exception, there will be other similar request
>> for making LINK2, LINK3, etc.
>>     
> 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?
>> I have argued earlier, if people know what kind of LINK they want, it
>> means they also know what kind of content type they want.  Using
>> content negotiation is cheaper because it takes one round trip but not
>> two.
>>     
> By that argument we should have links "transclude" all links
> automatically, because then people don't have to bother with following
> hrefs. 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. 
>> Second, the semantics of LINK is in fact incorrect.  I dislike the
>> general use of the word metadata.  HTTP headers are the "metadata"
>> about the message payload - NOT the "metadata" of resource.  (Of
>> course, this leads to my different viewpoint of what a URI
>> identifies.)  Hence, whatever is in the LINK should be, as all other
>> HTTP headers, about how to parse the payload and nothing-else. Using
>> HTTP LINK for the metadata of the resource that the URI identifies, in
>> fact, breaks the web's founding principle that tis the orthogonality
>> of protocol.  Which makes the HTTP LINK an even worse offense.
>>     
> 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!
>>> Here is the use-case as attached below. Note that we do not specify URIs
>>> for the XML documents, therefore rending the argument to "just use
>>> conneg" void
>>>
>>> >From GRDDL Use-Case document (I think Ian Davis wrote this part..):
>>>
>>> "Oceanic is part of a consortium of airlines that have a group
>>> arrangement for the shared supply and use of aircraft spares. The
>>> availability and nature of parts at any location are described by
>>> AirPartML, an internationally-agreed XML dialect constrained by a series
>>> of detailed XML Schema. Each member of the consortium publishes the
>>> availability of their spares on the web using AirPartML. These
>>> descriptions can subsequently be searched and retrieved by other
>>> consortium members when seeking parts for maintenance. The protocol for
>>> use of the descriptions requires invalid documents to be rejected.
>>> Oceanic wishes to also publish RDF descriptions of their parts and would
>>> prefer to reuse the AirPartML documents which are produced by systems
>>> that have undergone exhaustive testing for correctness. There is no
>>> provision in the existing schemas for extension elements and changing
>>> the schemas to accommodate RDF would require an extended international
>>> standardisation effort, likely to take many years. This means they
>>> cannot alter their XML documents to use GRDDL. Using the ability of HTTP
>>> Header Linking Draft to specify Link and Profiles for GRDDL
>>> transformation in HTTP Headers, Oceanic Consortium can serve RDF via
>>> GRDDL without altering their XML documents. "
>>>   
>>>       
>> Do you think that is a valid use case for a healthy argument?
>>     
> Ask Ian Davis, but that's how a lot of XML documents (spec) are in the
> wild. And again, you can't use conneg to automate a GRDDL transform. I
> suggest you read the GRDDL spec.
>   
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?
>> Your opinion is already decided by making XML spec non-modifiable and
>> by pre-determining "using the ability of HTTP Header Linking
>> *draft*".  Wouldn't it be better to say: "using the *existing* ability
>> of HTTP content negotiation ..."? Which way is better? Using currently
>> spec or extending it for something that it can already do?
>>     
> How about using the spec as it was written in RFC 2068 [1]. Perhaps you
> should actually take a look at that before throwing around accusations
> that thinks are being "added" for no good reason. Obviously the editors
> of RFC 2068 thought it was a good idea, and they seem to want it back,
> as does it seem the IETF HTTP WG. The only people against this seem to
> be, rather oddly, SemWeb heads who have their own favorite way of
> providing metadata. Which is fine, but why not allow people more options?
>   
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?

Regards,

Xiaoshu

Received on Tuesday, 25 March 2008 00:55:11 UTC