[oslc-cm] State Predicates

[Paul McMahan]

Sam,

Thanks for raising this important issue.

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'm afraid that mixing language about individual state predicates being
optional into the more general statement about query support doesn't add
the needed clarity, at least for CM consumers.  Instead it seems to imply
that CM consumers would need to use some type of sampling or heurisitic to
determine if they can send queries that include state predicates.  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.


Best wishes,
Paul McMahan
IBM Rational



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


The current spec language around state predicates is unclear. The
ChangeRequest resource [1] lists them as optional properties. The state
predicates section [2] of the spec says that they MUST be queryable,
however, which seems to imply that they aren't optional. I suggest we
update the spec to say,

"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. If present, predicates MUST be
queryable. The Change Request resource definition sections defines the
complete set of predicates."

There is a second issue of how consumers know if a CM provider supports
state predicates. They can't rely on resource shapes since shapes are
optional. It's also not clear how providers should respond to requests for
state predicates when they're not supported. I've raised this latter
problem as a possible core issue since I couldn't find guidance on how
providers should respond to requests for any unsupported properties. [3]

[1]
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#Resource_ChangeRequest
[2]
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#State_Predicates
[3]
http://open-services.net/pipermail/oslc-core_open-services.net/2012-March/001256.html
--
Best Regards,
Samuel Padgett | IBM Rational | spadgett at us.ibm.com