[oslc-cm] State Predicates

[Samuel Padgett]

Paul McMahan/Raleigh/IBM wrote on 03/27/2012 10:55:57 AM:

> > I think the right approach is for providers to simply leave predicate
> > values out of the response if they aren't supported for the change
> > request (as opposed to responding with an error). We could add
> > language here saying that.
> >
> > Does that satisfy your use case?
>
> I think that would be an improvement.  But perhaps some
> clarification about what the spec means by saying that predicates
> MUST be "queryable" would be even more helpful.   From the POV of a
> consumer I would assume "queryable" means that when a predicate is
> included in the oslc.where, oslc.select, or oslc.properties request
> parameters the server MUST NOT respond with an error code based
> solely on the inclusion of the predicate alone.

I think we're saying the same thing in a different way. (So we agree :)


> The consumer would also expect the content of the response to be
> complete and valid in terms of its correspondence with the the
> provider's Resource Shapes for Query Capability.   If a provider
> does not have general support for state predicates then it SHOULD
> reflect this in its Resource Shapes for Query Capability.  This
> doesn't seem like an additional buren on providers since the V2 spec
> already says:
>
> >  OSLC CM service providers SHOULD support Resource Shapes for
> Query Capability as defined in OSLC Core Specification [1]
>
> From the standpoint of CM consumers this clarification would provide
> better confidence that they can use queries involving predicates
> across any CM provider, while pointing out that they need to take
> the Resource Shapes for Query Capability into account when
> interpreting the results.
>
> [1] http://open-services.net/bin/view/Main/
> CmSpecificationV2#Query_Capabilities

Sure, we can add this as well for clarity.

--
Best Regards,
Samuel Padgett | IBM Rational | spadgett at us.ibm.com