[oslc-cm] Updated State Predicates Proposal

Paul McMahan pmcmahan at us.ibm.com
Wed Jun 20 13:21:08 EDT 2012


> 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

oslc-cm-bounces at open-services.net wrote on 06/20/2012 11:56:37 AM:

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: oslc-cm at open-services.net
> Date: 06/20/2012 12:00 PM
> Subject: Re: [oslc-cm] Updated State Predicates Proposal
> Sent by: oslc-cm-bounces at open-services.net
>
> 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 at IBMUS
> > To: oslc-cm at open-services.net,
> > Date: 06/20/2012 07:45 AM
> > Subject: [oslc-cm] Updated State Predicates Proposal
> > Sent by: oslc-cm-bounces at open-services.net
> >
> > 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 | 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
>
>
> _______________________________________________
> Oslc-Cm mailing list
> Oslc-Cm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
>





More information about the Oslc-Cm mailing list