Looks good but still this statement stands out as seeming like they are required: "Predicates MUST be queryable." I propose this change: "If a service provider supports state predicates on change requests, then the state predicates MUST be queryable"
Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 > From: Samuel Padgett/Durham/IBM@IBMUS > To: [email protected], > Date: 06/20/2012 07:45 AM > Subject: [oslc-cm] Updated State Predicates Proposal > Sent by: [email protected] > > Following up on the state predicate thread [1] for spec Issue 12 [2], I > propose to following revised text to the state predicate section of the CM 2.0 spec. > > "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. Predicates MUST be queryable. If a consumer > includes predicates in oslc.where, oslc.select, or oslc.properties request > parameters, the provider MUST NOT respond with an error code based solely on > the inclusion of the predicates alone, even if the provider does not > implement predicates. The Change Request resource definition sections > defines the complete set of predicates." > > The revised text explicitly says predicates are optional, but also says that > they must not cause errors if included in requests. > > [1] http://open-services.net/pipermail/oslc-cm_open-services.net/2012-March/ > 000361.html > [2] http://open-services.net/bin/view/Main/CmSpecV2Issues > [3] http://open-services.net/bin/view/Main/CmSpecificationV2? > sortcol=table;up=#State_Predicates > -- > 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
