- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 20 Oct 2007 11:33:21 +1000
- To: James M Snell <jasnell@gmail.com>
- Cc: URI <uri@w3.org>
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" scope. 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. Cheers, > > - 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