Re: URI Template -04 Implementation Notes

Hi Joe,

Re point 6, just to mention that there are examples of what I describe in
the JSON description of the Buzz API.  I am led to believe that you are
familiar with this.

That aside, where next with the spec, implementation issues etc?  If there's
anything I can do...

Regards,
Mike
mjb@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake


On 2 June 2010 11:18, Mike Burrows <mjb@asplake.co.uk> wrote:

<snip>


>
On 2 June 2010 05:00, Joe Gregorio <joe@bitworking.org> wrote:
>
>> 6. I've come across yet another case where going in reverse, from a
>> template
>>   to matching, would be useful. How about carving out () at the end of
>>   an expression as a place where a regex could be stored for applications
>>   that want to use a template for matching against incoming requests, but
>>   just state that the allowed regex's and matching algorithms are outside
>>   the scope of the current spec?
>>
>
>
> That could be done without changing the spec at this stage.  Routes (for
> example) has a syntax that allows a regex to be embedded - e.g.
> "{foo:[a-z]+}" - but it's usually much better to provide these as separate
> parameters to the route definition.  Implementers are free to do something
> similar now with the URI Template spec as it stands, and meanwhile the spec
> can progress towards approval.
>
> It should be sufficient for servers to be able to generate URI Templates
> from their native formats (this is what described_routes does with templates
> from Routes or Rails); in the worst case they can be maintained separately.
> So far I've manage to avoid doing anything that will encourage clients to
> parse URIs.
>
> <snip>
>