> 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:[email protected] [email protected] wrote on 03/26/2012 08:26:08 AM: > From: Samuel Padgett/Durham/IBM@IBMUS > To: [email protected] > Cc: Paul McMahan/Raleigh/IBM@IBMUS > Date: 03/26/2012 08:28 AM > Subject: [oslc-cm] State Predicates > Sent by: [email protected] > > > 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 | [email protected] > > > _______________________________________________ > Oslc-Cm mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net >
