URI Template -04 Implementation Notes

I've committed an incomplete implementation of the -04 spec
in Python to svn along with test cases taken from the spec.

   http://code.google.com/p/uri-templates/source/detail?r=57

The tests themselves are taken directly from the spec and
are stored in a JSON file, to make it easier to reuse them.
(Well, almost taken verbatim from the spec, below I list
the cases that were either inconsistent or looked wrong
and how I changed them.) The code does not implement
'partial' modifiers.

Here are my notes:

1. The spec is fiddly, by which I mean that while the rules
   for handling semicolon, query parameter, path and label
   expansions all make sense on their own, they are all
   slightly different from each other. It makes for a lot
   more code than I expected, and is fairly tedious to implement.
   I'm not sure that the amount of complexity is warranted.

   To simplify I would like to see label and semicolon path
   style expansions dropped. I also believe the '+' modifier could
   be dropped without loss of generality.

2. From the spec, this rule isn't consistent:
      ["{?x,y,empty}", "?x=1024&y=768&empty="],

3. One of these is inconsistent
     ["X{.empty}", "X."],
     ["x{?empty_list}", "x"],

4. Also inconsistent
     ["{;list}", ";val1,val2,val3"],
     ["x{;name=none}", "x;name=Fred,Wilma,Pebbles"],

5. I tried working through the empty and default cases
    (section 2.5) but came across so many cases that
    seemed to disagree with previous examples or the wording
    of the spec that I began to suspect the section was incomplete.
    Here is the list of test cases I had collected and believe are wrong,
    before I stopped:

     ["x{empty_list=_}y", "xy"],
     ["x{empty_list+=_}y", "xempty_list._y"],
     ["x{empty_keys=_}y", "xy"],
     ["x{empty_keys+=_}y", "xempty_keys._y"],
     ["x{?empty}", "x?empty="],
     ["x{?empty=none}", "x?empty="],
     ["x{?empty_list*=none}", "x?none"],
     ["x{?empty_list+=none}", "x?empty_list.none"],
     ["x{?empty_keys*=none}", "x?none"],
     ["x{?empty_keys+=none}", "x?empty_keys.none"],

  I believe many of these cases with defaults are ones that Mike Burrows
  raised earlier.

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?

  Thanks,
  -joe

Received on Wednesday, 2 June 2010 04:00:46 UTC