Re: I-D Action:draft-gregorio-uritemplate-04.txt

Thanks, looks good.

I have a processor (in Python) that checks out ok for all the examples in
section 1.2.  The only genuine special case in my code was the different
treatment of empty values by the ; and ? operators.  I assume it's
deliberate but I mention it just in case.

One trivial typo: a missing semicolon after path  := "/foo/bar" just before
that same table in section 1.2.

Default values are there but untested; so far I parse but otherwise ignore
prefix and suffix values.  I'll report back my progress on those later as a
sanity check on the as-yet untested examples.

Re point 1 on error handling , it would be reasonable and indeed preferable
in many languages for an implementation to raise an exception in the
presence of errors, in which case the result string is undefined and any
information about the error (or perhaps errors plural) would be returned
back to the caller in the exception object.  That sort of behaviour is
compatible with the spec as it stands but not with the kind of wording used
below.  I would choose to leave the spec as it is.

FWIW, I'm with you Roy on point 4c.  My URI Templates are embedded in
metadata that can annotate variables with as much flexibility as I'll ever
need, and I imagine that this will be a fairly typical use case.  As for the
other changes proposed in point 4 I'm not that fussed except that the
novelty of tracking the standard across two language implementations is
wearing a bit thin.  But if there's anything I can do to help...

Regards,
Mike
mjb@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake


On 10 March 2010 01:20, Roy T. Fielding <fielding@day.com> wrote:

> [second attempt to send this]
>
> I managed to submit a new draft, just before the deadline,
> with the obsolete sections removed and the sections that
> still need writing marked as TBD.
>
> The current issues (that I am aware of) include:
>
> 1) error handling -- as Joe noted, we can improve consistency
> by making every error in the template result in a semi-expanded
> result string and error indicator, rather than nulling
> the result string and returning immediately.  My preference is
> to copy bad expressions to the result, continue processing, and
> indicate an error occurred to the caller.  This allows the
> calling application to use the result string to point out
> where the processing failed.
>
> 2) reserved substitution -- this is currently allowed only
> by the "+" operator.  A suggestion by Mike Burrows is that the
> "+" operator be changed into a variable name prefix so that
> it can be selectively applied to any variable in any expression.
> In addition to the added power, I found that a prefix would
> simplify the value expansion description (and algorithm).
> However, I have not made that change yet in 04.  Would such
> a change be compatible with XRD and other applications?
>
> 3) I introduced explode modifiers, with the named variable
> version indicated by a trailing "+" on the name.  Perhaps that
> would be better as a trailing "@" if we do (2) above.
>
> 4) James Manger suggested several changes to the syntax:
>
>  a) remove the variable lists and instead have the processor
>     maintain a memory of where it is in the URI generic syntax
>     to know when to add the default ";" or "?" delimiters.
>     Add a comma operator to support CSV expansions.
>
>  b) change the default syntax to {var|default} instead of
>     {var=default}, in order to allow ...
>
>  c) define variable bindings within the template itself so
>     that large schemas like OpenSearch can directly annotate
>     every variable inside the template as opposed to annotating
>     them by reference outside the template.  e.g.,
>
>        find{?q=searchTerms}{?lang=language}
>
>    I personally find (a) significantly uglier than the
>    existing syntax;  (b) okay if people haven't implemented
>    defaults yet; and, (c) a very slippery slope that, IMO, will
>    result in the equivalent of WADL being embedded inside the
>    template instead of remaining outside (where it can be safely
>    ignored by RESTful applications).  YMMV.
>
> I will be at the Anaheim IETF if anyone wants to discuss these
> issues in person, but please send email to the list if you want
> the discussion to result in changes to the next draft.
>
> Cheers,
>
> Roy T. Fielding                            <http://roy.gbiv.com/>
> Chief Scientist, Day Software              <http://www.day.com/>
>
> Begin forwarded message:
>
> > From: Internet-Drafts@ietf.org
> > Date: March 8, 2010 5:00:01 PM PST
> > To: i-d-announce@ietf.org
> > Subject: I-D Action:draft-gregorio-uritemplate-04.txt
> > Reply-To: internet-drafts@ietf.org
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >       Title           : URI Template
> >       Author(s)       : J. Gregorio, et al.
> >       Filename        : draft-gregorio-uritemplate-04.txt
> >       Pages           : 25
> >       Date            : 2010-03-08
> >
> > A URI Template is a compact sequence of characters for describing a
> > range of Uniform Resource Identifiers through variable expansion.
> > This specification defines the URI Template syntax and the process
> > for expanding a URI Template into a URI, along with guidelines for
> > the use of URI Templates on the Internet.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-04.txt
>
>
>
>