Discussion on 262: Statuses

["Green, Alastair J." <Alastair.Green@choreology.com>]

Dear all,

The attached Word doc shows two different proposed textual redrafts for
section 5.1 of WS-Context.

In working through the proposed text (and thanks to both Peter and Tony
for comments), I became increasingly uneasy with the position of "having
our cake and eating  it" that we all centred on during the TC
discussion.

I have attempted to render this position into revised text which I
believe is precise and consistent, and which I could vote for. This is
Option 1 in the document.

Option 2 is offered for consideration as an alternative. It has the
advantage of introducing the notion of status, and of defining some
mechanics (faults) that all referencing specs are likely to find useful.

However, the Option 2 proposal differs in that it eliminates the "ur
state machine". (Diagram 10 and the defined values).

The problem I have with this state machine is that it is not "ur"
enough. And if I make it more basic, then it becomes truly trivial.
Either way, I think it is going to become an unused example, a
Habsburg's tail.

My concerns focus on the states COMPLETING and COMPLETED. 

COMPLETING: The notion that there is a distinct phase of processing to
achieve completion seems to me to be true of some referencing specs
(e.g. multi-phase transaction completion protocols), but not of others.
Why not have an INITIALIZING state, for example.

If we eliminate COMPLETING we end up with ACTIVE --> COMPLETED. This is
hardly profound, nor likely to be useful without further elaboration.
The problem with COMPLETED is that even things that end (and not all
activities end in any meaningful period of observation), typically have
more than one status. To take a simple example: SUCCESS or FAILURE. 

We are now in a situation where we can reasonably observe that an
Activity must come into existence (become ACTIVE), but pretty much
anything it does thereafter is a sequence of state transitions, where
the transitions and the states CANNOT USEFULLY BE DEFINED IN ADVANCE of
the referencing spec.

I therefore would prefer to go with Option 2 as being more realistic and
less misleading, although I think Option 1 is essentially harmless.

Please also note that Option 2 removes the definition of a type
wsctx:StatusType, as this is simply a typedef for Qnam (without usages)
becomes moot. 

You could argue that WS-Context, even if it eliminates the "ur state
machine", should define a status type, thereby ensuring that a reported
status is a scalar, thereby enabling some level of underlying common
implementation that will not have to vary across referencing specs. I am
not convinced we are adding anything to XML processing capabilities if
we do this. 

Alastair

2005-06-07.WS-Context.Section_5.1.Proposed.redraft.doc