Spec Issue - unmatched single curly braces in HTTP Location

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.