Re: [wsdm] [muws] comments on MUWS spec

[John Fuller <jfuller@wernervas.com>]

In the ASAP technical committee we're considering a state  
representation like this.

<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>

On Mar 11, 2004, at 10:55 AM, Sedukhin, Igor S wrote:

> 4.3.3. Really, why did it become TimeMetric?? In the schema appendix  
> it says [<xs:element name="CurrentTime" type="xs:dateTime"/>].... Is  
> this some recent change??
>
> 4.2.2 Representing states as Qnames would require one to have a schema  
> that describes the Qnames. I'm not sure what such schema would mean.  
> It would also require quite non standard schema interpretation and  
> inclusion of the schema in messages (e.g. to retrieve StateModel).
>
> This is an interesting idea, but we have to craft the solution  
> properly. The only value from this could be in applying Xpath  
> expressions to state when subscribing for notifications, but that  
> cannot be done with type derivation approach. Schema has to declare  
> the hierarchy. This is actually more easily implementable approach  
> when working with XML Schema processors.
>
> In othere words we would have
>
> <xs:element name="TransportUnavailable">
> 	<xs:complexType>
> 		<xs:sequence>
> 			<xs:element ref="muws:Unavailable"/>
> 		</xs:sequence>
> 	</xs:complexType>
> </xs:element>
>
> Now, I can easily interrogate the return value of CurrentResourceState  
> as
>
> Element el = response.getElementByName("Unavailable")
>
> I can also use this as a subscription "topic" expressions such as
>
> //TransportUnavailable
>
> //*/Unavailable
>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> -----Original Message-----
> From: Vambenepe, William N [mailto:vbp@hp.com]
> Sent: Thursday, March 11, 2004 11:26 AM
> To: wsdm@lists.oasis-open.org
> Subject: [wsdm] [muws] comments on MUWS spec
>
>
> Hi all,
>
> Here are some non-editorial corrections I would like the group to make  
> to MUWS 0.5.
>
> Regards,
>
> William
>
>
>
> 4.2.4: "CurrentResourceState" property: why "current". Aren't all  
> properties by default the current value unless otherwise specified? We  
> don't say CurrentResourceID, CurrentName, CurrentNumberOfMessages,  
> CurrentLastRestartDate, etc... So I propose to rename  
> "CurrentResourceState" to just "ResourceState".
>
> 4.3.3: Why is "CurrentTime" of type:muwsMetrics? It should just be  
> xsd:DateTime. There is absolutely no value in making "CurrentTime" of  
> type metric. It is a non-metric property used to support the use of  
> metrics. (note: in this case, the "current" kind of makes sense  
> because saying just "time" might be confusing)
>
> 4.2.2: Represent states with QNames rather than URIs. The reason is  
> that if you don't understand a URI you are stuck and can't go  
> anywhere, while if you don't understand a QName you can find out if it  
> is linked to other Qnames you understand and might still be able to  
> understand it enough to make use of it. To do so, here is a proposed  
> mechanism:
>
> A "linked chain QName" is defined recursively as a QName that points  
> to a restriction of either the simple type muws:BaseState (which MUWS
> defines) or a simple type represented by a "linked chain QName" itself.
> In addition, MUWS would mandate that all import statements necessary  
> to put a "linked chain QName" in scope MUST have a location attribute  
> pointing to the schema in which the QName is defined.
>
> Here are a couple of schema definitions for "chain linked Qnames" that  
> would represent states (I made up the examples, I am just trying to  
> illustrate the mechanism):
>
> In the muws targetnamespace:
>
> <xs:simpleType name="Unavailable">
>   <xs:restriction base="muws:BaseState"/> </xs:simpleType>
>
> In the mows targetnamespace:
>
> <xs:simpleType name="TransportUnvailable">
>   <xs:restriction base="muws:Unavailable"/> </xs:simpleType>
>
> In the "apache axis" targetnamespace:
>
> <xs:simpleType name="TomcatHTTPListenerDown">
>   <xs:restriction base="mows:TransportUnavailable"/>
> </xs:simpleType>
>
> We end up with states muws:Unavailable, mows:TransportUnavailable,  
> axis:TomcatHTTPListenerDown that are derivations of one another, in  
> that order. And this can be easily extended by anyone in their own  
> domain. If I am told by a managed object that it is in state  
> axis:TomcatHTTPListenerDown and I don't understand the axis namespace,  
> I can still find that this is a restriction of  
> mows:TransportUnavailable and treat it as such. And if I don't  
> understand the mows namespace either, I can go all the way back to  
> muws:Unavailable and that still gives me some information about the  
> state.
>
>
>
>
> 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/wsdm/members/ 
> leave_workgroup.php.
>
>
>
> 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/wsdm/members/ 
> leave_workgroup.php.
>