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: state type



1 Originally (and the last draft) we had

<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:enumeration value="closed.abnormalCompleted.aborted"/>
</xsd:restriction>

</xsd:simpleType>

2 This was pretty limiting, so at one time I suggested just allowing certain prefixes

<xsd:simpleType name="stateType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="open.notrunning.?\c*"/>
<xsd:pattern value="open.notrunning.suspended.?\c*"/>
<xsd:pattern value="open.running.?\c*"/>
<xsd:pattern value="closed.completed.?\c*"/>
<xsd:pattern value="closed.abnormalCompleted.?\c*"/>
<xsd:pattern value="closed.abnormalCompleted.terminated.?\c*"/>
<xsd:pattern value="closed.abnormalCompleted.aborted.?\c*"/>
</xsd:restriction>
</xsd:simpleType>

3 More recently it sounded like we wanted to just let it be a string

4 I would like to propose stateType look like this

<xsd:simpleType name="stateType">
<xsd:extension base="xsd:string">
<xsd:attribute name="namespace" type="xsd:anyURI"/>
</xsd:extension>
</xsd:simpleType>

This is the way status, for instance, is defined in WS-Context.
This would mean,
we could just use strings like in 3) since the attribute would be optional,
if people have other specs to qualify the names they can provide it,
it's more architecturally friendly than QNames (see TAG findings about QNames in data)

***

5 Another alternative is to look at how state is represented in WSDM.
State is represented in WSDM-MUWS as an extension of the extensible "categorytype" they provide
to facilitate notification. In WSDM-MOWS, rules are provided for how to define substate semantics.

***

I think ASAP currently most closely resembles the representation in WSCAF-WS-Context,
so my preference is that we go with 4).




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