Re: uri-templates implementation feedback.

On Aug 8, 2011, at 11:50 PM, Marc Portier wrote:

> Hi all,
> 
> I've finally come round to updating my js implementation to the latest state of the spec (that is currently r71 at http://code.google.com/p/uri-templates/)
> 
> 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?

When I added path params to URLs in RFC 1808, the intention was
to be closer to VAX/VMS-style path versioning rather than matrix.
In fact, I'd say matrix is bunk -- there was never any need to
supplant query params with path params.

I'd rather not change the above.  If a path has a variable list
of parameters and key=value is desired, then provide the value as
an associative array.  In contrast, if we make the above change,
then there is no way to get the

  ;red;green;blue

result other than by defining it as separate variables, as in
{;red}{;green}{;blue}

> [encoded names]
> 
> If I understood the spec correctly the varspec-names can contain pcnt-encoded characters, and should be decoded to translate onto context-keys.
> 
> Thus the following expansions should work out as listed, right?
> 
>>    var context = {
>>        "!":  "exclamation-mark",
>>        "%21": "encoded exclamation-mark"
>>    }
>> 
>>    var testset = {
>>        "{!}"   : "{!}",
>>        "{%21}" : "exclamation_mark"
>>    };

Right, though I am thinking of reversing myself and removing
some of the places where IRI characters are allowed, because of
stuff like the above and concerns over double-encoding values,
IDNA hostnames, etc.

> [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.

Umm, no.  It only looks cool because you are a programmer.
Dynamic indirect binding inside a declarative format ...
that is the kind of thing that drives documentation and
template users nuts.

> 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?)

Right, it's not supposed to be a programming language.

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

Ouch!

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

Thanks.  I'm mostly interested in what removals result in
the most savings.

....Roy

Received on Friday, 12 August 2011 23:36:48 UTC