W3C home > Mailing lists > Public > uri@w3.org > March 2010

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

From: Mike Burrows <asplake@googlemail.com>
Date: Wed, 10 Mar 2010 17:40:31 +0100
Message-ID: <7a2269961003100840u15792f0dg289a6d46f4362da1@mail.gmail.com>
To: "Roy T. Fielding" <fielding@day.com>
Cc: URI <uri@w3.org>
Sorry again, that first one should have been
    x{empty_list=_}y           xy

which I can't easily reconcile with (for example)
    x{/empty_list=none}   x/none


On 10 March 2010 16:38, Mike Burrows <asplake@googlemail.com> wrote:

>
> Sorry ignore that first one, my mistake.  I'm still confused by the
> apparent conflicts though.
>
>
>
> On 10 March 2010 16:18, Mike Burrows <asplake@googlemail.com> wrote:
>
>>
>> Couple of issues with defaults.
>>
>> This doesn't seem right:
>>     x{empty=_}y           xy
>>
>> These
>>     x{;name=none}         x;name=Fred,Wilma,Pebbles
>>     x{?favs=none}         x?favs=color,red,volume,high
>> seem in conflict with
>>     {;list}               ;val1,val2,val3
>>     {;keys}               ;key1,val1,key2,val2
>>
>> I suspect same too about
>>     x{;empty_list=none}   x;empty_list=none
>>     x{;empty_keys=none}   x;empty_keys=none
>>
>> In both cases I may be missing something, but I wouldn't expect the
>> presence of a default to change behaviour in this way.  Or is it the earlier
>> part of the spec that is incorrect?
>>
>>
>> Regards,
>> Mike
>> mjb@asplake.co.uk
>> http://positiveincline.com
>> http://twitter.com/asplake
>>
>>
>> On 10 March 2010 15:18, Mike Burrows <asplake@googlemail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Received on Wednesday, 10 March 2010 16:41:07 UTC

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