URI Template error handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

URI Template error handling

Joe Gregorio-2
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.

   Thanks,
   -joe

Reply | Threaded
Open this post in threaded view
|

Re: URI Template error handling

Roy T. Fielding
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
Reply | Threaded
Open this post in threaded view
|

Re: URI Template error handling

Joe Gregorio-2
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 <[hidden email]> 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