[cddlm] RE: Latest version of the component model

[Stuart Schaefer]

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.
> 
> 
>