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

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

Title: Message

My responses where they were necessary.

 

 

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?  

[IS] Yes. 

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". 

[IS] Great. 

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.

[IS] The sentence before it already says that service offers disk functions, why repeat it in the very next one? 

 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. 

[IS] Well one may read sectors from the disk using the service, not read them from the service itself. That is what I meant. So I wanted it to say "along with that reading sectors from the disk using the service".

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? 

[IS] It is sufficient for people to understand it from the text. Only the first time a term is introduced or defined it makes sense to italicize it. Otherwise the document will look funny with all those italicized everywhere. Captilatization is also bad for the same reason. 

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.

[IS] We have discussed this on the last telcon and decided to move the UML example to the MUWS document (this should have been recorded). Without the example the "illustrations" are not clear. We have to explain it. What was there in the MUWS document was not sufficient explanation of the approach that we've used.

I'm not sure either if we need that level of the formalizm in UML, but we either have it or we don't. Does not make sense to tease spec readers back and forth on this.

573 [in context]
In WSDM context.  

+0. 

[IS] Well. the sentense just does not read right otherwise [Figure 4.3.1-1 presents the Metrics capability in context] Which context it refers to? In the context of the universe?

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. 

[IS] It seems that you agree that it should be CurrentTime, right? Why -1 then?

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. 

[IS] Well, this is important. We do it one way or the other, not in many ways. Pick one.