|
This is essentially what we have now. We used URNs to name the states and
then one could write a simpletype to restrict it based on a pattern. Also
patterns could be used to find out what state that is. For example.
Unavailable = urn:wsdm:unavailable
TransportUnavailable = urn:wsdm:unavailable:transport
Now, using XML elements as a representation and
identifying states with a QName has some advantages when doing XQueries
into resource properties that represent the state and also when subscribing
to the state changes using WS-Notification.
-----Original Message-----
From: John Fuller
[mailto:jfuller@wernervas.com]
Sent: Thu 3/11/2004 12:04 PM
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/leave_workgroup.php.
|