Re: Feedback on draft-gregorio-uritemplate-00

Hi Stefan,

One of the things we found when talking through URI templates is that  
there are a a *wide* variety of use cases for annotations,  
conventions, etc. in template variables; e.g., whether to percent- 
encode, whether something is optional, constraints on the value  
space, whether to include the variable name in a query arg, etc. So,  
whatever convention you use here, it needs to be extensible.

Additionally, template variable names themselves have a pretty wide  
range; e.g., if Semantic Web folks start to like them, they'll  
probably want to use a URI as a template variable name (and this  
might be a good idea in other situations too...). This leads to a  
requirement that any such conventions that are built into URI  
Templates itself, and not dependent on context, needs to be very  
distinct from the variable name.

At best, I think something like this would work:
   http://example.com/{path<a>}/{b}?{query<c>}
with a convention for naming the "functions" similar to that for Atom  
link relations (a registry or use a full URI for a non-registered  
value).

However, that makes one of the big use cases -- human-readable docs  
-- more unlikely. Ideally, you should be able to drop URI Templates  
directly into developer docs (like those at developer.yahoo.com,  
amazon.com/webservices, dev.live.com, code.google.com, etc.), and  
there's a lot of line noise there. Really, this is walking down the  
path of designing an in-template schema language, which IMO is a  
*huge* rat-hole.

I appreciate the attraction of putting the datatype in the template,  
but consider the situation if you leave it outside. Every use of URI  
Templates is going to have to define the semantics and processing of  
each variable name somewhere else anyway; they'll have to say "'a' is  
the username, and should be at most 8 characters long...".  Since  
there needs to be external information like this anyway, putting the  
encoding information there as well is the simplest, most flexible  
approach that hits the 80% case.

If we want percent-encoding and input hints are unattractive, I'd  
rather force the processor to do the right thing and automatically  
encode based on where the variable is in the URI. I think it would  
still be good to have an input-hint-shaped escape hatch then, but  
that can be implementation-specific.

Cheers,


On 2006/10/07, at 2:45 AM, Stefan Eissing wrote:

>
> It seems to me that the data type of uri templates parameter would  
> be part of the template and not part of the input. The one  
> designing the template should know what goes where?
>
> Am 07.10.2006 um 05:39 schrieb Mark Nottingham:
>
>> Actually, by putting what's effectively an encoding type in the  
>> input data structure, we *can* have both;
>>
>> {
>>   'a': ('foo/bar', PATH_SEGMENT),
>>   'b': ('foo/bar', NULL),
>>   'c': ('foo/bar', QUERY_STRING),
>> }
>> http://example.com/{a}/{b}?{c}  -->  http://example.com/foo%2f/foo/ 
>> bar?foo/bar
>>
>
> here you declare how the input shall be treated as attribute of the  
> input. What about this:
>
> ('foo/bar', 'foo/bar', 'foo/bar')
>
> http://example.com/{1ps}/{2}?{3q}  -->  http://example.com/foo%2f/ 
> foo/bar?foo/bar
>
> n - substitue n-th parameter unchanged
> np - substitue n-th with uri escaping to make a valid path
> nps - substitue n-th with uri escaping to make a valid path segment
> nq - substitue n-th with uri escaping to make a valid query
>
> Instead of positional, numbered parameters, one can apply the same  
> to named parameters, as in
>
> http://example.com/{ps(a)}/{b}?{q(c)}
>
> Cheers,
>
> Stefan
>


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

Received on Saturday, 7 October 2006 14:47:00 UTC