RE: [wsdm] [MUWS] comments on the document

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

Title: Message

Thanks for the detailed review. My comment below in blue.

 

William

82-97 What is the point of such summary? We've got requirements docs, just refer to them. Otherwise we can include a laugdty list of things like [MUWS can tolerate time zone differences]. 

+1 

The architecture section does not need to be summariezed that way too. That section is sufficiently structured already, IMO. 

Are you talking about 92-97? 

108 [The reader is familiar with the concept and principles of IT management system]
This is so vague and nonconcrete that I suggest this statement to be removed.

+0 (neutral)

 110 We need to include a reference to XML Namespaces spec (http://www.oasis-open.org/archives/wsdm/200403/msg00078.html)

+1 

 113-114 [All parts of this document are normative with the exception of examples and special sections that are specifically marked as non-normative.]

And so, Introduction section has not been marked non-normative and same goes for 2.1 and so forth. Are they all normative now? What is normative in those sections?

I suggest that instead, the statement is changed to indicate which EXACT sections are normative. And I believe that would be only 4,5,6 and D,E.

+1 

 150-151 [Since the Web services architecture defines how to specify information, operations, and notifications through WSDL interfaces]

I don't think WSA defines notifications via WSDL interfaces… That is an extension of WSA. I suggest notifications are removed from this statement.

+1 

 151-152 [locateability through endpoints]
What's that?

+1 to using real words. 

 154 [to provide the basis for providing]
Editorial.

+1

 156 [If a Web service can expose the functionality of an exposed resource through a Web service functional interface, then, a Web service can expose the manageabiity of the exposed resource.]

Editorial fix is needed for "expose*" use in the sentence.

How about: "the management interface of a resource can be exposed through a Web service interface in the same way that the functional interface can". 

 193 [that offers the disk functions]
This has to be removed from the sentense.  

-1. We want to make it clear that we are talking about management of the functional Web service interface, not the management interface. If you hae a better wording to propose we can change that, but simply removing this makes it confusing.

196-197 [along with that reading sectors from the disk service]
It should say "using the disk service".  

-1. Here too we want to make it clear that we are talking about the funtional interface of the service. Reading sectors is clearly part of the functional interface. "Using the disk service" is unclear. 

206 [Thus, manageability ]
"Thus" should be removed.  

+1. 

228-229 should say
[a "Metrics" WSDL interface description defined in a “http://www.docs.oasis-open.org/wsdm/2004/04/muws/wsdl” namespace]  

+0. 

239 The picture should be cropped to remove the bottom example part. It is not relevant anymore.  

+1. 

Section 2.4 onwards (througout the rest of the document): captialization of concept names must be fixed. It should all be lower case: "manageability provider" instead of "Manageability Provider", for example. 

We need to make it clear that we are using these terms as defined in the "concept" section. If we drop the capitalization, should we italicize? 

391 [in order to participate in MUWS]
Should say "in order to support MUWS specification".  

+1. 

391-392 I'm not sure it is necessary to list all capabilities defined in the section. Someone will have to always remember to update this list. 

+0. 

394-395 and throuout the rest of the document has to accommodate namespace separation (http://www.oasis-open.org/archives/wsdm/200403/msg00090.html) 

+1. 

397-398 has to incorporate UML example (http://www.oasis-open.org/archives/wsdm/200403/msg00081.html)  

-1 to the "example" UML (confusing, makes it look like there are naming convention on capabilities even though I know it's not what you mean). The semantic is attached to the individual operations, properties and events. Period. A "capability" has no semantic of its own, it is only a grouping of a certain set of operations, properties and events. I agree with what you are trying to say, but the form is too confusing. I don't think we need this level of formalism. -1 to forcing types defined in MUWS to have a UML representation. UML diagrams are just illustrations.

410 Property name capitalization in the UML diagram must match the capitalization in the property XML document and the schema. 

+1. 

421 [a resource properties document ]
Should say "a resource properties instance document"  

+1. 

428 onwards: fix [resourceId] to be ResourceId and bold.  

+1. 

485 [through Web services]
Should go.  

-1. But I would add "exposed" in front of "through Web services". 

492 Match the capitalization in the UML model.  

+1. 

530 [resource properties document ]
Instance document  

+1. 

550-553 and 561-564 [execute the Start transition according to the UML diagram]
Rephrase with states instead of transitions.  

Done in the current editors draft. 

570 [of a typical object property ]
Just the "property".  

+1. 

573 [in context]
In WSDM context.  

+0. 

573-576 [The Metrics capability requires that a currentTime metric be present, providing a reference point for the time-based attributes defined for the metric data types (§4.3.2). (Note that currentTime is a read-only metric and, consequently, the resetAll() operation has no effect on it.)]

This belongs to the defintion of the CurrentTime later in the text. This sentense is quite out of place there.  

+1

Also it is CurentTime not currentTime to be precise.  

-1. Currently we are mostly capitalizing the first letter, so I suggest we uniformize to this convention. 

578 fix capitalization in the diagram  

+1. 

604 and throuout the document [“MetricAttributes”]
I suggest that references to properties, operations or capability names are without quotes and in bold. That makes technical information visible and easily readable. Also this is the prevailing case in this and MOWS document right now, so it is easier to fix it in just a few places now. 

+0. 

645 Rename StartupInterval to SinceReset  

+1.