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 the document


Title: Message
More on the thread (<wv></wv>), where appropriate. We are converging... :-)
 
William

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.  

<wv>Then +1</wv> 

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? 

<wv>Just to make sure there is no confusion, because the sentence we are talking about introduces another web service, the manageability service. It might sound a bit pedantic, but really what's the harm of being extra-clear. It's not like the spec is hoping to get a Pullizer anyway... ;-)</wv> 

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

<wv>+1 then. I thought you wanted to say "using the disk service" INSTEAD of "reading sectors". "Along with that reading sectors from the disk using the service" is fine by me.</wv> 

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.  

<wv>I'm not convinced by it's not a big deal to me. If no-one else writes to support distinguishing these terms then let's do as you suggest.</wv> 

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.

<wv>I felt safe missing the last conf call because MUWS would not be discussed, but looks like people found a way to put more stuff in it anyway... :-). If we really need it, we need to move it in a place where people will see that it can be ignored if they understand our notation (which most people will). A place people skip over and only go back to if they have problems. Like an appendix or the "notation convention" section. And in any case, if the text can be useful the UML diagram is really overkill.</wv> 

 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?

<wv>Fine, +0 means I am neutral so I don't resist this change.</wv> 

 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?  

<wv>Sorry, I misread you. +1 to CurrentTime.</wv> 

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.

<wv>I am fine going with your suggestion.</wv>

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]