|
And another major advantage of QNames is that they leverage XML
namespaces, allowing people to define extensions without risks of name clashes.
In the example below, two people could define a "transport" restriction of
urn:wsdm:unavailable and call it urn:wsdm:unavailable:transport but they woudn't
mean the same thing by that. This is a major problem.
But as I said on the call today, I am not married to QNames. All I care
about is a safe way to create substates in one's namespace (as opposed to in a
global namespace).
BTW, we are going to have the same problem when time comes to define
relationship types. We will define a few base types and will need to allow
people to specialize them. The "link chain QName" mechanism I wrote up was
designed to be usable in that context too. Let's make sure that whatever
mechanism we design for state can be used for relationships.
William
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.
|