OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [asap] Discussion on state datatype

Here's some of the discussion I recall from recent WSDM calls.
The idea was that the resource could be available, degraded or unavailable.
I know there was some discussion as to whether the unavailable "state"
didn't so much belong to the resource as to the perception of the
manager of that resource.


On Feb 29, 2004, at 10:58 PM, James Bryce Clark wrote:

    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:

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" />
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]