[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] MOWS Document Comments
Replies on replies, moved up here. 2. Headings - I like your suggestion of "Manageability Representation Topics" as the heading for 2.1, and would prefer "Model" for 2.1.3, especially since the headings are "Mod .x" :-). 4. About [Overall 2.], Mark says "the model we will come up with will be pure UML that includes both data (properties), behaviour (operations) and events. This can be further rendered into a CIM model and then as CIM-XML, however I missing something about CIM models here?" I think that you may be missing something :-). CIM is about semantics and can be render in UML or MOF. The original spec was written in the mid 90's and is being updated to take advantage of the newest UML spec, stereotypes, etc. In the mean time, CIM includes everything that you list above - properties, operations and events/indications - and its semantics (even if the MOF language is ignored) can/should be reused. OTOH, rendering UML in MOF removes a lot of ambiguities that get missed with UML/pictures. I am not necessarily advocating WBEM - which is the specific CIM-XML encoding, but I see NO need to reinvent semantics and see nothing that is contrary to what CIM has defined. This work would easily build on CIM's concepts. CIM is an evolution, not a static definition. 5. Met 1 - The discussion on the call last week clarified this, for me. However, the current wording in the document needs to be stronger (IMHO). Could I recommend using some of your words - "[Met. 1.] The manageability representation MUST support the concept of metrics, i.e. the ability to define and track metrics [22]" 6. Mod 6 - Your wording works for me "The manageability representation MUST NOT be specific to a particular data or interface representation." 7. Chng 6, "The manageability representation SHOULD enable grouping of changes. The notion of /change package/ allows for a collection of changes to be described as "all or nothing". Mark says "this is a notification not an action". Given this comment, I think that it is incorrect to state "all or nothing". I would reword the requirement as "The manageability representation SHOULD enable grouping of changes. The notion of /change package/ allows for a collection of changes to be described as a group, and notifications reported on the group as a whole." Andrea -----Original Message----- From: Potts, Mark [mailto:mark.potts@hp.com] Sent: Friday, September 26, 2003 3:41 PM To: Andrea Westerinen; Igor.Sedukhin@ca.com Cc: wsdm@lists.oasis-open.org Subject: RE: [wsdm] MOWS Document Comments Andrea Responses below... Lets discuss Monday if we can > Feedback on the Management Of Web Services: > > 1. Since every requirement references "Manageability > Representation", it is really important to define it clearly. > In fact, I believe that it is the same as the "manageability > capabilities" of MUWS, but adds the abstract semantic > definition (information modeling) on top. Of course, I may > be totally wrong in this and need to be reset. I think "Manageability Representation" (MR) should be defined in the glossary consistent with MUWS and "Manageability Capabilities". You should have an e-mail from me as a response to your last mail on that thread. > > 2. I think that it is problematic to have a central term, > "manageability representation", and headings that use this > term, 2.1 Manageability Representation and 2.1.3 > Representation. The entire document is about "manageability > representation". We need to rename sections 2.1 and 2.1.3 > (perhaps to "Model" and "Capabilities and Perspectives", > respectively??). I think that 2.1 can stay the same or perhaps clarified to MR Topics - all the subsections are simply requirements grouped by topic of category. Your right about 2.1.3 however and we need to either change this to model (but that is so overloaded). The other option is to move these to Overall section 2 as a subsection called Representation specific. I think prefer the latter but happy to hear other suggestions. The most important fact is that we have them captured and not how they are categorised or where they appear. > > 2. Page 8, Overall 1 - The requirement distinguishes between > "management and provisioning". It seems that management > includes provisioning. Should provisioning instead be > specifically added to the list of capabilities in Overall 3? Igor can you reword this to be consistent with what's been put into MUWS. > > 3. Page 5, last paragraph (continuing on page 6) - This text > does not seem to fit in a "glossary" section. It should be > moved/removed. This is an open item and Igor William and I are trying to come to consensus on this. > > 4. Page 8, Overall 2 - Clarify that a "specific model > representation" is really a specific "data model" > representation and the example is "(e.g., CIM-XML)" and not > CIM directly. In fact, CIM itself IS expressed as a > UML-based model - since MOF is only a textual rendering of UML. I still think [Overall 2.] is right, but feel free to retort - the model we will come up with will be pure UML that includes both data (properties), behaviour (operations) and events. This can be further rendered into a CIM model and then as CIM-XML, however I missing something about CIM models here? <arw> The distinction > > 5. Page 8, Met 1 - Is the MUST requirement that metrics exist > but that they may only be defined in specific data models? > Otherwise, I think that we have to define some base metrics > and their semantics. It does not make sense to say that the > representation MUST have metrics, but that none are specified > in the UML abstraction. Since Met 1 is a MUST, doesn't this > mean that there is some minimum set of metrics (defined in > support of Met 6) that MUST be implemented? If so, we should > be explicit about this in the requirements. Met 1 says the model must support the concept/definition of metrics and allow them to be tracked. When we define the model we may decide there is a minimum set that have to be supported, Met 6 is stating that, but the specification will determine exactly what that KEY set is. > > 6. Page 9, Mod 6 - Can this be clarified to indicate that we > are talking about information encoding and wire transmission > (ie, bindings)? Perhaps saying "The manageability > representation MUST NOT be tied to a specific XML Schema > representation, binding and/or interface"?? I think that's what it says, and relates to Overall 2, but if its not clear how about.. "The manageability representation MUST NOT be specific to a particular data or interface representation." It may actually be a dup of Overall 2 and could be scrubbed? > > 7. Page 10, Chng 6 - The text "all or nothing" reads to me as > transactions. This seems to indicate that transactions > SHOULD be discussed in MUWS. If something else was intended, > this is not clear. The changes that are defined can simply be grouped such that they are determined to be related and all occurred as a result of one action, this is a notification not an action remember. > > 8. Section 4 should be removed in lieu of explicit references > to MUWS. If we want to further clarify MUWS requirements or > make them stronger (SHOULD to MUST), then we should reference > the MUWS requirement directly. I don't think that it is > acceptable for MOWS to dictate a MUST or SHOULD that it not > at least a SHOULD or MAY in MUWS. Agreed - we need to remove this and pass it onto MUWS editors such that they can ensure they are covered in MUWS requirements. > > 9. There are some grammar issues: > - Page 4, First paragraph - Should end with ":" since the following > sub-headings supply the info indicated in the sentence > - Page 4, under "deliverables" sub-heading - Should be a period after > Jan 2004, and "this includes ... " should be the start of a new > sentence (with appropriate capitalization) > - Page 4, second sentence under "Initial Focus" - Is a run-on > and "address" > should be changed to past tense. The sentence should > be rewritten > as "However, it is expected ... will also need to be addressED > in the tenure of the WSDM TC. These include, but are ..." > - Page 5, second paragraph under "WSDL described web service" > - "endpoint" > in the second sentence should be plural (ie, "A binding, ..., is > accessible via one or more endpointS ..." > - Page 9, Mod 1 - Remove the "a" before "consumer" > - Page 10, Life 7 - Suggest rewording as follows: "The manageability > representation SHOULD support a "ping" to a Web service that > does not change the service's state" > > 10. One item needs clarification: > - Page 10, Life 8 - Needs to be rewritten as a sentence with a MUST. > Igor - these are all your!!! > Andrea > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]