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
> 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_ 
> <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.
>
>
>
>