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

["Vambenepe, William N" <vbp@hp.com>]

Hi Jeff,

> If a WSDM client understand semantically what muws:Unavailable and
> mows:TransportUnavailable means, then what is the advantage of being
> able to get to that starting with a axis:TomcatHTTPListenerDown? Why
> can't both the WSDM client and service use
> urn:mows:TransportUnavailable? After all the service knows it's
> returning a TransportUnavailable condition and the client knows it's
> receiving a TransportUnavailable condition, so why all the extra
> complexity?

Because there is additional semantic in axis:TomcatHTTPListenerDown that
would be useful to someone who understands the axis namespace. A
management console who gets this and knows how to manage Axis will know
where to go next. If it just got a mows:TransportUnavailable, some of
the information available at the manageability endpoint and that could
be useful to the manager would be lost.

In your proposal, you are basically saying people should not create new,
domain-specific, states and should stick to WSDM-defined states to make
sure everyone understands them. I think we need to provide support for
people to add states in separate namespaces while linking these states
to existing states to allow interop with people who don't understand the
new namespace.

Yes, if you want to take advantage of this feature you will need to
process XSD declarations. But:

- you are not forced to do it, you can treat the Qnames just like you
would treat URIs if you'd like (binraly understand/don't understand)
- XSD tools will do this automatically for you (which is why I added the
requirement that import statements provide a location, allowing XSD
tools to retrieve all that is needed to tell you all about the QName)
- It doesn't have to happen at each invocation, it is likely that in
many case the manager would retrieve a list of all states supported by a
managed resource, resolve them to Qnames it understand, cache this info,
and never have to worry about doing this XSD processing anymore for the
rest of its interactions with the managed resource

Finaly, what is the "exclusive canonicalization" issue you mention? It
is the fact that the prefix of Qnames is not fixed? Schema processors
can deal with that.

Regards,

William


> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com] 
> Sent: Thursday, March 11, 2004 8:44 AM
> To: wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] [muws] comments on MUWS spec
> 
> 
> William,
> 
> I am afraid I still don't see the advantage of using Qnames over URIs.
> If a WSDM client understand semantically what muws:Unavailable and
> mows:TransportUnavailable means, then what is the advantage of being
> able to get to that starting with a axis:TomcatHTTPListenerDown? Why
> can't both the WSDM client and service use
> urn:mows:TransportUnavailable? After all the service knows it's
> returning a TransportUnavailable condition and the client knows it's
> receiving a TransportUnavailable condition, so why all the extra
> complexity?
> 
> Won't the Qname approach require the WSDM client to parse through the
> XSD defintions  itself to derive the mapping? Now we are not talking
> about using XSD as input to a validator or code generator, but forcing
> the XSD client code to understand and be able to calculate XSD type
> semantics.
> 
> Also, how are we going to address the issue of exclusive
> cononicalization of Qname values (or rather the lack there of)?
> 
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
>  
> Try the industry's only 100% .NET-enabled identity management 
> software.
> Download your free copy of Universal IdP Standard Edition today. Go to
> www.opennetwork.com/eval.
>  
> 
> 
> -----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_workgrou
> p.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.