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


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

> 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

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