- From: Doug Davis <dug@us.ibm.com>
- Date: Wed, 9 Dec 2009 10:48:26 -0500
- To: public-ws-resource-access@w3.org
- Message-ID: <OF90A4FE49.5247A31F-ON85257687.0055A8D4-85257687.0056D7CF@us.ibm.com>
Looking over 8303 I think there might be a bigger issue here. I agree with Gil's edits (using MUSTs) but I think there's some confusion here. If we adopt Gil's edits, then the description of [Body]/wst:Create reads as follows: "This REQUIRED element MAY contain zero or more child elements. If this element does not contain a child element then the resource will be created using default values. The first child element, if present, MUST be the literal resource representation, a representation of the constructor for the resource, or other instructions for creating the resource. If present, any extension elements MUST be included after the mandated first child element." The problem is that if the clients doesn't send in the initial representation, it just wants the default values, how does the service know whether any extension element is an extension or part of the initial representation? The word "mandated" in the last sentence could be interpreted to mean that if you have an extension then you MUST also send in some element for the resource representation/instruction. If that's what we want to imply, then we should be more explicit. However, I'm not convinced that's correct since I don't think we want to lose the ability to not send in an initial representation just because we're also sending in an extension. I see two options here: 1 - remove the extensibility from the Create element and people can just use soap headers - then there's no ambiguity. 2 - add a sentence that says something like: If there are extension elements in the Create element then the definition of those extensions MUST define how to distinguish between the extension and the resource representation in cases where the resource representation is not present in the message. The same approach should be used for CreateResponse. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8303 thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com The more I'm around some people, the more I like my dog.
Received on Wednesday, 9 December 2009 15:49:35 UTC