Re: Mixing template variable vocabularies?

Mark, I like the concept, but I'm not sure that tying the variables to
the link relation is such a good idea.  As much as I'd hate to admit it,
this is probably something that should be done using qname-like
variables, e.g.,

  Link-Template: <http://example.com/{a:foo}/{b:foo}>; rel="alternate";
    a=<http://example.org/ns/bar>;b=<http://example.com/ns/baz>

This, of course, makes the templating language quite a bit more
complicated but achieves the goal.

Or... of course, we could just keep it simple and just say that there is
one set of template variables, they're not related to the link relation
in any way, and the application just has to know which values to provide.

- James

Mark Nottingham wrote:
> 
> One of the use cases I have for URI templates is shoving them around in
> HTTP headers (e.g., the Link-Template header
> <http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt>)
> to build ad hoc, link-rich protocols. E.g., what's sketched out in
> <http://lists.w3.org/Archives/Public/uri/2007Jul/0039.html>.
> 
> In that approach, the template variable names are grounded by the link
> relation itself; e.g., the 'token-login' link relation says that it
> expects the 'token' variable to be in the template. As such, the
> variables in use are defined by and bound to the link relation.
> 
> Question: do people have use cases where this doesn't work? Are there
> times where a link relation (perhaps an existing one) doesn't know all
> of the possible parameters to a link?
> 
> For example, a case where you want to construct a URI for a generic
> service (e.g., an APP endpoint), but want to put some site-specific
> variables into the template, like a user or group identifier
> (effectively mixing template variable vocabularies).
> 
> If we do want to cover cases like this, it seems like we'll need some
> way to individually scope the name space of a template variable, rather
> than assuming that they're all in the same one.
> 
> Cheers,
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 
> 
>

Received on Saturday, 20 October 2007 01:01:03 UTC