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.