> From: Paul McMahan/Raleigh/IBM > To: Steve K Speicher/Raleigh/IBM@IBMUS, > Cc: [email protected], [email protected] > 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
