Re: [ws-caf] Discussion on 262: Statuses

[Mark Little <mark.little@arjuna.com>]

I'd go for 5.2 too. I think it's more manageable in the long term and is 
a cleaner model overall.

Mark.


Green, Alastair J. wrote:

>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
>