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) <jakaputin@gmail.com> 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.
>