[oslc-core] Need for a new specification phase/status: "deprecated"

[John Arwe]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120423/3366fcb0/attachment-0003.html>