Paul McMahan/Raleigh/IBM wrote on 03/27/2012 10:55:57 AM: > > 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.
I think we're saying the same thing in a different way. (So we agree :) > 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 Sure, we can add this as well for clarity. -- Best Regards, Samuel Padgett | IBM Rational | [email protected]
