> However, we could say something like that about the state, but I'm > not exactly sure what... or even if that is true. Perhaps it "MAY > not" have the desired effect.
I'm not asserting that we need to. "Is it a gap?" is simply a due-diligence question. Remember that the thread-let started with your statement: > > The client cannot change its oslc_auto:state to make it eligible, as I was pointing out, by Devil's Advocate example, that such a strong reading of the spec is not IMO supported by the spec's current contents. Now that you seem to be agreeing that "weaker" readings are possible, viz > .... If providers want to allow non- > eligible requests to eligible ones they can, but there's no call for then our interpretations are compatible. I don't feel any particular need to explicitly call out this alternative in the spec. As you correctly point out, we have no in-scope (or other, for that matter) scenarios pushing for it so in a sense its speculative anyway. As long as the spec does not go out of its way to prohibit new behaviors that we might add in the future, "good enough" for me. Fine on the other topics; thread closed, from my perspective. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
