Sam, Thanks for raising this important issue.
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'm afraid that mixing language about individual state predicates being optional into the more general statement about query support doesn't add the needed clarity, at least for CM consumers. Instead it seems to imply that CM consumers would need to use some type of sampling or heurisitic to determine if they can send queries that include state predicates. 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. Best wishes, Paul McMahan IBM Rational From: Samuel Padgett/Durham/IBM To: [email protected] Cc: Paul McMahan/Raleigh/IBM@IBMUS Date: 03/26/2012 09:26 AM Subject: State Predicates The current spec language around state predicates is unclear. The ChangeRequest resource [1] lists them as optional properties. The state predicates section [2] of the spec says that they MUST be queryable, however, which seems to imply that they aren't optional. I suggest we update the spec to say, "Predicates are exposed as OPTIONAL single-value properties on a Change Request resource, often read-only. An attempt to update read-only predicates SHOULD be answered with a 409 Conflict HTTP status code. Their presence in a resource representation used for an update via PUT MUST NOT prevent the resource from being updated. If present, predicates MUST be queryable. The Change Request resource definition sections defines the complete set of predicates." There is a second issue of how consumers know if a CM provider supports state predicates. They can't rely on resource shapes since shapes are optional. It's also not clear how providers should respond to requests for state predicates when they're not supported. I've raised this latter problem as a possible core issue since I couldn't find guidance on how providers should respond to requests for any unsupported properties. [3] [1] http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#Resource_ChangeRequest [2] http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#State_Predicates [3] http://open-services.net/pipermail/oslc-core_open-services.net/2012-March/001256.html -- Best Regards, Samuel Padgett | IBM Rational | [email protected]
