Re: 6.7.1.1 Construction of the request IRI using the http location

Yoeunn,

Maybe we could solve this by mapping our syntax into a regex and then 
using the regex semantics.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



Youenn Fablet <youenn.fablet@crf.canon.fr> 
Sent by: www-ws-desc-request@w3.org
11/23/2006 08:47 AM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
Philippe Le Hegaret <plh@w3.org>, www-ws-desc <www-ws-desc@w3.org>, 
www-ws-desc-request@w3.org
Subject
Re: 6.7.1.1 Construction of the request IRI using the http location







I agree.
I would like also to note that if two curly-braced element names are not 
separated by a '?' or a '/' character, parsing may also be ambiguous
Example:
    whttp:location="{name}{address}", "{name}adr{address}" can be 
ambiguous
    whttp:location="{name}/{address}", "{name}?addr={address}" would not 
lead to ambiguous parsing if escaping is used
We could enforce the presence of a '?' or '/' between two curly-braced 
elements.
I understand that this limits the current expressiveness power of the 
location property,
but IMHO, this retains much of its usability, eases tooling and lowers 
the chances of wsdl authoring errors.
    Youenn


Arthur Ryman wrote:
>
> I think it makes sense to be more precise about the syntax of the 
> {http location} and to use escaping to avoid breaking the syntax.
>
> Arthur Ryman,
> IBM Software Group, Rational Division
>
> blog: http://ryman.eclipsedevelopersjournal.com/
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-2411, TL 969-2411
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063, text: 4169395063@fido.ca
>
>
> *Youenn Fablet <youenn.fablet@crf.canon.fr>*
> Sent by: www-ws-desc-request@w3.org
>
> 11/22/2006 10:51 AM
>
> 
> To
>                Philippe Le Hegaret <plh@w3.org>
> cc
>                www-ws-desc <www-ws-desc@w3.org>
> Subject
>                Re: 6.7.1.1 Construction of the request IRI using the 
http location
>
>
>
> 
>
>
>
>
>
>
> Following on philippe's message, there are also ambiguous cases that
> might happen.
> Given this schema:
> <element name=root>
>    <sequence>
>        <element name=person type=string minOccurs=0/>
>        <element name=address type=string minOccurs=0/>
>        <element name=surname type=string minOccurs=0/>
>    </sequence>
> </element>
> Given this instance data:
> <root>
>    <person>foo</person>
>    <address>/</address>
>    <surname>foo</surname>
> </root>
> with http:location="foo/{person}/{address}/{surname}
> we will obtain foo/foo///foo, which leads to ambiguous parsing on the
> server side (as address='' and surname='/foo' will also lead to the same
> uri-encoded data).
> Should we prevent this case and escape the '/' character in url path
> encoded data?
>
> There is also the case of the '?' special character that may lead to
> issues in determining when begins the query string.
> Should we prevent this case and escape the '?' character in url path
> encoded data?
>    Youenn
>
>
>
> Philippe Le Hegaret wrote:
> > Given this instance data:
> >  <root>
> >    <foo>1</foo>
> >    <foo>2</foo>
> >  </root>
> >
> > With http:location="t"
> > we should obtain "t?foo=1&foo=2"
> >
> > With http:location="t/{foo}"
> > we should obtain "t/1?foo=2"
> >
> > With http:location="t/{foo}/{foo}"
> > we should obtain "t/1/2"
> >
> > With http:location="t/{foo}/{foo}/{foo}"
> > should we obtain an error (we don't have 3 foo elements in the 
instance
> > data) or, should we obtain "t/1/2/1" or "t/1/2/2" ?
> >
> > As a side comment, using element names in the http:location adds an
> > additional message schema constraint, in addition to the ones already
> > defined the IRI style: those element names shouldn't be optional. If 
one
> > of those http:location element names is defined as optional in the
> > schema, not including it in the instance data could result in a 
runtime
> > error.
> >
> > Philippe
> >
> >
> >
> > 
>
>
>