RE: Issue 8303

Analyzing this more:

The current definition [1] of Create and PutResponse does not allow using an extension element without the mandated first child element (containing the representation). That is, even though the use of representation in the Create and PutResponse is optional, but when extensions are used, the representation must be included as the first child element. This means that, in the Create case, extension elements cannot be used in the default case where the Create does not contain the representation (where the creation happens using pre-defined defaults).


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

Extension specifications are free to define mechanisms that would allow for using extension elements in the default case as long as they don't alter the base behavior (where absence of elements implies use of defaults). The key is to define extensions in a way that it does not alter the base behavior so that interoperability with resource managers that support only the base behavior is not affected.

Thanks.

[1]

[Body]/wst:Create
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. Additional extension elements MAY be included only after the mandated first child element.
[Body]/wst:PutResponse
This REQUIRED element, if it contains any child elements, MUST have as its first child element, an element that comprises the representation of the resource that has been updated. Additional extension elements MAY be included after the element representing the resource.
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Friday, January 08, 2010 9:47 AM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: RE: Issue 8303


Well, its not any harder to test than our requirement that extensions MUST NOT contradict the semantics of the parent.  Neither are really very testable  :-)

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

01/08/2010 12:37 PM

To

Doug Davis/Raleigh/IBM@IBMUS

cc

"public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>" <public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>>

Subject

RE: Issue 8303







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

Should we turn this into a guidance statement instead of a requirement? This may be hard to test. Thanks.

From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org]<mailto:[mailto:public-ws-resource-access-request@w3.org]> On Behalf Of Ram Jeyaraman
Sent: Tuesday, January 05, 2010 10:16 AM
To: Doug Davis
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: RE: Issue 8303

Clarification is good. Could you propose a concrete text for the clarification? Thanks.

From: Doug Davis [mailto:dug@us.ibm.com]<mailto:[mailto:dug@us.ibm.com]>
Sent: Tuesday, January 05, 2010 10:02 AM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: RE: Issue 8303


I think we might need to say something because we're the ones that are opening the door to (ie. creating) the ambiguity.  My concern with option 2 is that each extension might define a different way of doing this differentiation - which would itself be a nightmare.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>

01/05/2010 12:57 PM


To

Doug Davis/Raleigh/IBM@IBMUS

cc

"public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>" <public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>>

Subject

RE: Issue 8303











Yes, I am tending towards option 2. However, I am wondering why even say anything in the specification? (Since any extension specification that layers on the protocol specification has to clearly define the syntax and semantics of extensions anyway).

Thanks.

From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org]<mailto:[mailto:public-ws-resource-access-request@w3.org]> On Behalf Of Doug Davis
Sent: Monday, January 04, 2010 12:37 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: RE: Issue 8303


This isn't about an extension modifying base behavior.  Let's say I have an extension to send a notification email to someone:
<wst:Create>
<foo:bar> my data </foo:bar>
<zzz:email> user@here.com<mailto:user@here.com> </zzz:email>
</wst:Create>

This will create a "bar" object and send an email - so far so good.  Now I want to create a new object but let everything default:
<wst:Create>
<zzz:email> user@here.com<mailto:user@here.com> </zzz:email>
</wst:Create>

If the resource accepts an xs:any for the data how does the service know whether or not <zzz:email> is "the data" or "the extension" ?

It sounds like you refer option #2.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>

01/04/2010 12:58 PM




To

Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>" <public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>>

cc

Subject

RE: Issue 8303














The extensions should not alter the base behavior - this has already been made clear by the specifications. Extension specifications should define the syntax and semantics of the extension elements, how to construct/compose them, and how it relates to the base elements - I prefer to delegate this to the extension specifications and retain the existing extensibility points in Create/CreateResponse.

From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org]<mailto:[mailto:public-ws-resource-access-request@w3.org]> On Behalf Of Doug Davis
Sent: Wednesday, December 09, 2009 7:48 AM
To: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: Issue 8303


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<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.

Received on Friday, 8 January 2010 19:28:46 UTC