W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > December 2009

Issue 8303

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:16 GMT