> I just > hesitate to create a number of these "parked" spec statuses when one with > some explanation may suffice.
I'm not seeing the functional difference (for "clients" of this "interface"). Going back to Steve's original proposal [1], I see several different pieces of information being baked into the "deprecated" proposed state. Most of the discussion to date appears to be around other combinations of those same pieces of information, and whether or not each unique combination deserves it's own name. The pieces of information are likely fundamental, the name/not less so ... if clients are expected to take different actions based on the information, then named or not they are different states. [1] proposes that we define "deprecated" as the combination: (a) Specification should no longer be developed (b) implementations [JA: of the current spec] are not encouraged (c)indicate a possible way forward, if one exists (a) could be read to mean any one of the following (inclusive) - superseded - it's a dead end, we now think it's a bad idea, should start from scratch if same problems need to be solved -- that seems like a terminal state (Warning: Keep Out) - there is no longer enough energy to keep it moving forward -- that seems like an indeterminate state (suspended) Whether or not implementations should be encouraged is dependent on which reading of (a) one takes. If work was suspended because a second implementation was not worthwhile at the time, i.e. suspended, then there is no obvious reason to -discourage- new implementations either. If it was superseded/Warning:Keep-Out, you would discourage new to a greater/lesser degree. (c) appears to link back to the reading of (a) again... if the way forward is - "start over from scratch", that corresponds to "Warning: Keep Out" - create more implementations of the spec as it exists now, ... "suspended" - resolve questions/problems A, B, C, ... work was "suspended" at an earlier point in its maturity/life cycle My sense of the discussion is that there's no objection to using "deprecated" for the specific combination proposed, it's more about "if we're going to cover one case, we should cover most/all of the common cases at the same time" + a feeling that 'deprecated' does not fit all those cases equally well. Going back to the client's point of view, it seems like someone new just wandering into the spec list off the street is interested in a rather small number of questions: Q1: which spec should I implement to covers my needs? i.e. does/did the owning wg consider it "ready enough to implement" Q2: is there an active community around the spec that will answer questions and provide opportunities to test my implementation for interop? Q3: if there is nothing ready or actively being developed to cover my needs, how do I use this community to develop something new? [1] http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001284.html Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
