[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] [muws] comments on MUWS spec
> Correction:
> <xsd:pattern value="unavailable.?\c*"/>
On Mar 11, 2004, at 11:23 AM, John Fuller wrote:
> Aside from the question of whether further qualification is for
> substates or specialization,
>
> to clarify, the idea was that
>
> <xsd:pattern value="open.running.?\c*"/>
>
> would allow the substate
>
> unavailable.transporterror.oraclespecifictransporterror
>
>
>
> On Mar 11, 2004, at 11:18 AM, John Fuller wrote:
>
>> 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.
>>>
>>
>>
>> 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.
>>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]