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
>
>
>
>

Received on Wednesday, 22 November 2006 15:52:29 UTC