Re: URI Template -04 Implementation Notes

In implementing a -04 parser in PHP, I also found the expansion operators to
treat modifiers dissimilarly, resulting in a large number of special cases.
http://lab.kevburnsjr.com/php-uri-template-parser

I did, however, get the library to pass for all examples I could find in the
-04 spec (except those relating to partial modifiers which I have yet to
implement).
http://php-uri-template-parser.hackyhack.net/tests.php


KB - a
- --- -
> 1. [...]
>
>   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.

In the step from -03 to -04 the syntax has become more succinct, but has
also become more magical.  Simpler is better IMHO.


KB - b
- --- -
> 6. I've come across yet another case where going in reverse, from a
>  template to matching, would be useful [...]

Reversibility was something that originally attracted me to URI-Templates.
If a resource could use the same pattern to match a URI as it uses to
generate them, the world could be a much simpler place.

However, it could be argued that most templates are not designed to be
reversible (you wouldn't try to reverse an HTML template expansion).

The best solution I could come up with is a second format employing an
extended expression syntax (adding support for RegEx) used for matching that
could be easily reduced to a valid uri-template for expansion.  A *
reversible-uri-template* if you will.

Keeping this as a separate format would ensure that uri-template parsers
remain simple to implement (important for adoption IMHO).


KB - c
- --- -
Lastly, I wondered about using multiple operators for a single expression,
particularly with respect to the + operator.

Should expressions with multiple operators such as {+;list1,list2} be
allowed in order to add support for Reserved Expansion of expressions with
delimiter operators?


- KevBurnsJr
c: +001 (650) 521-7791


On Tue, Jun 1, 2010 at 9:00 PM, Joe Gregorio <joe@bitworking.org> wrote:

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