RE: issue 6924: concrete proposal

I agree with Gil.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Friday, June 12, 2009 12:29 PM
To: Doug Davis
Cc: public-ws-resource-access@w3.org
Subject: Re: issue 6924: concrete proposal

I think you should replace all the highlighted "may"s with "could".

Your descriptive text looks fine.

- gp

On 6/11/2009 8:24 PM, Doug Davis wrote:

I've updated the spec per the resolution.  However there are two things I'd like people to think about:
1 - In this text:
- - - - - - - - -
Implementations MAY use the fault code wst:InvalidRepresentation if the presented representation is invalid for the target resource. The replacement representation **may** be considered to be invalid if it does not conform to the schema(s) for the target resource or otherwise violates some cardinality or type constraint. If an implementation detects that the presented representation is invalid it MUST generate a wst:InvalidRepresentation fault.

The replacement representation **may** contain within it element or attribute values that are different than their corresponding values in the current representation. Such changes **may** affect elements or attributes that, for whatever reason, the implementation does wish to allow the client to change. An implementation MAY choose to ignore such elements or attributes, or it MAY generate a wst:PutDenied fault.
- - - - - - - - -
There are a lot of "may"s (I put ** around the ones in question) and I'm not really sure we intended to use RFC2119 keywords in all of those spots.  I suspect "might" be more appropriate in at least some of them.  Gil?

2 - check the text around the new fault, I had to add some descriptive text so I made up:
  This fault is generated when a Put request message attempts to modify a portion of a resource but is not allowed to do so.
If people have a better choice of words please let me know.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.

Doug Davis/Raleigh/IBM@IBMUS
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

06/11/2009 10:59 AM

To

Gilbert Pilz <gilbert.pilz@oracle.com><mailto:gilbert.pilz@oracle.com>

cc

"public-ws-resource-access@w3.org"<mailto:public-ws-resource-access@w3.org> <public-ws-resource-access@w3.org><mailto:public-ws-resource-access@w3.org>, public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

Subject

Re: issue 6924: concrete proposal








This looks good to me - with the caveat that when we get around to defining policy (or whatever mechanism a client uses to know what's supported) we include some flag that the service can use to tell the client how it will act when it comes across read-only attributes (ie. ignore or fault).

On a more general note - in each spec we should probably start keeping a list of things like this that needs to be advertised.  Some things will be easy to remember but I'm worried that other things might fall thru the crack - like this one.  I'd like to see a placeholder of "things to advertise" in each spec so that people can provide us feedback on the list as the spec progresses but if that's not acceptable then a wiki would be good enough for now.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
Gilbert Pilz <gilbert.pilz@oracle.com><mailto:gilbert.pilz@oracle.com>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

06/11/2009 01:56 AM


To

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

cc

Subject

issue 6924: concrete proposal








Change the exposition of Put as follows:

A Put request MUST be targeted at the resource whose representation is desired to be replaced, as described in 2 Terminology and Notation<http://www.w3.org/2002/ws/ra/edcopies/wst.html#Notations_and_Terminology> of this specification.

Implementations MAY use the fault code wst:InvalidRepresentation if the presented representation is invalid for the target resource. The replacement representation may be considered to be invalid if it does not conform to the schema(s) for the target resource or otherwise violates some cardinality or type constraint. If an implementation detects that the presented representation is invalid it MUST generate a wst:InvalidRepresentation fault.

The replacement representation may contain within it element or attribute values that are different than their corresponding values in the current representation. Such changes may affect elements or attributes that, for whatever reason, the implementation does wish to allow the client to change. An implementation MAY choose to ignore such elements or attributes, or it MAY generate a wst:UpdateDenied fault. See 5 Faults<http://www.w3.org/2002/ws/ra/edcopies/wst.html#Faults>.

Other components of the outline above are not further constrained by this specification.

A successful Put operation updates the current representation associated with the targeted resource.

Add the following fault definition to Section 5:

5.2 wst:UpdateDenied
[Code]

s:Sender

[Subcode]

wst:UpdateDenied

[Reason]

One or more elements or attributes cannot be updated.

[Detail]

An optional list of the QNames of the elements or attributes that are not allowed to be updated.