Re: Feedback on draft-gregorio-uritemplate-00

Hi Mark,

first of all thanks for the detailed explanation. I see now much  
better what you have in mind.

As James already wrote, simplicity (as in usability) is the goal here  
and any attempt to fully describe every parameter type and  
restrictions (to avoid the s-word) will kill the use of templates on  
the spot.

I still have the nagging feeling that extensions to the template, as  
the bash like substitutions for defaults that Roy mentioned and/or  
unforeseen others, will one day come in handy when more experience  
has been made.

Currently the templates allow only "unreservered" chars between the  
curly braces which works well for parameter names. Perhaps an "escape  
hatch" would come in handy so the production could look like this:

template-char = unreserved
template-name  = 1*template-char
ext_char = unreserved / gen-delims / sub-delims
template-var  = "{" template-name [ ":" 1*ext_char ] "}"

and uri templates would require any implementation to ignore  
extensions they do not recognize (so all for now). (using ":" as  
separator was just the first thing that came to mind, any not- 
unreserved (ha!) uri char would do. Using just a single one makes  
implementation easy.)

Cheers,

Stefan

Am 07.10.2006 um 16:46 schrieb Mark Nottingham:

>
> 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 19:27:30 UTC