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

RE: Issue 6712 Discussion and Proposal

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Wed, 6 May 2009 12:55:37 -0400
To: 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>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
Message-ID: <OF7D114683.6138FEAB-ON852575AE.0051CB95-852575AE.005D0DD4@us.ibm.com>

I believe that what Doug is after is the equivalent of the ability to 
transfer (say) a SOAP envelope (XML) as text/plain rather
than as application/soap+xml. In that case, the SOAP envelope is not 
processed as a SOAP envelope (with all of the 
attendant processing specified in the SOAP spec) but as a blob of text 
that just happened to look an awful lot like a 
SOAP envelope.

If I understand Doug's position, he wants to be able to support a service 
that can accept both and process accordingly.

Doug, have I captured your point correctly?


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

Geoff Bullen <Geoff.Bullen@microsoft.com>
Doug Davis/Raleigh/IBM@IBMUS
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
05/06/2009 10:42 AM
RE: Issue 6712 Discussion and Proposal
Sent by:

> Even HTTP itself has a "message format" flag - its called 
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 
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. 
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Tuesday, May 05, 2009 3:11 PM
To: Geoff Bullen
Cc: public-ws-resource-access@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. 


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> 
Sent by: public-ws-resource-access-request@w3.org 
05/05/2009 01:05 PM 

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

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 
Defining the literal Resource to create: 
                              Resource Definition here 
Defining a set of rules to create a Resource: 
                              Rules here 
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: 
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. 

Received on Wednesday, 6 May 2009 16:57:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:49 UTC