Re: Feedback on draft-gregorio-uritemplate-00

I totally agree, and had thought that's where we ended up (we did a  
lot of last-minute adjustments ;). The template variable name should  
be able to be a full URI, with the full range of allowable characters  
available to it.

Cheers,

On 2006/10/07, at 12:27 PM, Stefan Eissing wrote:

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


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

Received on Monday, 9 October 2006 05:12:35 UTC