> I think the right approach is for providers to simply leave predicate > values out of the response if they aren't supported for the change > request (as opposed to responding with an error). We could add > language here saying that. > > Does that satisfy your use case?
I think that would be an improvement. But perhaps some clarification about what the spec means by saying that predicates MUST be "queryable" would be even more helpful. From the POV of a consumer I would assume "queryable" means that when a predicate is included in the oslc.where, oslc.select, or oslc.properties request parameters the server MUST NOT respond with an error code based solely on the inclusion of the predicate alone. The consumer would also expect the content of the response to be complete and valid in terms of its correspondence with the the provider's Resource Shapes for Query Capability. If a provider does not have general support for state predicates then it SHOULD reflect this in its Resource Shapes for Query Capability. This doesn't seem like an additional buren on providers since the V2 spec already says: > OSLC CM service providers SHOULD support Resource Shapes for Query Capability as defined in OSLC Core Specification [1] >From the standpoint of CM consumers this clarification would provide better confidence that they can use queries involving predicates across any CM provider, while pointing out that they need to take the Resource Shapes for Query Capability into account when interpreting the results. [1] http://open-services.net/bin/view/Main/CmSpecificationV2#Query_Capabilities Best wishes, Paul McMahan IBM Rational From: Samuel Padgett/Durham/IBM To: Paul McMahan/Raleigh/IBM@IBMUS Cc: [email protected] Date: 03/27/2012 08:48 AM Subject: Re: State Predicates Thanks for your input, Paul. After reading Samit and your replies, I agree we need further clarification. > 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 think the right approach is for providers to simply leave predicate values out of the response if they aren't supported for the change request (as opposed to responding with an error). We could add language here saying that. Does that satisfy your use case? > ... 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. My concern is that this proposal introduces new MUST requirements into an already-final spec (rather than simply clarifying what's already there). We might be able to look at it for 3.0, though. - Thanks, Sam
