Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 10:47:47 +1000

[Follow-ups set to Apps-discuss]

FYI; a few people have asked me about this recently, and URI Template is final, so it seems like a good time.

Cheers,

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-link-template-00.txt
> Date: 3 July 2012 10:44:09 AM AEST
> To: [email-masked]
> 
> 
> A new version of I-D, draft-nottingham-link-template-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Filename:	 draft-nottingham-link-template
> Revision:	 00
> Title:		 The Link-Template HTTP Header Field
> Creation date:	 2012-07-03
> WG ID:		 Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-link-template-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-nottingham-link-template
> Htmlized:        http://tools.ietf.org/html/draft-nottingham-link-template-00
> 
> 
> Abstract:
>   This specification defines the Link-Template HTTP header field,
>   providing a means for describing the structure of a link between two
>   resources, so that new links can be generated.
> 
> 
> 
> 
> The IETF Secretariat

--
Mark Nottingham   http://www.mnot.net/

---

From: Erik Wilde <[email-masked]>
Date: Mon, 02 Jul 2012 18:48:29 -0700

hello mark.

>> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-link-template-00.txt

this looks like a very useful initiative! however, for more complex 
templates, it may be too limiting to only allow variables from "one 
namespace" (i.e., from the one URI prefix you currently allow). for 
example, we are looking into search services, and it is actually highly 
likely that different variables in the templates will come from 
different namespaces, for example for basic search, paging, spatial 
aspects, and facet information. i don't have an easy answer how to best 
do it (and think the current design is actually quite elegant), but from 
the perspective of more complex templates, it seems to me that 
supporting multiple namespaces would be a requirement.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 11:58:09 +1000

On 03/07/2012, at 11:48 AM, Erik Wilde wrote:

> this looks like a very useful initiative! however, for more complex templates, it may be too limiting to only allow variables from "one namespace" (i.e., from the one URI prefix you currently allow). for example, we are looking into search services, and it is actually highly likely that different variables in the templates will come from different namespaces, for example for basic search, paging, spatial aspects, and facet information. i don't have an easy answer how to best do it (and think the current design is actually quite elegant), but from the perspective of more complex templates, it seems to me that supporting multiple namespaces would be a requirement.

Yep, agreed. The syntax of the header is somewhat limiting. Possible approaches to this that pop into mind:

* Define a prefix for variable to uri mappings; e.g., 
   _foo="http://example.org/vars/foo"
   ... but that potentially conflicts with other future parameters, and I'm not a big fan of this approach elsewhere

 * Define another header, e.g.,
    Link-Template-Vars: foo="http://example.org/vars/foo"
    ...which is OK but it'll get awfully verbose (maybe defining a base and some fallback rules? could get complex)

and so on.

Intuitively, I think we need a simple solution that addresses the common case (all vars in one namespace) without much fuss/overhead, but enough flexibility to address the complex case. That might be a combination of a base URI and another header.

I'd love feedback on this.

Cheers,

---

From: Erik Wilde <[email-masked]>
Date: Mon, 2 Jul 2012 19:18:39 -0700

hello mark.

> Intuitively, I think we need a simple solution that addresses the common case (all vars in one namespace) without much fuss/overhead, but enough flexibility to address the complex case. That might…

agreed that it should be simple to use for non- or one-namespace users. but we definitely need the multi-namespace case, so i'll think a little about how that could be accomplished. (we could invent a general "xmlns"-like header for all-header-scoped URI/prefix bindings, but i am sure a lot of people would not want to see xmlns mirrored so closely in HTTP.)

cheers,

dret.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 12:25:44 +1000

> agreed that it should be simple to use for non- or one-namespace users. but we definitely need the multi-namespace case, so i'll think a little about how that could be accomplished. (we could inven…

Yes. Also, I think the *really* common case is going to be for the variables to be defined by the link relation itself....

Cheers,

---

From: Graham Klyne <[email-masked]>
Date: Tue, 03 Jul 2012 10:26:23 +0100

> I'd love feedback on this.

The use-cases I have for this don't depend on the variable names being URIs.  My 
own take is that it was up to the defining application/API to explain how the 
variable names are related to known values, and then use the Link-template 
header to allow a service to describe how to map that information to a related URI.

So I'd be happy to see this aspect of the spec dropped if it's likely to lead to 
complications (and delay).

But, of course, others may have burning use-cases of which I'm unaware, so this 
is clearly just one voice among many of what is actually useful to define here.

#g
--

---

From: Erik Wilde <[email-masked]>
Date: Wed, 04 Jul 2012 10:00:07 +0200

hello all.

On 2012-07-03 11:26 , Graham Klyne wrote:
> The use-cases I have for this don't depend on the variable names being
> URIs.  My own take is that it was up to the defining application/API to
> explain how the variable names are related to known values, and then use
> the Link-template header to allow a service to describe how to map that
> information to a related URI.

i think that's the use case that mark serves well in the current 
approach (mapping to URIs is optional).

> But, of course, others may have burning use-cases of which I'm unaware,
> so this is clearly just one voice among many of what is actually useful
> to define here.

the question is whether you're interested in scenarios where you make 
parameters reusable across link templates and relations. currently, 
there is no standardized way how to "register URI parameters", and maybe 
that's something worth looking into. our scenarios are something along 
those lines:

- we have paged feed scenarios with random access, where we have 
well-defined parameters that allow clients to construct URIs of result 
sets, based on page sizes and a page index.

- we want to reuse these concepts in a variety of cases where the actual 
results mix in other parameters, such as for spatial search, and faceted 
search. a template should be able to mix-and-match parameters and do 
that in a way that uses the globally unique URI parameter identifiers.

so a question i am interested in looking at would be the following: 
would it make sense to consider a "URI parameter registry", so that 
syntax and semantics of URI template parameters could be made reusable 
across media types and/or link relations?

cheers,

dret.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Jul 2012 11:59:32 +1000

On 04/07/2012, at 6:00 PM, Erik Wilde wrote:

> so a question i am interested in looking at would be the following: would it make sense to consider a "URI parameter registry", so that syntax and semantics of URI template parameters could be made reusable across media types and/or link relations?

I don't think so. The intuitive thing, to me, is to be able to map them to URIs somehow.