W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > January 2010

RE: Issue 8303

From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
Date: Tue, 5 Jan 2010 17:57:49 +0000
To: Doug Davis <dug@us.ibm.com>
CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <503546C5699C1144BDEA0D0DFFE7F881181B4445@TK5EX14MBXC119.redmond.corp.microsoft.com>
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<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 Tuesday, 5 January 2010 17:58:26 GMT

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