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: [Omod] minutes of Tue, Nov 11th, 1-2pm EST.


Title: [Omod] next call is on Thu, Nov 6th, 4-5pm EST.


AGENDA
1. Roll.  : Heather, Fred, William, BrianC, BryanM, DanF 

2. Approve minutes at http://lists.oasis-open.org/archives/wsdm/200310/msg00127.html.  

approved 

3. Review open action itmes (5 min)
ACTION: BrianC to align the versioning/revision/change detail UML diagram with the MOWS Concepts diagram and incorporate "versioned X is an X" elements.  closed. 

ACTION: Igor to research how to pretty-up the presented UML diagram to be UML 2.0 compliant with respect to readonly modifier and research how to hide +/- if they are not used in the diagram.  closed. 

ACTION: Igor to start the MOWS document outline and fill in the parts that we have already dicussed and recorded the decisions for (e.g. diagrams, text in e-mails)  closed. 

ACTION: William to provide a model of WSMF managing a web service endpoint expressed in UML similarly to http://lists.oasis-open.org/archives/wsdm/200310/msg00067.html  closed. 

ACTION: Igor to send visio file to William.  closed. 

NEW ACTION: BryanM to send Sessions capability UML model of WSMF.

4. Discuss the initial MOWS document at http://lists.oasis-open.org/archives/wsdm/200310/msg00168.html (30min)

Changes pending:
 a. "This specification defines an endpoint as what is described by a <port> element in a WSDL document."  at lines 173-174 
 b. [..WSDM MOWS specification defines endpoints..] It should say "defines manageability of endpoints".  at line 199 

NEW ACTION: Igor will incorporate pending changes as above.

Igor: went over the document section by section. Outline is according to the slides from F2F with some editorial fixes. Content is from the e-mail discussions.

Section 2 did not raise concerns.

Section 2.1 was ok too. Close ISSUE 6.

Section 2.2 (ISSUE 7). Igor presented as defining separate specific and common capabilities that are equally manageability capabilities which could be composed at the manageable resource in any mix that makes sense for the resource.

Heather is concerned that specific capabilities need to be extensions of common.

Igor: the semantics model of the instance of a capability (concept) may well define explicit extensions of the common semantics (model, interface, etc.). However the concepts themselves are not necessarily/mandatory extensions of one another. Therefore Heather's concern could be represented by an optional dependency of the specific capability from the common capability. There could be specific capabilities that are new and not extensions of any common capability also certain models (e.g. configuration, metrics) may rely on some of the definitions of the common semantics, but may not necessarily be explicit direct extensions of the common model. Such capabilities (e.g. specific configuration) may be supported by the manageable resource without necessarily supporting the corresponding common capability.

Heather, Igor & group discussed merits of explicit extends ("is a") relationship between concepts and dependency.

ACTION: Igor will try to add dependency between the capability concept representations in UML and supply text that explains it.

Section 2.3 was ok.

Section 2.4 was ok.

Fred: port vs endpoint use in the document.

Igor: how about use of endpoint in the document and definition either upfront or in the glossary that an endpoint is as per WSDL 2.0 and it is equal to WSDL 1.1. port. The document would then only refer to "endpoint per WSDL 1.1" if reference of port is absolutely necessary.

all agreed.

ACTION: editors to ensure use of "endpoint" throughout the document and add definition/glossary accordingly.

Section 3 was ok.

Heather: how is the optionality is represented.

Igor: by cardinality/multiplicity of a property

Fred: would it makes sense to make {rw} default and not clutter the diagram

Igor: better to call out all possible metadata explicitly. We may have more e.g. constant, volatile, etc. They all will be expressed as constraints e.g. {ro,const}

Igor: soliciting the list of other possible metadata abbreviations to add to th edocument. Please send suggestions via e-mail.

Igor: can I keep a pen on th edocument and incorporate the on-gong changes that we discuss?

group did not object

5. ISSUES ( 25 min)

ISSUE 4: concepts of versioning applied to MOWS concepts
Brian's input: http://lists.oasis-open.org/archives/wsdm/200311/msg00008.html  

Igor's cleanup & words: http://lists.oasis-open.org/archives/wsdm/200311/msg00009.html  

Brian presented his view on the versioning concepts.

Igor presented the digram that was to render Brian's concepts accordingly to the MOWS/Web services concepts.

Brian is concerned that a notion of a versioned instance of a service is not being communicated by the digram.

Igor: according to the diagram an instance of a versioned serrvice is an instance of a service (with a particular targetNamespace) and also an instance of a versioned component which has a version property. The relationships (e.g. revisions & changes) are, therefore, apply to that instance as well.

[long discussions on trying to sync it up]

Fred: what if the revisions relate to versioned components instead of how it is now? Would that address the concern.

Brian: agreed.

NEW ACTION: Igor to fix the diagram to show revision is about versioned components.

NEW ACTION: Fred to fix up the text which was send with the Igor's diagram.

With the above changes to be incorporated into the MOWS document the versioning issue is closed. Group had no objections.

Administrativa:

REGULAR TUESDAY CALL NEXT WEEK TO BE MOVED TO THU 4-5 EST

ANOTHER CALL THIS WEEK WILL HAPPEN ON THU 4-5 EST to discuss WS-Manageability and WSMF UML models and start combining them and filling out subsections of section 3 of the MOWS spec document.

--- END OF CALL --

Namespaces for versioning concern therad: http://lists.oasis-open.org/archives/wsdm/200311/msg00025.html

Should these concepts be applicable to MUWS as well, i.e. to any resource? Should we move them there?

ISSUE 5: UML approach (see doc).
ACTION: BrianC to attempt to express ManageableEndpointState UML information model linked directly to the web service endpoint state diagrams designed by the W3C Arch MTF. CLOSED, see http://www.oasis-open.org/archives/wsdm/200310/msg00084.html.

Retire this issue until we get to definiton of the State?

ISSUE 6: "locus of implementation" (see doc)
Let's close this one, if no objections.

ISSUE 7: MOWS and MUWS relationship (see doc)
Let's close this one, if no objections.

ISSUE 9: UML models: need to reconcile WS-Manageability and WSMF expressed similarily
Have to start the model and throw in the props/ops/events/metadata per each manageability 'category'. http://lists.oasis-open.org/archives/wsdm/200310/msg00067.html 

Bryan's input: http://lists.oasis-open.org/archives/wsdm/200311/msg00028.html 

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



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