> If a service provider supports state predicates on change requests, > then the state predicates MUST be queryable
It would be helpful clarify how that a consumer can detect that state predicates are supported. At one point we talked about checking the resource shape for the query capability to see if the state predicates are present. But providing this resource shape is not a MUST requirement, so it might not be present. The consumer needs to know if state predicates are supported because otherwise the query results could be unpredictable. For example, if a consumer sent a query like oslc.where="oslc_cm:closed=true" then one service provider might include ALL of the change requests in the result but another service provider might include NONE, depending on their interpretation of the spec. Best wishes, Paul McMahan IBM Rational [email protected] wrote on 06/20/2012 11:56:37 AM: > From: Steve K Speicher/Raleigh/IBM@IBMUS > To: [email protected] > Date: 06/20/2012 12:00 PM > Subject: Re: [oslc-cm] Updated State Predicates Proposal > Sent by: [email protected] > > 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 > > > _______________________________________________ > Oslc-Cm mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net >
