Re: [apps-discuss] FYI: LINK and UNLINK

On 07/11/2013 01:15, Manger, James H wrote:
>> http://www.ietf.org/id/draft-snell-link-method-07.txt
>>
>> Per Julian's suggestion, accommodates all target attributes, deals
>> with 2xx response codes, handles use of the anchor attribute to
>> override the context IRI. Also, deals with equivalence checking for
>> IRIs.
>
>
> The root cause of the arguments about which link attributes are "significant" is that 1 link syntax is being used for 2 distinct purposes.
>
> 1. With the LINK method, a Link header provides a complete link to add.
>
> 2. With the UNLINK method, a Link header provides criteria for matching existing links to remove.
>
> The Link header is designed to provide a complete link. It is not designed to convey criteria for matching links. It can approximately serve the latter purpose if you add a rule. Possible rules are:
> A) "a link matches only if every attribute is exactly the same"; or
> B) "a link matches if the attributes provided match, regardless of any other attribute is has"; or
> C) "a link matches if the values and presence of 6 specific attributes match (rel, hreflang, ...)".
>
> A better design would be to acknowledge that specifying a link and specifying criteria for matching links are different things. That could be reflected by defining an Unlink header to hold matching criteria. We could drop the UNLINK method and just include Link and Unlink headers when using the LINK method.
>
> The Unlink header could use a syntax like Link; probably with rule B (all attribute in the Unlink value must match, but a link still matches if it has additional attributes); perhaps with an optional extra=false attribute meaning links with additional attributes do not match.

I had a similar problem when reading the updated draft: it's not clear what an 
UNLINK actually removes.

I'm uncertain about whether this is the right response, but it seems like a 
plausible approach to me.  I kinda like the idea that it would allow links to be 
changed (remove+add) atomically.

#g
--

Received on Thursday, 7 November 2013 09:41:32 UTC