15 messages in org.oasis-open.lists.wsdmRE: [wsdm] [muws] comments on MUWS spec| From | Sent On | Attachments |
|---|---|---|
| Jeff Bohren | Mar 11, 2004 8:29 am | |
| Sedukhin, Igor S | Mar 11, 2004 8:41 am | |
| Vambenepe, William N | Mar 11, 2004 8:45 am | |
| John Fuller | Mar 11, 2004 8:51 am | |
| Vambenepe, William N | Mar 11, 2004 8:52 am | |
| Vambenepe, William N | Mar 11, 2004 8:58 am | |
| John Fuller | Mar 11, 2004 9:04 am | |
| John Fuller | Mar 11, 2004 9:09 am | |
| John Fuller | Mar 11, 2004 9:11 am | |
| Vambenepe, William N | Mar 11, 2004 9:16 am | |
| Jeff Bohren | Mar 11, 2004 9:30 am | |
| Jeff Bohren | Mar 11, 2004 9:42 am | |
| Sedukhin, Igor S | Mar 11, 2004 10:44 am | |
| Sedukhin, Igor S | Mar 11, 2004 11:19 am | |
| Vambenepe, William N | Mar 11, 2004 1:12 pm |
| Subject: | RE: [wsdm] [muws] comments on MUWS spec | |
|---|---|---|
| From: | Jeff Bohren (jboh...@opennetwork.com) | |
| Date: | Mar 11, 2004 9:30:16 am | |
| List: | org.oasis-open.lists.wsdm | |
William,
The exclusive cononicalization issue is strictly an XML Dsig issue. The problem is illustrated as by the following example:
1) A WSDM client create a WSDM request and signs it specifying exclusive cononicalization 2) The request is to an intermediate service, which processes the request and forwards it to the actual WSDM service 3) The WSDM service attempts to validate the signature 4) The validation fails because in step 2 mows:TransportUnavailable became TransportUnavailable because the mows namespace was found in a parent element
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:vb...@hp.com] Sent: Thursday, March 11, 2004 11:59 AM To: Jeff Bohren; ws...@lists.oasis-open.org Subject: RE: [wsdm] [muws] comments on MUWS spec
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:jboh...@opennetwork.com] Sent: Thursday, March 11, 2004 8:44 AM To: ws...@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:vb...@hp.com] Sent: Thursday, March 11, 2004 11:26 AM To: ws...@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.