> From: Samuel Padgett/Durham/IBM > To: Paul McMahan/Raleigh/IBM@IBMUS, > Cc: [email protected], [email protected], Steve K > Speicher/Raleigh/IBM@IBMUS > Date: 06/20/2012 06:32 PM > Subject: Re: [oslc-cm] Updated State Predicates Proposal > > > From: Paul McMahan/Raleigh/IBM@IBMUS > > > > The consumer needs to know if state predicates are supported because > > otherwise the query results could be unpredictable. For example, if a > > consumer sent a query like oslc.where="oslc_cm:closed=true" then one > > service provider might include ALL of the change requests in the result but > > another service provider might include NONE, depending on their > > interpretation of the spec.
> Hey, Paul. My understanding of this scenario is that the query should never > return any results if the provider doesn't support predicates because no > resources will ever have that triple. I don't think it's ambiguous, although > I agree some providers could get it wrong. 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. > We could offer that guidance here in the CM spec, but I still feel it should > be in the Core query spec since it's not specific to predicates. It applies > to any property that a particular provider doesn't support. We still have an > open Core issue on this, Issue 42 [1]. > > I agree with Steve that the simplest way is to use > oslc.select=oslc_cm:closed and see if the triples are in the response. > > [1] http://open-services.net/bin/view/Main/OslcCoreV2Issues
