[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