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

> Definitely appreciate the feedback but I'm definitely -1 on the idea
> of inventing a new "Unlink" request header. It's just not necessary. I
> also don't believe matching rules are required. The UNLINK will match
> if all the attributes provided match all the attributes of an
> established link. It doesn't need to be more complicated than that.

So to change the title associated with an existing link I need to do an UNLINK request to remove the existing one, then a separate LINK request to add the new one. I probably need a 3rd request: an initial GET (or HEAD) to get all the attributes of the old link so I can remove it.

Since I need separate UNLINK and LINK requests, modifying the title cannot be atomic. Ouch.

If I want to remove all rel=alternate links I can’t send 1 request with "Unlink: rel=alternate", but I need to read all existing links, select those with the rel of interest, then replay all those links in an UNLINK request (with an If-Match header in case there were other concurrent changes).

If a link has 2 rel values I assume I need to include both to remove the link. Do they have to be in the same order or does rel="alternate stylesheet" match rel="stylesheet alternate". I wonder what an extraneous space in a rel value would do? The link is likely to work, but an UNLINK request will probably fail.

If I GET an HTML doc that has <link>s, I hope it includes all the attributes of those links otherwise my attempt to remove a link will fail. I hope I can translate HTML attribute values into HTTP header parameter values (doing that RFC2231 paramname*=%-escaped stuff) otherwise I cannot remove links.

If an XML <link> element has an xmlns attribute I assume I don’t translate it to an HTTP Link header parameter when doing an UNLINK request. Is it obvious which XML attributes to include and exclude?

I think splitting Link changes into separate LINK and UNLINK requests is a significant flaw. To fix that you need a separate way to express link removal (eg an Unlink HTTP header is one option), and that way would be more useful with a more lenient matching rule.

James Manger

> On Wed, Nov 6, 2013 at 5:15 PM, Manger, James H
> <> wrote:
> >>

> >>
> >> 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.
> >
> >
> > --
> > James Manger

Received on Friday, 8 November 2013 03:55:20 UTC