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

Issue 6712 Discussion and Proposal

From: Geoff Bullen <Geoff.Bullen@microsoft.com>
Date: Tue, 5 May 2009 10:05:20 -0700
To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <5AAAA6322448AA41840FC4563A30D6E843A0747D99@NA-EXMSG-C122.redmond.corp.microsoft.com>
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:
                              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 Tuesday, 5 May 2009 17:06:05 UTC

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