W3C home > Mailing lists > Public > uri@w3.org > October 2007

Re: Mixing template variable vocabularies?

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 20 Oct 2007 11:33:21 +1000
Message-Id: <117A4B32-6A82-4C42-A664-B47904DA6167@mnot.net>
Cc: URI <uri@w3.org>
To: James M Snell <jasnell@gmail.com>

On 20/10/2007, at 11:00 AM, James M Snell wrote:

> Mark, I like the concept, but I'm not sure that tying the variables to
> the link relation is such a good idea.

Yeah, I had the same discomfort.

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

You had me up until "qname-like" :)

If we can contrive to keep the delimiters between the operator and  
args outside URI-legal characters, we could open up variable names to  
be (optionally relative) URIs again. Yes, it's uglier, but not as  
conceptually ugly as qnames, and human readability seems to be  
diminishing as a high-order goal anyway.

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

I'm tempted by this too, but it doesn't seem very... Web-like.  
Granted, you ultimately have to "just know" the semantics of the  
variables anyway (until the Semantic Web becomes operative and begins  
killing us all), but not being able to uniquely identify the  
variables in a given template doesn't seem like great practice, if  
we're planning to allow them to come from anywhere but the "local"  

It would be cool if somebody could write a template that specifies  
that a Yahoo ID, or a GMail login, or a social security number (gack)  
went into a variable. It's a very nice-to-have if we could do it  
easily; if it gets in the way too much, I'm happy dropping it.


> - 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/

Mark Nottingham     http://www.mnot.net/
Received on Saturday, 20 October 2007 01:35:19 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:50 UTC