← Prev in month ← Prev in thread
Next in thread → Next in month →

Re: [asap] Discussion on state datatype

From
Kohn Guller
Date
2004-03-01T12:57:52+00:00
ID
Thread
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.

WSDM-ResourceStateV_05.doc

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:

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.
← Prev in month ← Prev in thread
Next in thread → Next in month →