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

RE: Issue 6712 Discussion and Proposal

From: Geoff Bullen <Geoff.Bullen@microsoft.com>
Date: Fri, 29 May 2009 10:51:52 -0700
To: Doug Davis <dug@us.ibm.com>
CC: David Snelling <David.Snelling@UK.Fujitsu.com>, Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
Message-ID: <5AAAA6322448AA41840FC4563A30D6E8475A30CE05@NA-EXMSG-C122.redmond.corp.microsoft.com>
Hi Doug,
So to follow the logic here, we need to find "weasel words" to define a resource representation that will allow the service to "tweak the XML" so that my example below will be legal, but those same "weasel words" will somehow deliberately disallow that same service from accepting a Create message of the form:
<resource>
<issue>
    <Subject>AAA</subject>
    <Contents>BBB</contents>
   <priority></priority>
</issue>
</resource>

And disallow the service from generating the resultant resource:
<issue>
    <Subject>AAA</subject>
    <Contents>BBB</contents>
   <priority>3</priority>
   <issueNumber>12345</issueNumber>
</issue>

What justification do you have for allowing some "tweaking of the XML" but not allowing other similar "tweaking"?
Why are "wrappers" singled out for special attention?  Removing the wrapper element seems even more innocuous than changing the priority.

Best Regards,
Geoff

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, May 29, 2009 3:38 AM
To: Geoff Bullen
Cc: David Snelling; Gilbert Pilz; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: Issue 6712 Discussion and Proposal


Geoff,
  this discussion should really happen under Gil's new issue - 6975 - as I think we just need to find the correct wording (or weasel wording) to allow for the service to tweak the XML.  I don't think anyone would disagree with the idea that the service may, in certain situations, need to take these kinds of actions - which is, IMO, why Transfer uses words like "logical difference". I think that was its attempt to allow these kinds of things.
  However, this is not the usecase that is driving 6712 and whether or not the service is allowed to make these kinds of tweaks is not relevant to this issue.  This issue focuses on clearing up the ambiguity that exists on the Create.

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.

Geoff Bullen <Geoff.Bullen@microsoft.com>

05/29/2009 01:44 AM

To

Doug Davis/Raleigh/IBM@IBMUS, Gilbert Pilz <gilbert.pilz@oracle.com>, David Snelling <David.Snelling@UK.Fujitsu.com>

cc

"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>

Subject

RE: Issue 6712 Discussion and Proposal







Hi Doug, David and Gil,

Let me try a slightly different approach to reaching some common understanding on this issue.  It appears one of the main sticking points is around trying to come to a definition of "literal resource representation" and "instructions".   This is understandable, since if you want to define a dialect to select between the two, the client will need to be able to accurately determine which one it is sending and use the right dialect value.

So help me out here, please.  Let's say we have a service that is associated with maintaining an issues list.
The client wants to create a new issue, and sends a create message with:
<issue>
    <Subject>AAA</subject>
    <Contents>BBB</contents>
   <priority></priority>
</issue>

Now the Service then creates an issue that looks as follows:
<issue>
    <Subject>AAA</subject>
    <Contents>BBB</contents>
   <priority>3</priority>
   <issueNumber>12345</issueNumber>
</issue>

This is also what would be returned in a Get Response.  Note that the service has added in the issue number, and has changed the priority to the default value of 3.

Question: Is the create message a literal resource representation?

If yes, then how do you define a literal resource representation to include this use case and what, then, is a set of instructions?

If no, what is it, a set of instructions?  If it is a set of instructions, how is the client to know that it should mark this as a set of instructions rather than as a literal resource representation?  It seems that almost everything would have to be marked by the client as a set of instructions, because the client would not know if the server was going to change anything or not.

I hope your answers to these questions will help gain a mutual understanding of this issue.
Thanks,
Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Thursday, May 28, 2009 5:30 PM
To: Gilbert Pilz
Cc: David Snelling; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: Re: Issue 6712 Discussion and Proposal


