I believe we need to craft the schema properly before saying we will use
QNames to identify the state.
-----Original Message-----
From: Vambenepe,
William N [mailto:vbp@hp.com]
Sent: Thu 3/11/2004 12:06 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Cc:
Subject: RE: [wsdm] [muws] comments on MUWS
spec
I am open to such changes in how we use schema to allow states
to be
somehow linked to one another (so that people who don't understand
a
specific state have a chance to find out which of the states
they
understand this is a specialization of). We are probably not going
to
finalize the mechanism today. Can we agree to make the simple change
in
MUWS 0.5 to use Qnames for states (instead of URIs) without
saying
anything else. This way, there won't be major incompatible
changes
between MUWS 0.5 and MUWS 1.0 if we put such a mechanism in MUWS
1.0.
William
> -----Original Message-----
> From:
Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
>
Sent: Thursday, March 11, 2004 8:55 AM
> To: Vambenepe, William N;
wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] [muws] comments on MUWS
spec
>
>
> 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/leav
e_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_workgrou
p.php.