Re: URI Template error handling

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 01:54:14 UTC