Thank you for this comment. The Working Group this issue as a CR122 .
Yes, this is the expected behavior. It is possible to bind some XML data in
such a way that parts of that data are omitted from the message. It is also
possible that this may cause problems in some cases. But adding a constraint
about using these features together is somewhat unnatural and may constrain
away useful behavior in other cases. WG did not change the spec in response
to this issue.
Unless you let us know otherwise by the end of January, we will assume you
agree with the resolution of this issue.
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Youenn Fablet
> Sent: Thursday, December 07, 2006 1:46 AM
> To: www-ws-desc
> Subject: Clarification about ignoreUncited behaviour
> Reading section 6.7.2, I am not entirely sure of the right behaviour of
> the whttp:ignoreUncited property.
> Here is my current understanding. Can someone verify and correct it if
> Input parameters not cited in whttp:location are serialized to build a
> query string.
> This query string is then added to the message body or the request IRI
> If the operation is POST or PUT, the query string value is serialized in
> the message body, no matter the value of whttp:ignoreUncited.
> It is unclear then whether section 18.104.22.168.2 should be considered in
> that case.
> If we do consider it, then if ignoreUncited=false, we are requested to
> serialize the data in the request IRI according section 22.214.171.124.3.
> This section dealing only with GET/DELETE requests, we can conclude that
> the data is not serialized in the request IRI (?)
> The example in section 126.96.36.199.4 follows that rule.
> If my understanding is right, then we should maybe clearly state that
> section 188.8.131.52.2 is only applicable to requests that have no body.
> If the operation is GET or DELETE, we have two cases:
> - If ignoreUncited=false, the query string is serialized in the
> request IRI
> - If ignoreUncited=true, the query string is not serialized in the
> request IRI.
> In the latter case, part of the input data is not serialized at all in
> the request. Is it the expected behaviour?