[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] [muws] comments on MUWS spec
Thanks John. This addresses the problem of linking a state to a given
basic set of states but not the generic problem of expressing that any
state is a specialization of another state. For example, the mechanism
below would not allow Oracle to define a state that is a specialization
(for their product) of a state defined by some DB industry consortium.
Regards,
William
> -----Original Message-----
> From: John Fuller [mailto:jfuller@wernervas.com]
> Sent: Thursday, March 11, 2004 9:05 AM
> To: Sedukhin, Igor S
> Cc: wsdm@lists.oasis-open.org; Vambenepe, William N
> Subject: Re: [wsdm] [muws] comments on MUWS spec
>
>
> 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.
> >
>
>
> 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/leav
e_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]