[oslc-cm] Updated State Predicates Proposal

[Steve K Speicher]

> From: Paul McMahan/Raleigh/IBM
> To: Steve K Speicher/Raleigh/IBM at IBMUS, 
> Cc: oslc-cm at open-services.net, oslc-cm-bounces at open-services.net
> Date: 06/21/2012 11:35 AM
> Subject: Re: [oslc-cm] Updated State Predicates Proposal
> 
> 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.
>

Good background and feedback for what we can do better in the future. 
Saying something like all CR predicates SHOULD be queryable, may be all 
would be safe in 2.0.

- Steve