[cddlm] RE: Latest version of the component model
Stuart Schaefer
Sschaefer at softricity.com
Thu May 19 10:41:44 CDT 2005
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 at 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 at 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.
>
>
>
More information about the cddlm-wg
mailing list