RE: issue 6712: updated proposal

Chris,

Asir seems to be saying: Its is the service that decides what gets sent to it.
IBM seems to be saying, perhaps, but because the payload can be one of a few different things,  we have found this nifty example where the service needs help from the client in order to distinguish what might be going on (the database example Doug uses)
IBM seems to further be saying, therefore we should add a new feature to the protocol to support it.

It is the last bit that concerns me the most at the moment.  By adding this attribute to the protocol, you are complicating all the other clients who don’t need or want this attribute (no-one has yet answered my question on this), plus, as Asir points out, the problem is service specific, and should be handled by the service (in this case the database service) using standard extensions specific to that service.  One possible example might be:

[Header]
    <myDBService:UseRepresentation s:mustUnderstand="true">
[Body]
    <wst:Create myDBService:isRepresentation="true”>
        stuff…
    </wst:Create>


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Friday, June 05, 2009 5:54 AM
To: Asir Vedamuthu
Cc: Doug Davis; Geoff Bullen; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: issue 6712: updated proposal

Asir,

Quite true. Yet, what you fail to point out is that the text following that which you quoted goes on to say:
"and MAY contain the literal initial resource representation, a representation of the constructor for the resource, or other instructions for creating the resource."

Which brings us back to Doug's issue. There is nothing here that says that a service cannot accommodate all of these in a single implementation. The question then becomes how to distinguish between them.

Again, this is the duality of which I previously wrote.

In the context of HTTP, the entity body of the HTTP POST message is given a type by means of a media type, which, in turn, informs the
recipient of the sender's intent.

If one sends an application/soap+xml then the message is governed by SOAP processing rules as prescribed by SOAP1.2. If one sends the
same literal representation as text/plain, or application/octet-streatm, then it is clear that the sender did not intend SOAP processing to be
applied, but rather that it be treated as plain old text or a bag of octets.

Quoting sentence fragments out of context to support a technical argument only tells part of the story.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986



From:

Asir Vedamuthu <asirveda@microsoft.com>

To:

Christopher B Ferris/Waltham/IBM@IBMUS, Geoff Bullen <Geoff.Bullen@microsoft.com>

Cc:

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

Date:

06/04/2009 10:12 PM

Subject:

RE: issue 6712: updated proposal

Sent by:

public-ws-resource-access-request@w3.org


________________________________



We want to point out that the Transfer Member Submission says that the contents of the first child element (in a Create message) are service-specific [1]. Just like HTTP POST [2], the interpretation of the contents of the first child is defined by the resource to which the create message is addressed!

[1] http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/#Create – “The contents of this element are service-specific …”
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 - “The actual function performed by the POST method is determined by the server …”

Regards,

Asir S Vedamuthu
Microsoft Corporation

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Christopher B Ferris
Sent: Thursday, June 04, 2009 6:21 PM
To: Geoff Bullen
Cc: Doug Davis; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: issue 6712: updated proposal

Geoff,

Nice use of the red herring defense.

The whole point of this issue is to provide the client with a means of conveying its intent.

Let's, instead, start with the following message as the child element of the Create:

<xsl:stylesheet version="1.0"
               xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
               xmlns="http://www.w3.org/TR/xhtml1/strict">
<html>
 <head>
   <title>Hi, Mom!</title>
 </head>
 <body>
   <p>Hi, Mom!</p>
 </body>
</html>
</xsl:stylesheet>

Presuming the service is an advanced piece of software that can process XSLT, but that was also designed to
operate like a SVN service, should it run the stylesheet and store the generated XHTML as the representation? Or,
should it instead simply store the stylesheet as the representation?

This has been the crux of Doug's issue all along. The duality inherent in the fact that an instruction also has a representation.
When does one treat it as an instruction and when as a representation? Only the sender can know its intent in this
context, and it certainly isn't an arbitrary distinction.

Doug would like to have the capacity to enable the client to assert how the content should be interpreted. That seems
completely reasonable. You don't like the proposal; that much is clear. So much so, in fact, that you are willing to change
the semantic of the submission specification in this case to avoid having to deal with the fact that the submission
contains an ambiguity that requires attention. Yet, when it comes to the issue related to @Mode, you, and others
from team WS-DD, claim that the semantics of the submission specification are sacrosanct and must be preserved at
all cost or else the sky will fall, or some such dreadful happening.

The cognitive dissonance is making my head hurt.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986

From:

Geoff Bullen <Geoff.Bullen@microsoft.com>

To:

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

Date:

06/04/2009 07:56 PM

Subject:

RE: issue 6712: updated proposal

Sent by:

public-ws-resource-access-request@w3.org




________________________________




Hi Doug,
So, if the client sends a representation that includes the element <priority>0</priority> and the value of zero is changed to the value of 3 by the service when the resource is created, is the representation the client sent over the “initial representation of the child resource” or not (i.e. should the flag be true or false)?

Can’t we just forget about trying to make this arbitrary distinction between resource and instruction (and thus the need for this new attribute) and instead, as Bob suggested at the last call, just change the wording in Create to use the term “payload” instead of using the words “literal resource or instruction”?

Regards,
Geoff

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Thursday, June 04, 2009 4:23 PM
To: public-ws-resource-access@w3.org
Subject: issue 6712: updated proposal


Upon thinking about 6712, I don't think the flag to indicate that Body is the representation, or an instruction, needs to be anything more than a boolean.  Clearly if its the data itself then the service will know what to do - just store it.  If its an instruction then the QName of the Body element will convey the instruction's definition.  So, my new proposal is the same as the old one but with the "Dialect" attribute changed to "isRepresentation".

Proposal:
Add a 'isRepresentation' attribute that explicitly tells the service
whether or not the child of the Create element is the literal representation
of the resource or an instruction.

<wst:Create isRepresentation="xs:boolean"? ...>
xs:any *
</wst:Create>

/wst:Create@isRepresentation
This OPTIONAL attribute, when present and set to 'true', indicates
that the child of this element is the initial representation of the
new resource. When present and set to 'false' this attribute indicates
that the child of this element is an instruction for how to create the
new resource. The default value for this attribute is 'true'.

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.