[oslc-cm] State Predicates

[Samit Mehta]

> the idea is that
> an attempt to actually modify a state predicate value SHOULD result
> in a 409 error, but just having the value in the PUT request MUST
> NOT cause if an error if it's unchanged. This is true for both full
> and partial update.

Now I understand, so +1 on this approach as well.  I would be explicit
about the fact that a value was provided for the read-only property that
was different from the one in the resource.

This should be the behavior for all read-only properties, and I still think
should be captured in the CORE spec.  This way clients can expect
consistent behavior for any read-only properties.

___________________________________________________________________________
Samit Mehta
Lead Architect, ISV Enablement & Ready for IBM Rational software validation
IBM Rational Software - Business Development
(512) 323-9350 - Work
mailto:samit.mehta at us.ibm.com


Samuel Padgett/Durham/IBM wrote on 03/26/2012 02:00:38 PM:

> From: Samuel Padgett/Durham/IBM
> To: Samit Mehta/San Francisco/IBM at IBMUS
> Cc: oslc-cm at open-services.net, Paul McMahan/Raleigh/IBM at IBMUS
> Date: 03/26/2012 02:00 PM
> Subject: Re: [oslc-cm] State Predicates
>
> Hi, Samit. Thanks. My comments below.
>
> > > An attempt to update read-only
> > > predicates SHOULD be answered with a 409 Conflict HTTP status code.
Their
> > > presence in a resource representation used for an update via PUT MUST
NOT
> > > prevent the resource from being updated.
> > Would the first sentence above be applicable to update via PARTIAL
> > PUT only?  If yes, then let's add that to Sam's suggested update
> to the spec.
> >
> > Similarly, is the second sentence above be applicable to update via
> > PUT where the entire resource is provided in the request?  What is
> > the general recommendation (i.e. what's spec'd in the CORE spec) for
> > a PUT with regards to read-only properties?  I couldn't find a clear
> > indication in CORE spec on how a provider should handle read-only
> > properties being specified in the request document for an update of
> > resources via PUT.  It may be a good idea to be more clear about
> > this in the CORE spec, and possibly repeat it in the OSLC CM spec
> > for predicates to be more clear for someone reading the CM spec only.
>
> Maybe these statements could also be clearer, but the idea is that
> an attempt to actually modify a state predicate value SHOULD result
> in a 409 error, but just having the value in the PUT request MUST
> NOT cause if an error if it's unchanged. This is true for both full
> and partial update.
>
> > > There is a second issue...
> > > It's also not clear how providers should respond to requests for
> > > state predicates when they're not supported.
> >
> > +1 on the specification needing to be clear on how consumers can
> > know whether a provider supports a specific state predicate.  I
> > don't think it is relevant for the consumer to find out whether the
> > provider has support for state predicates in general, just a specific
one.
> >
> > How are the current providers (e.g. ClearQuest, RTC, and Change)
> > handling this currently?
>
> I believe ClearQuest returns a 400 Bad Request if you ask for a
> property that is not defined. I'm not sure about RTC and Change. The
> JIRA provider just leaves it out of the response.
>
> My preference is to simply leave it out of the response.
>
> - Sam