RE: [wsdm] [MUWS Spec] general comment - need to be decided by 1.0 at th

-----Original Message-----
From: Vambenepe, William N
Sent: Wednesday, March 17, 2004 5:09 PM
To: Sedukhin, Igor S; John DeCarlo; WSDM TC
Subject: RE: [wsdm] [MUWS Spec] general comment - need to be decided by 1.0 at the latest

Every capability is either optional or required so this is clear. On the
other hand, I agree that it would be good to clarify how one should use
(or doesn't have to use) the states we define when describing the state
of their resources. I propose something like:

The states defined by this specification are intended to be generic
states that are relevant for any type of resource. Implementers SHOULD
reuse existing states if they are appropriate for their resources.
Implementers are sole judges in deciding what states are appropriate and
it is expected that new states will be defined (and therefore new URIs
created to represent them), for example if the existing states do not
cover the intended meaning or if the existing states are too general and
the implementer wishes to expose a more specific state description. Just
like they MAY create new states, implementers MAY create new transitions
between any 2 states (the 2 states don't need to have been defined by
the same people). Note that until MUWS defines a way to represent the
state model for a resource, "creating a new transition" just means
writing some text to explain that a resource's state can change from one
state to another. Finally, it is expected that MUWS 1.0 will define a
way for states to be defined as sub-states of another state, at which
point the specification will have specifications and recommendations on
using this mechanism.

> -----Original Message-----
> From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> Sent: Tuesday, March 16, 2004 11:42 AM
> To: John DeCarlo; WSDM TC
> Subject: RE: [wsdm] [MUWS Spec] general comment - need to be
> decided by 1.0 at the latest
>
>
> It seems that it could be sufficient that MUWS spec merely
> says what is mandatory to implement when describing the
> capabilities. For example it may say that Identioy is
> required for any resource (I believe it says so now). It
> would then have a similar statement in Resource State section
> saying that it is mandatory to derive from the top three
> states, and so on.
>
> I'm not sure there needs to be a separate section that calls
> out all the above assetions.
>
> -----Original Message-----
> From: John DeCarlo [mailto:jdecarlo@mitre.org]
> Sent: Tuesday, March 16, 2004 2:35 PM
> To: WSDM TC
> Subject: [wsdm] [MUWS Spec] general comment - need to be
> decided by 1.0 at the latest
>
> Hello,
>
> I earlier made a comment about wording in MOWS, section 2.2,
> about the optional dependency on MUWS. Namely,
>
> "The endpoint manageability capability may depend on a common
> manageability capability. This dependency is optional,
> however. The dependency could be an explicit extension of a
> common capability which makes it more specific. For example,
> a common manageable state capability may represent an ability
> to express UP/DOWN states, and an endpoint manageable state
> capability may add an ability to represent
> IDLE/BUSY/SATURATED, and other endpoint-specific states. This
> could be expressed by an endpoint manageable state UML model
> (class) that extends the common manageable state UML model
> (class). There could be cases where the extension is
> implicit. For example, a UML model of the endpoint manageable
> metrics capability could use some of the data types expressed
> in the common manageable metrics UML model (e.g., Counter
> data type), but the capability model itself does not have to
> mandate the extension of the whole common capability model.
> That is, the endpoint manageable metrics capability can be
> supported on its own without the need to support the common
> capability. There also could be cases when an endpoint
> manageability capability is a new one, available for web
> service endpoints only, and there is no dependency on the
> common capability. This is why the dependency is optional."
>
> However, it seems to me that the MUWS specification needs to
> have some words about how it impacts the various resource
> domains, like MOWS.
>
> "When making an IT Resource manageable using Web services,
> the following items are required to be implemented by the
> manageability provider (bulleted list or references to
> sections) and the following items are strongly urged to be
> implemented, knowing that there are some IT Resource domains
> where it can not be: (bulleted list)."
>
> It could go on to talk about capabilities that are more
> specific, are similar but have different names, etc.
>
> But we need to have agreement on this, at least by 1.0.
>
> For instance, on Resource State. Will it be legal for a
> manageability provider to implement 5 top level states or are
> we requiring every manageability provider to implement 3 top
> level states, only valid transitions, and may extend only by
> implementing sub states of the 3 top level states?
>
> We have talked about this, but at some point the document
> will need to be absolutely clear and match up with MOWS.
>
> Thanks.
>
>
> --
>
> John DeCarlo, The MITRE Corporation, My Views Are My Own
>
>
>
> 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.

wsdm message