That's right.  Since Transfer itself doesn't define any "instructions" (aka extensions) to go into the Create then the default case is the one where the XML represents the literal representation of the resource.  And since the spec itself calls out the use of instructions (aka defines the extension point) it must provide a means for an implementation to know when those extensions are being used - like we cleared up in [1].  But Dave is also correct that one option is to simply remove this extension point.  Those really are the only two options I see.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6594

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.
Gilbert Pilz <gilbert.pilz@oracle.com>
Sent by: public-ws-resource-access-request@w3.org

05/28/2009 07:23 PM


To

David Snelling <David.Snelling@UK.Fujitsu.com>

cc

public-ws-resource-access@w3.org

Subject

Re: Issue 6712 Discussion and Proposal











Dave,

W/respect to (d) it seems to me that the client can always turn around and do a Get on /wst:CreateResponse/wst:ResourceCreated and check to see if what got created was what it expected but this seems like an awfully inefficient and error prone way of solving this problem.

I agree with you about the @Dialect attribute. I think it is the cleanest way to solve this problem. It should also be accompanied by a class of nested policy assertions that the resource manager can use to advertise which dialects it supports. Since @Dialect and these policy assertions are optional, the base case collapses to your solution (a), which is to use the 'literal resource representation'.

- gp

On 5/11/2009 2:16 AM, David Snelling wrote:
Folks,

It is clear to me that there are 2 semantics inferred in the T-spec for create that a service may support.

1) Make the payload the resource.

2) Use the payload in some way to make the resource.

As Geoff pointed out the service gets to decide which it supports or if it supports both. The spec is not even clear which is the default mode, so a client should consult a policy framework before proceeding. So we at least need to define a pair of URIs to use in a policy framework. As it stands the service may behave contrary to the client's assumption and the client will remain totally unaware of what semantic the service acted on.

I prefer the Dialect proposal, but I see a couple of other solutions. a) We could mandate a single semantic only, probably (1) above. b) We could allow both but a service MUST advertise which it supports in a policy framework. c) Add another version of the create operation, d) Mandate that the service always send back the resulting representation, so the client can check it and retry if the result is not what was expected.

On 07 May 2009, at 14:20, Doug Davis wrote:


Geoff,
 I forgot to mention that your solution actually doesn't work.  As a service there are two types of Creates I might support (both legal and advocated in the T spec):
1) Create where I pass in the xml representation as a child of the Create
2) an 'instruction based' Create where the QName of the Create tells me the instruction
Obviously the QName of the child element in case #2 is not defined by T so it will be service specific.  However, case #1 is something that should work across all implementations of Transfer.  As a service provider if I want to offer up both, your solution would not work for me.  You're asking me to remove case #1 and make my implementation totally non-interoperable.  Yes, clearly, case #2 will only be interoperable with other endpoints that know about my service specific QName and that's ok.  However, what's not ok is for me to have to remove case #1 because that's the baseline for interop that I need to ensure the broadest support.  So, in terms of "bad architectural decisions" that one would be pretty high on my list.

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.
Doug Davis/Raleigh/IBM@IBMUS
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

05/06/2009 09:07 PM




To

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

cc

Subject

RE: Issue 6712 Discussion and Proposal













I actually agree.  The WS-Transfer team that wrote the spec made a very bad architecture decision by explicitly saying that something can be done but not provide a way for it to actually happen.  Glad we can finally agree on something.

I accept your modified proposal to rename the attribute.

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.
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>

05/06/2009 08:56 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 6712 Discussion and Proposal













Doug,
>From the email below, we assume that:

<Body>
<doit xmlns="urn:foo"/>
</Body>

Actually means:

[Body]
<create>
<Body>
<doit xmlns="urn:foo"/>
</Body>
          </create>

The server is in complete control of definition and contents of the first child element, in this case an element called "body".

