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.