Re: [asap] Discussion on state datatype

[John Fuller <jfuller@wernervas.com>]

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.