Steve, I think you should check this with the WSDM guys, but this is from WSDM MUWS Part 1.0, Chapter 6. I read it to say that only the Identity capability is required. "Implementers of manageability endpoints are free to expose additional manageability capabilities beyond those defined in MUWS. An additional capability is represented by a set of manageability capability interfaces. The properties defined in a new capability must be defined as XML Schema Global Element Declarations. The operations defined in a new capability are represented as WSDL 1.1 operations. Furthermore, a manageability endpoint offering a new capability is free to ignore all standard manageability capabilities defined by MUWS except for the Identity capability. 811 The MUWS Identity capability is REQUIRED. " Chapter 5 seems to indicate that Identity, ManageabilityCharacteristics, and CorrelatableProperties are required, but again Chapter 6 seems to countermand that. For lifecycle representation, I would prefer you to use the cmp:lifecycle definitions. In regards to the MOWS stuff, you don't have to purge it. You could use it. I made it completely optional in the component model. You may choose to use it, since you are exposing web services such as the Portal EPR. Stuart -----Original Message----- From: Steve Loughran [mailto:steve_loughran@hpl.hp.com] Sent: Wednesday, May 18, 2005 12:47 PM To: 'cddlm-wg@ggf.org' Subject: [cddlm] MUWS and MOWS OK, I think I understand it better; the cmp XSD is helping me to get to grips with this. to be MUWS, we appear to need 0. properties as WSRF properties 1. an identity (URI) 2. some XML document declaring our capabilities (how this gets to the system is out of band) 3. an operational status attribute 4. optional: a state derived from the muws state stuff 5. events for changes in (3) and (4) that are derived from the muws events I am thinking that I must describe the state of the systems using the cmp: lifecycle, and have matching events, but declare that transition operations are queued requests -it isnt an error to send >1 state changing operation to a system EPR, when it is in a valid state for that request -it is an error to send a state changing operation to a system EPR when it isnt in a valid state for it -you can send terminate requests to terminated systems. -The OperationalState of a system is "operational" only when in the running state. I'll then purge all MOWS stuff (GetManageabilityReferences &c). is this right? -steve