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]
