[oslc-cm] State Predicates

[Samit Mehta]

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

> 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 liked one of Sam's suggested solutions in his separate email to the the
Core team - provider MUST omit the unsupported state predicate(s) from the
response.  It seems simple.

___________________________________________________________________________
Samit Mehta
IBM Rational Software - Business Development
mailto:samit.mehta at us.ibm.com



oslc-cm-bounces at open-services.net wrote on 03/26/2012 08:26:08 AM:

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: oslc-cm at open-services.net
> Cc: Paul McMahan/Raleigh/IBM at IBMUS
> Date: 03/26/2012 08:28 AM
> Subject: [oslc-cm] State Predicates
> Sent by: oslc-cm-bounces at open-services.net
>
>
> The current spec language around state predicates is unclear. The
> ChangeRequest resource [1] lists them as optional properties. The state
> predicates section [2] of the spec says that they MUST be queryable,
> however, which seems to imply that they aren't optional. I suggest we
> update the spec to say,
>
> "Predicates are exposed as OPTIONAL single-value properties on a Change
> Request resource, often read-only. 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. If present, predicates MUST be
> queryable. The Change Request resource definition sections defines the
> complete set of predicates."
>
> There is a second issue of how consumers know if a CM provider supports
> state predicates. They can't rely on resource shapes since shapes are
> optional. It's also not clear how providers should respond to requests
for
> state predicates when they're not supported. I've raised this latter
> problem as a possible core issue since I couldn't find guidance on how
> providers should respond to requests for any unsupported properties. [3]
>
> [1]
> http://open-services.net/bin/view/Main/CmSpecificationV2?
> sortcol=table;up=#Resource_ChangeRequest
> [2]
> http://open-services.net/bin/view/Main/CmSpecificationV2?
> sortcol=table;up=#State_Predicates
> [3]
> http://open-services.net/pipermail/oslc-core_open-services.net/2012-
> March/001256.html
> --
> Best Regards,
> Samuel Padgett | IBM Rational | spadgett at us.ibm.com
>
>
> _______________________________________________
> Oslc-Cm mailing list
> Oslc-Cm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
>