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.

Received on Friday, 5 June 2009 12:54:47 UTC