- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 8 Jan 2010 12:46:57 -0500
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OF3A5BFC08.032B7C0C-ON852576A5.00619272-852576A5.0061B390@us.ibm.com>
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 The more I'm around some people, the more I like my dog. Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> Sent by: 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" <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] On Behalf Of Ram Jeyaraman Sent: Tuesday, January 05, 2010 10:16 AM To: Doug Davis Cc: 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] Sent: Tuesday, January 05, 2010 10:02 AM To: Ram Jeyaraman Cc: 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 The more I'm around some people, the more I like my dog. Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 01/05/2010 12:57 PM To Doug Davis/Raleigh/IBM@IBMUS cc "public-ws-resource-access@w3.org" <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] On Behalf Of Doug Davis Sent: Monday, January 04, 2010 12:37 PM To: Ram Jeyaraman Cc: 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 </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 </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 The more I'm around some people, the more I like my dog. Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 01/04/2010 12:58 PM To Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" < 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] On Behalf Of Doug Davis Sent: Wednesday, December 09, 2009 7:48 AM To: 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 The more I'm around some people, the more I like my dog.
Received on Friday, 8 January 2010 17:47:57 UTC