Re: [wsdm] [muws] comments on MUWS spec

[John Fuller <jfuller@wernervas.com>]

If the "specialized states" aren't substates of the basic set of states,
should the extra information be expressed otherwise (ex: Ws-Context?)


On Mar 11, 2004, at 11:12 AM, Vambenepe, William N wrote:

>
> 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.
>