Re: issue 6924: concrete proposal

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
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
06/11/2009 10:59 AM

To
Gilbert Pilz <gilbert.pilz@oracle.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
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
The more I'm around some people, the more I like my dog. 


Gilbert Pilz <gilbert.pilz@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org 
06/11/2009 01:56 AM 


To
"public-ws-resource-access@w3.org" <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 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.

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.