Re: Mixing template variable vocabularies?

Mark Nottingham wrote:
> [snip]
> You had me up until "qname-like" :)
>

Yeah, that was unbelievably painful to type.

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

Hmm....

At this point, I'm really leaning towards wanting Joe to just update the
spec as he described it in his recent note and just let implementors go
off and do their thing with it for a while.  If and when things start to
get ugly with regards to naming conflicts, etc, we can revise the spec
with whatever additional level of complexity proves useful.

- James

> 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 03:19:29 UTC