|
Jamie,
Everyone needs to take a serious look at Appendix B
of the BCM
specifications.
This is about to become a public OASIS spec' - and
it includes
very serious capabilities for state management -
and much more.
This also transcends OCL with a simple XML approach
to solving
this. CEFACT tried OCL within UML - and
its really not designed to do
B2B state management, auditing, threads and the
feature set that
BCM is presenting as Linking and Switching - with
XML.
Thanks, DW.
----- Original Message -----
Sent: Sunday, February 29, 2004 11:58
PM
Subject: Re: [asap] Discussion on state
datatype
There's also quite a bit of work on a
taxonomy of availability states at our WSDM TC. I am tempting to ping
the co-chairs of that group in the hopes that they can hook you up with the
right discussion thread in their "management" work.
Keith, does that sound useful? I bet there's some
"re-usable" learning out there (although, at first glance, your extensible
OCL-ish format is very attractive). David, this would also hit ebXML I
think -- not sure if at this stage those signals are being kept by BP or MSG,
but somewhere, eh? Cordially Jamie
At 09:49 PM
2/28/2004, David RR Webber wrote:
Keith,
Two things - an
interesting list of states - but I think it would pay to discuss this list
with the BPSS team, ebMS team and also the BCM team.
A common list would be more effective.
On the schema side - if you want to do extended value
checking and semantics - then you should look at creating an OASIS CAM
template for ASAP. This would give you significantly better
fine-grained control of the content and structure - and also allow you to
use context * * *
----- Original Message -----
From: Keith Swenson
To: ASAP (E-mail)
Sent: Sunday, February 29, 2004 12:07 AM
Subject: [asap]
Discussion on state datatype
We have a
datatype definition for "State" to be:
<xsd:simpleType name="stateType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="open.notrunning" />
<xsd:enumeration value="open.notrunning.suspended" />
<xsd:enumeration value="open.running" />
<xsd:enumeration value="closed.completed" />
<xsd:enumeration
value="closed.abnormalCompleted" />
<xsd:enumeration value="closed.abnormalCompleted.terminated" />
<xsd:enumeration
value="closed.abnormalCompleted.aborted" />
</xsd:restriction>
</xsd:simpleType>
The purpose behind
making states as a sequence of dot separate values is that individual
implementation are supposed to be able to make extensions to this
set. For example, a company could make
"open.notrunning.beingBackedUp" or some such state. This 'adds
value' to the state. A partner of their may be able to understand
the nuance of beingBackedUp or might not. Never the less, anyone
will understand the beginning part "open.notrunning". * *
*
~ James Bryce Clark
~ Manager,
Technical Standards Development, OASIS
~ http://www.oasis-open.org/who/staff.shtml
~
+1 978 667 5115 x 203 central office
~ +1 310 293 6739 direct
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php.
|