Stuart, Please find the attached file which is my feedback only on Section 3. I will give comments on the rest of the document later... Best Regards, Jun ---------------------- [3.2] Core Concepts and Terminology ---------------------- I would like to have a balanced subsection structure like: 3.2.1 Components (starting from the second paragraph) 3.2.2 Deployable Systems ----------- Please avoid using unrestrictive expressions like "in some way", "there is no restriction ..." before giving restrictive definitions. (in order to serve as a reference for developers, it is desirable for a specification document to describe "what it is" before describing "what it isn't") This part can be like: "A component is a unit of deployment with which status and operational sequences of deployment are defined. A component is an abstract entitiy - although it typically represents a physical software/hardware component, there is no restriction to what a component may represent." -- I would comment this point for the overall document. please try to give crisp definitions first. ---------- "A component has two analogues...." does it mean: A language component <-(implements)- a deployment component <-(instance of)- a CDDLM component object if the above understanding is correct: (a) "it must locate and instantiate deployment components" should be like: "Given a language component, it must locate a deployment component and instantiate a corresponding component object." (b) if they have "interface"-"impelmentation" relationship, there may be better name than "language"/"deployment" components. (c) I don't know why we need to say "CDDLM" component objects. can we just say a deployment component instance? (d) I would like to see the UML diagram in Figure 3 earlier since it also explains the above relationship. ---------- "These deployment components will be moved through their lifecycle, and so bring up the system." (a) we need to explicitly say a component has its lifecycle: "A deployment component (instance?) has its lifecycle defined with deployment states such as initialized and running. The component lifecycle model is defined in Section XX." (b) "the system" is defined in the next subsection. we probably should not mention it here. (c) we may also want to say "a comopnent has properties" and "operations" with references to later sections for details. ---------------------- [3.3] Deploying Components ---------------------- I would define three types of EPRs at one place and then discuss procedures that use them. A deployment graph should be defined and discussed after defining all the EPR's. for example: "The CDDLM framework manages the following EPR's (WS-Addressing Endpoint References) in order to deploy a system: - a portal EPR that adresses a node implementing the Deployment API - a system EPR that adresses a system instantiated through the Deployment API - a component EPR that adresses a deployment component (instance?)" My understanding is that: From the CDDLM user's point of view, a component EPR is merely an identity assigned to a component, and the Deployment API does not define any operation sent to this endpoint from the user. Is this correct? I would like to have an explicit definition of a "deployment graph." Is this what the CDDLM framework manages after parsing of the CDL document? ---------------------- [3.4] Component Lifecycle ---------------------- Currently, we have the lifecycle model defined in two documents I think it should be defined only in the Component Model document and the Deployment API document should refer to the definition in the Component Model document. I don't clearly understand 3.4.1. (a) Does state extention mean definition of internal states? Does it allow any other extension? (b) How can I define extension using WSDM MUWS State capability? (c) For example, I want to have a system run multiple times after a single deployment (I want to go back and forth between initialized and running), how can I extend the lifecycle model?