RE: [cddlm] updated deployment API
Hi Steve, Please do so, put the documents on the site. I am in Seattle at the moment, but we'll continue to have our regular weekly meeting tomorrow, 6am, usual phone number. The agenda is update on two remaining specs, agenda at GGF, and daily business. Thanks, Dejan.
-----Original Message----- From: owner-cddlm-wg@ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Steve Loughran Sent: Tuesday, June 14, 2005 7:29 AM To: cddlm-wg@ggf.org Subject: [cddlm] updated deployment API
Hello, this is the final pre-GGF14 update. 1. the .doc file shows the most recent changes 2. the .pdf is the one for broad circulation.
Dejan, shall I put this + the WSDL/XSD up on the documents list on the site?
Hello, as I have already mentioned I had some problems with the xsds and wsdls from the specifications. Some of them, I've sent to Steve and he has corrected on the repository versions. Thanks Steve. I've also made some other changes to these versions in order to make them work with Muse until some point and to make the component-model.xsd schema not ambiguous. I would like to share these changes with you, so you can comment on them if you disagree on anything: * deployment-api.wsld: - The wsrf-rp:resourceProperties should be "wsrf-rp:ResourceProperties" in the "PortalEPR" and in the "SystemEPR" port types. - The "wsdl:part" of the "DeploymentFault" message should have its element attribute pointing to "cmp:ComponentFault" instead of to "cmp:ComponentFaultType", which does not exist in the component model. * deployment-api.xsd: - As muse had presented some problems of do not correctly identifying the namespaces of some of the elements from the "portalEndpointProperties" and of the "SystemEndpointProperties" that did not have any explicit namespace, I've used the "tns" namespace in these elements and I have declared this namespace in the beginning of the file with the same value of the targetNamespace attribute. * component-model.xsd - In order to remove the ambiguity, I've commented the "xsd:sequence" part of the "PropertyChangeEvent" and of the "ComponentLifecycleEvent" types while this problem is not solved in another way. Best regards, Ayla
Ayla Debora Dantas de Souza - Projeto Ourgrid wrote:
Hello,
as I have already mentioned I had some problems with the xsds and wsdls from the specifications. Some of them, I've sent to Steve and he has corrected on the repository versions. Thanks Steve. I've also made some other changes to these versions in order to make them work with Muse until some point and to make the component-model.xsd schema not ambiguous. I would like to share these changes with you, so you can comment on them if you disagree on anything:
* deployment-api.wsld: - The wsrf-rp:resourceProperties should be "wsrf-rp:ResourceProperties" in the "PortalEPR" and in the "SystemEPR" port types. - The "wsdl:part" of the "DeploymentFault" message should have its element attribute pointing to "cmp:ComponentFault" instead of to "cmp:ComponentFaultType", which does not exist in the component model.
fixed
* deployment-api.xsd: - As muse had presented some problems of do not correctly identifying the namespaces of some of the elements from the "portalEndpointProperties" and of the "SystemEndpointProperties" that did not have any explicit namespace, I've used the "tns" namespace in these elements and I have declared this namespace in the beginning of the file with the same value of the targetNamespace attribute.
What I have done here is -declared and used the api: prefix -added it explicitly in all type definitions (so that I am consistent throughout the doc) -added a comment above each property declaration requiring explicit namespace prefixes.
* component-model.xsd - In order to remove the ambiguity, I've commented the "xsd:sequence" part of the "PropertyChangeEvent" and of the "ComponentLifecycleEvent" types while this problem is not solved in another way.
Stuart is updating the component model to reflect changes here. Essentially muws events cannot be extended, instead we have to define custom XML content to place into the message, and provide information about that message outside the XSD/WSDL itself. There is something deeply amusing about that design, which is, of course, the original design of SOAPFaults. Somehow it was deemed inappopriate for faults but the right way for events. -steve
participants (3)
-
Ayla Debora Dantas de Souza - Projeto Ourgrid -
Milojicic, Dejan S -
Steve Loughran