[oslc-cm] Updated State Predicates Proposal

[Paul McMahan]

Thanks Sam and Steve for the helpful responses.

> What if the results of the query are really no results, even if the
> provider supports it?  Even in the case of using oslc.select and the
query
> returns 0 results, the selected property wouldn't be in the response due
> to no results.  Just an observation.

That was my next thought as well.  I am not sure that "sampling" the
service provider using oslc.select is a reliable or deterministic way for
consumers to detect whether state predicates are supported.   This is a
concern because several of the QM / CM integration scenarios that I know of
rely on state predicates.   If the CM provider doesn't support them then
the scenario should come to a halt pretty fast with an appropriate error
message or log entry explaining that the CM provider does implement the
necessary capabilities.

The current language in the CM spec which says that state predicates MUST
be queryable led me to a false sense of confidence that the scenario would
work with any CM provider that is fully compliant with the spec.   Its true
that each state predicate is defined as optional (occurring zero-or-one) on
an individual basis.  But that alone didn't lead me to the conclusion that
state predicates are optional on a collective basis.   Maybe I was seeing
what I wanted to see :-)

The proposed amendment does provide a better indication that consumers
should be wary of relying on state predicates, which is good.  But on the
other hand it weakens the statement that "predicates MUST be queryable" to
the point where I don't really understand its purpose.  i.e. what does it
mean to say that predicates MUST be queryable, but only if you implement
them?   As a CM consumer I am left wondering whether or not any given CM
provider can support my query.  I would almost rather see the spec say
something like predicates MUST be queryable unless the query shape
indicates otherwise.   But this would imply that opting out of support for
state predicates effectively means that support for query shapes goes from
SHOULD to MUST, which may not be too popular.  Another approach would be to
provide some type of clue in the CM service provider document.   Just
thinking out loud.


Best wishes,
Paul McMahan
IBM Rational