Bryan, Thank you for your assistance. I fixed most of what you have commented on. I am still not comfortable with the different namespace revisions between published specs that we are relying on, but I have fixed the document to reflect the actual XSD. Really only one question below on the WSDM StateCapability. Regards, Stuart
-----Original Message----- From: Murray, Bryan P. Sent: Friday, May 13, 2005 6:06 PM To: Milojicic, Dejan S Subject: RE: Latest version of the component model
Dejan,
I am including my notes from reviewing the spec. I did not look at the wsdl/schema in detail, but did look briefly at it.
Bryan
Section 1.1: I would use standards group namespaces rather than proprietary namespaces whenever possible. I recommend the following namespaces:
wsa: Use either the W3C submission namespace or the Last Call namespace
wsrf-*: Use the namespaces from the TC web site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf
WS-Notification specs should also use the namespaces from the TC web site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
Also, don't use the prefix "wsrf-nt" for WS-BaseNotification - it is not accurate. Instead use "wsn-baseN" or something similar.
section 2: 2 related specs are mentioned, but there is no reference to the specs (even in the references section). You need to provide a link to the specs.
section 2.1.3, 2nd to last sentence: This sentence makes it sound like the "Component Model Specification" is some other document rather than this document. Change "that" to "this".
This was part of stock material created for all documents. Changed.
section 3.4: The last para discusses linking lifecycles of related components but does not say how this is done. More speciifc rules should be stated for when a system component can transition between states based on the states of some of its dependent components transition.
The actual discussion is in Section 5. I put in a reference. Section 3 is designed as a non-normative overview of the component model. Not a place for rules.
Section 4.1: The example in 4.1 is not compliant with the schema fragment in 4.1.3 because it is not possible to have a string as a child node of the CommandPath element unless mixed="true" is added to the commandPathType complexType. The end element is 'simpleType' whereas the start element is 'complexType'.
This is fixed.
In CDL documents, sometimes the cdl prefix is used and sometimes it is not - better to be consistent.
I changed all documents to be full CDL fragments with the cdl:system elements.
section 4.4.1.3 (and others): The type 'lifecycleStateType' is used, but this type is not declared in the XML schema. Should this be muws-p2-xsd:StateType? Also, near the end of the section there is a schema fragment for ApplyingPolicy. I think this should be defined as follows: <xs:element name="ApplyingPolicy" type="muws-p2-xsd:StateType"/> I think with this definition it is still possible to have the instance definition listed, but the xsi:type attribute is not necessary.
The schema was updated, but not copied into the document. It has been fixed. The cmp:lifecycleStateType is an extension of the muws-p2-xs:StateType. Not sure about the xsi:type.
section 4.4.2.2: If a set of operations go together it is not necessary to use a separate interface for each operation.
The actions don't all go together, as some are declared in WS-RF and some are component model specific.
section 4.4.2.3: I would recommend that additional operations be decalred directly in WSDL rather than having a "do it" operation to provide additional capabilities. This allows a client to discover what the service is capable of through examining the WSDL rather than not having any means of discovering what the service is capable of if all other operations go through RunTask.
The RunTask action is not meant to replace an implementers ability to define operations in WSDL. It is meant as a well-known endpoint for simple, internal tasks to be accomplished.
section 4.5.4: DeploymentFault is not declared in the schema.
As above, copied the schema.
Section 4.6.1.1: ComponentLifecycleEvents sound a lot like StateCapability Events defined by MUWS part 2. See section 3.2.6.
They are exactly StateCapability Events. Just using the cmp:LifecycleTransition derivative of muws-p2-xs:StateTransition. Does that mean I have to declare it as a StateCapability event?? Won't a WSDM consumer recognize it, as its types correlate correctly?
Section 4.6.1.2: WS-BaseNotification defines an implicit topic for every mutable property. The notification define in baseN contains the old and new values and is placed in a MUWS ManagementEvent in the extension location.
The current draft does. Not the version I have been using. Why would WS-BaseNotification require the use of WSDM MUWS?
section 4.6.2.1: Dangling "The". It is not clear where the On* elements go - is it in a CDL doc? It looks like most of the On* events are shortcuts for subscription to the generic state transition event with a filter for a specific state.
Yes.
section 8.1.6: ImplementsMessageSet is not defined in the schema and no reference is provided to where it might be defined.
Removed. Should have been purged earlier.
-----Original Message----- From: Milojicic, Dejan S Sent: Wednesday, May 11, 2005 6:04 AM To: Murray, Bryan P. Subject: FW: Latest version of the component model
Hi Bryan,
Sorry to bug you. I was curious if there is any chance to review the documents or you plan to do so?
Thanks,
Dejan.
-----Original Message----- From: Milojicic, Dejan S Sent: Tuesday, April 26, 2005 7:00 AM To: Murray, Bryan P. Subject: FW: Latest version of the component model
Hi Bryan,
Is there any chance that you can one last time review this spec?
Thanks,
Dejan.
PS You mention that you will forward to me the interop spec (materials), can you please do so? -----Original Message----- From: Stuart Schaefer [mailto:Sschaefer@softricity.com] Sent: Friday, April 22, 2005 4:11 AM To: Milojicic, Dejan S Cc: Iyer, Subu; Rafaeli, Sandro; Talwar, Vanish Subject: RE: Latest version of the component model
Dejan and Team,
Attached is the latest draft of the component model document. I am also attaching the schema and WSDL files. The complete set will be uploaded into our SourceForge project later today.
Regards,
Stuart
-----Original Message----- From: Milojicic, Dejan S [mailto:dejan.milojicic@hp.com] Sent: Monday, April 11, 2005 2:21 PM To: Stuart Schaefer Cc: Iyer, Subu; Rafaeli, Sandro; Talwar, Vanish Subject: Latest version of the component model
Hi Stuart,
My team members are after me. I told them that the newest version of the component model will be out this Sunday and now they are asking me where is it :-)?
Is there any update on this front. I am also using this opportunity to introduce to you Subu Iyer, Sandro Rafaeli and Vanish Talwar, who work with me on the Scalable Management project and who have interest in using the CDDLM work.
Thanks,
Dejan.