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

RE: issue 6712: updated proposal

From: Asir Vedamuthu <asirveda@microsoft.com>
Date: Thu, 4 Jun 2009 19:09:14 -0700
To: Christopher B Ferris <chrisfer@us.ibm.com>, Geoff Bullen <Geoff.Bullen@microsoft.com>
CC: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <D46B7A44F5BD0C4A96D7D69E31C51D6B58AC22C75D@NA-EXMSG-C118.redmond.corp.microsoft.com>
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 02:09:56 GMT

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