[oslc-cm] State Predicates

[Paul McMahan]

> 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.

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

Best wishes,
Paul McMahan
IBM Rational



From:	Samuel Padgett/Durham/IBM
To:	Paul McMahan/Raleigh/IBM at IBMUS
Cc:	oslc-cm at open-services.net
Date:	03/27/2012 08:48 AM
Subject:	Re: State Predicates


Thanks for your input, Paul. After reading Samit and your replies, I agree
we need further clarification.

> I am not sure how to interpret the statement : "If present,
> predicates MUST be queryable".   As you pointed out, each predicate
> is defined as zero-or-one on an individual basis.  Would saying that
> a predicate is "present" mean that the provider knows a value for
> it, or would it mean that the predicate would be present in every
> Change Request included in the response if the client was to ask for
> it?  In either case, how could the CM consumer detect this condition
> before deciding how to build a query URL?  And what would be the
> result of including a predicate in a query when the "If present..."
> condition will not been met?  Would the server return an error code,
> or would the query results be inaccurate, etc?

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?

> ...                              If the CM spec needs to explicitly
> accommodate providers that don't support state predicates at all
> then it might be better to require that they advertise this
> limitation in their resource shapes document or services catalog.
> Alternatively, if the CM workgroup believes that general support for
> state predicates is actually required by the V2 scenarios then the
> spec could be clarified to call that out instead.

My concern is that this proposal introduces new MUST requirements into an
already-final spec (rather than simply clarifying what's already there). We
might be able to look at it for 3.0, though.

- Thanks, Sam