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

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     

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of John Kaputin (gmail)
Sent: Saturday, January 06, 2007 6:11 PM
To: www-ws-desc@w3.org
Cc: woden-dev@ws.apache.org; 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) <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.