Subject: Re: [core] application/link-format & non CoRE applications

From: Zach Shelby <[email-masked]>
Date: Mon, 2 Jan 2012 19:15:25 +0200

Herbert,

On Dec 15, 2011, at 11:50 PM, Herbert van de Sompel wrote:

> 1. Approach that allows using an off-the-shelf Link header parser
> 
> This approach requires that the content of an application/link-format document fully conforms to the "link-value" production rule of the ABNF of RFC 5988. As a result, whatever is put in place to implement the "sticky anchor" will be interpreted as a link. 
> 
> My original proposal fits into this category, but probably was inappropriate because the add-on I proposed looked too much like a "real" link. Maybe it's better to go for something that conforms to the syntax of a link but doesn't really make sense as a link, i.e. does not introduce the risk of applications interpreting it as a "real" link. 
> 
> Within this category, we thought the following could work:
> 
> <> ; anchor="the-actual-Context-IRI" , link, link, link, ...

This would apply only to that one link. But I actually think you're on the right trail here. Let's think it through:

The Context IRI needs to be assumed somehow. In HTTP Link Header it made sense that it was the Request URI. In this Link Format we assume it is the Base URI. Alternatively, this is overridden by the presence of the "anchor" attribute for a single link. Now we need a way to override the context for all the links in a document rather than a single one. In my mind, the right way to do that would be to define a new relation type "context" and use it to assign a new assumed context for all the links in the document.  So this would look like:

<the-actual-Context-URI> ; rel="context", link, link, link, ...

Now the trick is that the definition of this "context" relation type needs to assume a Context URI of that document itself, not a problem if defined so.

I am not sure that the CoRE Link Format is necessarily the right place to define this new relation type, although I am not against that either. It might make more sense to define this as a separate draft. 

> 2. Approach that requires some changes to an off-the-shelf Link header parser
> 
> In this case, we could go beyond the syntax defined in the ABNF in order to add the "sticky anchor". Devising a solution then comes down to finding a verbose syntax that remains easy to parse. The latter includes deciding on an appropriate delimiter. Understanding Carsten doesn't want "lines", maybe using e.g. a pipe character "|" as a delimiter could be an approach:
> 
> | the-actual-Context-IRI | link, link, link, ...
> 
> or, if extensibility regarding metadata to these files would be required, even:
> 
> | ContextIRI the-Context-IRI | Date the-date | link, link, link, ...

This seems like a hack to me, would avoid it.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297