RE: Spec Issue - unmatched single curly braces in HTTP Location

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

RE: Spec Issue - unmatched single curly braces in HTTP Location

Jonathan Marsh-2

Thank you for this comment.  The Working Group this issue as a CR141 [1].

 

The Working Group closed this issue as a duplicate of CR130 [2].  The expected resolution there should suffice for this issue as well.

 

Unless you let us know otherwise by the end of January, we will assume you agree with the resolution of these issues.

 

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR141    

[2] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR130     

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of John Kaputin (gmail)
Sent: Saturday, January 06, 2007 6:11 PM
To: [hidden email]
Cc: [hidden email]; John Kaputin
Subject: Re: Spec Issue - unmatched single curly braces in HTTP Location

 

Here's another example that highlights the need to decide on precedence when parsing curly braces in the HTTP location template. It might be better if the spec made this choice clear.

Consider the template (or a template fragment) "{{{town}}}". If inner-most matching pairs of single braces take precedence this is interpreted as {{,{town},}} and after substitution of element values and literals it becomes something like "{London}".  However if, as in the case of Woden, the double curly brace notation takes precedence over any potentially matching single braces, then this is interpreted as {{,{,town,}},} which is invalid because it has unmatched single curly braces (i.e. it has a left and a right brace that enclose the string "town}}" which cannot be an element local name, even after the double brace is replaced by a single brace).  If the first interpretation seems more reasonalbe, the spec should probably be clearer about how the double curly brace syntax is applied.

regards,
John Kaputin.

On 1/4/07, John Kaputin (gmail) <[hidden email]> wrote:

In defining the {http location} property the spec describes enclosing an element local name within curly braces and it describes using double curly braces to specify a single literal curly brace, but it is silent on the possibility of extraneous, unmatched single curly braces appearing in the HTTP location template. For example, "temperature/{town}" is okay but what about "temp{era{ture/{town}"?

One option is to do nothing - just include these unmatched curly braces in any derived HTTP location value after any valid element and literal substitution has occurred (e.g. the derived location becomes "temp{era{ture/London"), but this may result in a meaningless value in which case this option is not very helpful.

A second option is to treat such unmatched single curly braces as an error and add a suitable assertion to the spec so that implementations can catch this as an error and report it in a standard way.

Currently, my implementation in Apache Woden flags these unmatched braces as an error but I don't have an assertion to base the validation logic and an error message on.

Perhaps the first question in this situation is which of the multiple single curly braces to use for the 'pair' - e.g. left-most, inner-most or outer-most.  My Woden implementation assumes inner-most, so if multiple left braces precede a right brace, the right most one will be paired with the right brace and the others will be considered extraneous and unmatched. So in "temp{era{ture/{town}" the 1st and 2nd left braces are extraneous and the 3rd is paired with the right brace (e.g. "temp{era{ture/London").  Likewise, if multiple right braces follow a left brace the left most one is paired with the left brace. 

I'm not sure if the spec actually needs to say anything about the pairing strategy. The Woden implementation does not stop processing on an error, but continues to process the entire WSDL, returning a possibly invalid WSDL model and reporting all errors. So for this continue-on-error approach a pairing strategy much be chosen. Other implementations may stop-on-error, in which case it's sufficient just to detect that extraneous, unmatched curly braces exist without considering how to pair them off with the opposite brace. I do wonder though if different implementations adopting the continue-on-error approach chose different pairing strategies, if this could lead to interoperability problems.

The relevant section of the spec is Part 2, 6.7.1.1 Construction of the request IRI using the {http location} property.

regards,
John Kaputin.