W3C home > Mailing lists > Public > uri@w3.org > August 2011

uri-templates implementation feedback.

From: Marc Portier <marc.portier@gmail.com>
Date: Tue, 09 Aug 2011 08:50:42 +0200
Message-ID: <4E40D8C2.4000108@gmail.com>
To: URI <uri@w3.org>
CC: "Roy T. Fielding" <fielding@gbiv.com>
Hi all,

I've finally come round to updating my js implementation to the latest 
state of the spec (that is currently r71 at 

I know this has no official 0.6 label (yet), but since it fixed some 
samples and removed some more requirements (e.g. the 'default') lazy me 
thought this to be an easier goal.

Anyway, here some findings:

[unnamed list expansion for ; matrix-params]
Anyway: I only have one case that made me add some quirk to comply to:
   {;list*}              ;red;green;blue

Without the quirk my implementation produced:
   {;list*}              ;list=red;list=green;list=blue

Well, I obviously don't like quirks, but sentiments aside I am left to 
wonder if the matrix-parameters are not always expected to carry a name?

[encoded names]

If I understood the spec correctly the varspec-names can contain 
pcnt-encoded characters, and should be decoded to translate onto 

Thus the following expansions should work out as listed, right?

>     var context = {
>         "!":  "exclamation-mark",
>         "%21": "encoded exclamation-mark"
>     }
>     var testset = {
>         "{!}"   : "{!}",
>         "{%21}" : "exclamation_mark"
>     };

[nesting context variables]

The spec doesn't play out dereferencing nested structures by using . (or 
some other notation) between variable-names.

I'm not sure if this on purpose or just a wicked idea from me:

>     var context = {
>         "a.b"       : "value-at-a.b",
>         "x"         : { "y": "value-at-y-via-x"}
>     }
>     var testset = {
>         "{a.b}"       : "value-at-a.b",
>         "{x.y}"       : "value-at-y-via-x"
>     };

Dunno if this makes sense to add, but it seems like a fairly easy thing 
to add in the implementation.

On the other hand, it can be overcome by preprocessing the context 
structure (pretty much similar to how we currently would be adding the 
removed 'defaults' behavior, no?)

Note there is a challenge to correctly define 'preference of finding' 
which of possibly multiple matching keys with this approach. "a.b.c" 
might be found at any of: "a.b.c" "a"->"b.c", "a"->"b"->"c", "a.b"->"c"

All for now.
My implementation can be found at 
https://github.com/marc-portier/uri-templates  (The two failing tests 
(src/test/webenv/test.html) at the moment are the ones mentioned just 
above, I'll gladly fix taking into account your responses and 
clarifications.  If time permits I'll try to add some more edge-case tests)

Received on Tuesday, 9 August 2011 06:51:22 UTC

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