Re: Uniform access to descriptions

Jonathan Rees wrote:
>
>
> On Apr 8, 2008, at 6:45 AM, Phil Archer wrote:
>
>> Can I ask whether those interested in this issue feel that there is 
>> an emerging consensus? If so, would anyone care to take a stab at a 
>> timeline for an eventual resolution? If not, might it be worth 
>> setting up an ad hoc telecon some time so we can discuss it?
>>
>> I ask because POWDER is now working towards making a Last Call 
>> announcement at the end of the month with a view to reaching CR 
>> before we all disappear on summer holiday. It would clearly be 
>> advantageous if we can have a clear idea of where the HTTP Link (or 
>> alternative solution) is likely to be by then.
>>
>> Thanks
>>
>> Phil.
>
> Yes, I see the need for action.
>
> There appears to be consensus on Mark's RFC draft among a certain 
> contingent, in which I would include roughly POWDER, Atom, Tabulator, 
> and RDF (here I refer to the various mentions of Link: in various RDF 
> specs over the past ten years). We have some thoughtful naysayers, 
> some of whom prefer different solutions (but have not contributed use 
> cases), while others are simply critical.
Jonathan,

If this is the Mark's RFC draft that you are talking about 
http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt, 
then I wish you can carefully review what it is purpose.

The following is what I have privately communicated with Harry, here I 
recite:

"Honestly, after I read the Nottingham's draft, I dislike it even 
more.   The LINK header is essentially a "cute" way to move some of the 
RDF assertions into the HTTP headers. If you exam the proposed Link 
header more closely, they are more or less the Dublin Core.  What it 
will lead to is what you described as "transclude" all URIs into the 
headers.  It is very dangerous and very bad.  Consider the copyright 
LINK. If the content carries a copyright statement, which is different 
from the LINK's copyright?  Which one is the right one?".

When we make architecture decision, we should define its role with 
respect to the architecture.  The very founding principle of the web is 
the principle of orthogonal specification.  The proposed LINK is 
breaking this orthogonality by mixing the assertions of the message 
content with that of the message transportation. 

If you take away all these DC-like LINK headers in Mark's draft and take 
a careful look what can be left, then you will find they are essentially 
the same issue that can be dealt in Conneg. Hence, we should either 
choose Conneg or LINK but not both because doing the later once again 
breaks the principle of orthogonal specification.  Then, it should be up 
to TAG's decision which one to adopt or drop. 

Xiaoshu

Received on Tuesday, 8 April 2008 14:33:59 UTC