[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] MOWS Document Comments
Were down to one, IMHO. > 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" :-). Works for me [CLOSED - Igor to update the document] > > 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. OK so I want to use UML to model the manageability such that anyone can read and understand this without us getting into religious wars about the representation :-). So the wording maybe better if we keep it as it was but use MOF as an example. Andrea lets discuss today at lunch maybe and just close this one out. > > 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]" Again works for me [CLOSED - Igor to update the document] > > 6. Mod 6 - Your wording works for me "The manageability > representation MUST NOT be specific to a particular data or > interface representation." [CLOSED - Igor to update the document] > > 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." Again works for me [CLOSED - Igor to update the document] > > 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. > > > 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]