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] 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]