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


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]