OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]