The line of reasoning followed by IBM in the mail thread below seems to be that the Server implementer deliberately chooses to use the "body" element above, so that the Server code cannot tell the difference between the incoming elements in a Create message.  The implementer does this rather than choosing a different strategy such as the one we suggest below, where the Server could easily tell the difference.

This same line of reasoning seems to continue that, because it is possible for the Server implementer to make such a really bad architectural decision, the WG should accommodate this use case by creating an brand new attribute in the Transfer spec (just for Create) to allow the client the specify which one is really meant.  But, of course, the Server implementer, having worked out that it is a really bad architecture, now has to also add new Server code to support this new attribute in order to "hack the fix in", rather than simply add code to correct the actual architectural issue.

Perhaps we should call this new attribute <create usingReallyBadImplementation="1"> ?

--Geoff


From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, May 06, 2009 3:45 PM
To: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: RE: Issue 6712 Discussion and Proposal


The server. If the server supports both (meaning it accept both an instruction and storing of xs:any) and the Body looks like:
<Body>
<doit xmlns="urn:foo"/>
</Body>

is it a chunk of XML or is it the "doit" instruction?  It (the server) can't tell.

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.
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

05/06/2009 06:29 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 6712 Discussion and Proposal


















> ... but doesn't provide a way to unambiguously know which it is.

Doug,
Who is it that has to unambiguously know?  The client?  The server?  Each of these does unambiguously know.
--Geoff

From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, May 06, 2009 3:22 PM
To: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: RE: Issue 6712 Discussion and Proposal


Geoff,
that solution, while technically possible, implies that we can not use Transfer the way it was designed.  It says:

[Body]/wst:Create
If this REQUIRED element contains children then the first child MUST be the literal resource representation, a representation of the constructor for the resource, or other instructions for creating the resource.

It allows for the immediate child of the Create element to be either the XML or an instruction, but doesn't provide a way to unambiguously know which it is.

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.
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>

05/06/2009 05:56 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>>, "public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>" <public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>>

Subject

RE: Issue 6712 Discussion and Proposal



















> If I have a transfer service that is storing a blob of xml in a DB and it allows the XML to be anything - how do I know if the client meant for it to be stored "as is" or for the QName to indicate an instruction?  Assuming of course that the service supports instructions as well.

Doug,
The Transfer service is in control, it knows its own content, and it knows the difference between blobs and instructions.  If the situation quoted above arises for a particular Transfer service, then it could easily distinguish between blobs and instructions using some strategy such as:

Request from client to transfer service to create a blob:
[body]
<create>
 <blob>
    ... contents of blob to be stored in DB (any XML can be put here) ...
 </blob>
</create>

Request from client to transfer service to create resource using a set of rules:
[body]
<create>
 <MyInstructions>
    ... set of instructions defined here (only instruction specific XML can be put here) ...
 </MyInstructions>
</create>


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, May 06, 2009 7:54 AM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>; public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>
Subject: RE: Issue 6712 Discussion and Proposal


> Even HTTP itself has a "message format" flag - its called "Content-Type".

Doug, it is good that you are wanting to model Transfer after HTTP.  The Content-Type field is used to indicate the media type of the underlying data. The media type of a SOAP message is well defined. The type of the first child element of a Create message can be inferred from the QName of the first child element.

