Clarifications on CR117

After yesterday's discussion about CR117, I have the following 
comments/precisions/questions.
I hope this helps clarifying the issue(s).

1) Question mark
a) Having a '?' in the values of the parameter may lead to issues: the 
query string may begin in advance:
examples:
    whttp:location="Send/{title}/index?" with two parameters (title and 
author) may lead to something like: Send/What?/index?author="unknown".
There might be applications that will be able to handle that but others 
may not be able to correctly handle this...

b) To be noted that client applications will need to check at runtime 
whether the location and parameter values have a '?' in order to 
correctly build the query string
Let's have whttp:location="/Send/{title}"
if title is "What" and author is "Unknown&Co", we would have:
    /Send/What?author=Unknown&Co
if title is "What?ok" and author is "Unknown&Co", we would have:
    /Send/What?ok&author=Unknown&Co
This might need to be clarified in the specification (cf. phillipe AI).

Please note also the use of the "&" in this example. Other reserved 
characters (#) may also have some impact. Hence the proposal at the end 
of this message.

2) URI escaping

Characters from @address, @whttp:location or from parameter values may 
need to be escaped before being put in the HTTP request.
Characters from @address and @whttp:location are escaped as there is a 
mapping defined by their type xs:anyURI.
What should be done with characters from parameter values is not 
specified IIRC.
We might want to clarify whether the escaping happens before or after 
the replacement of the parameter name by its value.
If we have @whttp:location="Send%{int}" and int is "20", what do we have 
is either Send%20 or Send%2520.
Am I missing something?

3) Reversibility

In some cases, the templating mechanism may be ambiguous.
This may be due to the templates: whttp:location="{country}{zipcode}" 
may be ambiguous or not depending on the types of country and zipcode.
This may also be due to the use of special characters within parameter 
values: whttp:lcation="" may be ambiguous if some parameter values use 
'&' for instance.

It makes perfect sense to allow the description of such non-reversible 
URI construction.
It also makes sense IMHO to ensure the reversibility of the URI 
construction, especially for SOAP.
While this is feasible to do it by constraining the type of the 
parameters as arthur suggested, I think it would be better to have a 
more lightweight and general solution for wsdl users : binding simple 
IRI-style-compliant structures to either SOAP-response or SOAP 
request-response would be quite useful.

One potential solution is to have two parameter value serialization modes:
    - one straightforward that simply copies the parameter values
    - another one that url encode all URL reserved/special characters 
(/,?,$,&,=,.)
In the SOAP case, the second serialization mode might be the preferred one.
We could then add within the WSDL component model a property that tells 
the WSDL processor how parameter values are handled for a particular 
binding component.
The reversibility would then be ensured by the use of both the second 
serialization mode and simple templating rules like:
    - have an empty location value: all parameter values are encoded as 
query parameters
    - always put a '/' between parameter values

What do you think?
    Youenn

Received on Friday, 5 January 2007 09:41:06 UTC