[cddlm] Changes in xsds and wsdls

[Steve Loughran]

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