I wouldn't assume that ;-)  I only mentioned it because I know you like to make the comparison.  I actually am not fond of it because you're being very selective about which bits of HTTP to mimic - basically just the ones you like and ignoring the others.  For example, HTTP has the notion of fragments - two different ways (# in the URL and Range headers).
As for the QName... see below.

> the QName of the child can tell you most everything you need to know - however, the one case of the resource being an xs:any is still left ambiguous

Why is this ambiguous and to whom is it ambiguous?  Even though it has been defined as an xs:any in the Transfer schema, it is clearly defined by the Service that implements it (this is stated by the spec).  It is not ambiguous to the Service at all, nor the client, since the client knows what the Service demands.

If I have a transfer service that is storing a blob of xml in a DB and it allows the XML to be anything - how do I know if the client meant for it to be stored "as is" or for the QName to indicate an instruction?  Assuming of course that the service supports instructions as well.

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.
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>

05/06/2009 10:39 AM








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>>, "public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>" <public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>>

Subject

RE: Issue 6712 Discussion and Proposal



















> Even HTTP itself has a "message format" flag - its called "Content-Type".

Doug, it is good that you are wanting to model Transfer after HTTP.  The Content-Type field is used to indicate the media type of the underlying data. The media type of a SOAP message is well defined. The type of the first child element of a Create message can be inferred from the QName of the first child element.

> the QName of the child can tell you most everything you need to know - however, the one case of the resource being an xs:any is still left ambiguous

Why is this ambiguous and to whom is it ambiguous?  Even though it has been defined as an xs:any in the Transfer schema, it is clearly defined by the Service that implements it (this is stated by the spec).  It is not ambiguous to the Service at all, nor the client, since the client knows what the Service demands.

--Geoff


From: Doug Davis [mailto:dug@us.ibm.com]<mailto:%5Bmailto:dug@us.ibm.com%5D>
Sent: Tuesday, May 05, 2009 3:11 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>; public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>
Subject: Re: Issue 6712 Discussion and Proposal


This does not address the usecase that I'm worried about [1] nor the issue.  Even HTTP itself has a "message format" flag - its called "Content-Type".  In cases where there are multiple ways to interpret the data (which is something that Transfer itself promotes) it only seems logical for Transfer to provide the mechanism by which users of the spec can do that.  We don't need to specify much since the QName of the child can tell you most everything you need to know - however, the one case of the resource being an xs:any is still left ambiguous.

[1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0142.html

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.
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

05/05/2009 01:05 PM










To

"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

Issue 6712 Discussion and Proposal




















After further consideration of Issue 6712 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712), which concerns the Create message in Transfer, we don't really think it matters if the spec is inferring that a given service or resource can support more than one format of Create Message or not.  First, a few assumptions:
a)     Each Service is ultimately responsible for deciding what type and format of information is sent in a Create message.
b)     Each Service will define its own set of "creation rules" (if any) which will be used to create its resources.  That is, the WG will not define some common creation rules language that will be used by all resources.  A Service may even support more than one format of creation rules if it wants to.

Since the service is responsible for providing the definition of each Create message format it supports, it is also responsible for demining how it will tell the difference between those multiple formats when they occur in a Create message.   One way that the service might easily do this is as follows:

Defining the literal Resource to create:
[Header]
         <wsam:Action>.../ws-tra/Create</wsam:Action>
[Body]
<Create>
         <xxx:MyResource>
                        Resource Definition here
         </xxx:MyResource>
</Create>

Defining a set of rules to create a Resource:
[Header]
         <wsam:Action>.../ws-tra/Create</wsam:Action>
[Body]
<Create>
         <xxx:MyRules>
                        Rules here
         </xxx:MyRules>
</Create>

In the end, there is no real difference between these two examples. It is not clear then what the value is in providing a means within the protocol for determining the message format (e.g. a resource or rule flag).  Since the resource (service) is responsible for the definition of both "MyResource" and "MyRules" there is literally nothing extra in the Transfer protocol that is needed to help the resource understand the type of "instructions" it has been sent in a Create message.  To add some flag to the Transfer protocol seems purely redundant and unnecessary.

Based on the feedback from the WG, it does seem like some clarifying text is required, we propose:

[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, is service-specific (or the interpretation of the first child element is defined by the resource to which the create message is addressed) and 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.

--Geoff




Take care:

   Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
   Fujitsu Laboratories of Europe Limited
   Hayes Park Central
   Hayes End Road
   Hayes, Middlesex  UB4 8FE
   Reg. No. 4153469

   +44-7590-293439 (Mobile)
______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.
Received on Friday, 29 May 2009 17:57:54 GMT

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