Re: URI Template error handling

I'm not too tied to any one resolution, I just think error and warning
flagging and how errors and warnings affect the result needs to be
defined a little more precisely and used consistently throughout the
document. If that includes having error flagged results contain partially
matched templates that's fine with me.

  -joe

On Fri, Feb 26, 2010 at 5:53 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Feb 26, 2010, at 7:12 AM, Joe Gregorio wrote:
>
>> Section 2.2
>>
>>  The operator characters pipe ("|"), exclamation ("!"), and at-sign ("@") are
>>  reserved for future extensions. A processor that unexpectedly encounters
>>  such an extension operator should flag the expression as an error and include
>>  it in the result without expansion.
>>
>> The use of the term 'error' here contradicts its use in Section 3:
>>
>>  If a template processor encounters an error, such as an operator that it
>>  does not understand or a character sequence that does not match
>>  the <URI-Template> grammar, then processing of the template SHOULD
>>  cease, the URI-reference result SHOULD be undefined, and the location
>>  and type of error SHOULD be indicated to the invoking application.
>>
>> That is, since an error was encountered the result SHOULD be undefined, so
>> there's no result in which to include the unexpanded expression. I suggest
>> the following rewordings
>>
>> Section 2.2:
>>
>>  The operator characters pipe ("|"), exclamation ("!"), and at-sign ("@") are
>>  reserved for future extensions. A processor that unexpectedly encounters
>>  such an extension operator should pass the expression through unexpanded.
>>  It MAY also indicate a warning to the invoking application.
>>
>> Section 3:
>>
>>  If a template processor encounters an error, such as an operator that it
>>  does not understand or a character sequence that does not match
>>  the <URI-Template> grammar, then processing of the template SHOULD
>>  cease, the URI-reference result SHOULD be undefined, and the location
>>  and type of error SHOULD be indicated to the invoking application.
>> If a template
>>  processor encounters a warning, such as the use of an operator character
>>  reserved for future extension, then the processing of the template SHOULD NOT
>>  cease, and the location and type of warning SHOULD be indicated to the
>>  invoking application.
>
> Okay, though I would prefer to make the pass-through case apply
> for all errors as well, since that is the easiest way to tell
> the invoking application at what point the error occurred.
>
> ....Roy

Received on Saturday, 27 February 2010 02:15:36 UTC