W3C home > Mailing lists > Public > uri@w3.org > July 2010

Re: URI Template -04 Implementation Notes

From: Mike Burrows <mjb@asplake.co.uk>
Date: Mon, 19 Jul 2010 18:13:36 +0100
Message-ID: <AANLkTimdR4OdZjRVFrcJgzx3wWOrLReyFQqOuV-FWHkY@mail.gmail.com>
To: Joe Gregorio <joe@bitworking.org>
Cc: URI <uri@w3.org>
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...


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


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>
Received on Monday, 19 July 2010 17:14:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC