[graap-wg] composition/extension model for states?

Karl Czajkowski karlcz at univa.com
Tue Mar 22 02:08:01 CST 2005


In both the term-level and my newly proposed agreement-level states,
there is a modeling concern as to whether domain-specific or
community-specific extensions of the state model are allowed.

  1. [I do not like:] allowing arbitrary new states to replace
     existing states in the basic machine, e.g. the state machine can
     be in "no state" according to a basic client/observer who doesn't
     recognize extended states.

  2. Allow "sub-states" which turn the basic state machine into a
     hyphergraph where specialized state transfers can happen "within"
     a generic state but transition rules between super states should
     be respected still.

     A. Encode sub-states as extensibility content within the basic
        state elements, meaning document structure follows the generic
        rules and extra content "flickers" within that structure.
        This approach can be applied recursively to extend extensions!

     B. Encode sub-states as sibling RPs to the basic state
        elements. This allows stacking/mixing of multiple state models
        but any consistency model between the various RPs is left
        unaddressed.

     C. Hybrid of (A) and (B) where basic non-extended content remains
        and a new extended variant is places alongside.  This avoids
        the consistency issue of having to inspect both generic and
        specialized RPs, and also avoids requiring basic clients to
        filter or "project" extended states down to the base version
        they recognize.

Do we have a clear consensus on which approach is advocated for
WS-Agreement?  I think extended states will be important both to
address domain-specific things like "job states" as well as to compose
with negotiation systems in the future.

Thoughts?


karl

-- 
Karl Czajkowski
karlcz at univa.com





More information about the graap-wg mailing list