This answers Simon's question on the Tuscany XSDs with substitutionGroup.
From: Raymond Feng Sent: Tuesday, August 11, 2009 8:33 PM To: [email protected] Subject: [sca-assembly] [NEW ISSUE] SCA Assembly XSD extensibility is broken if new implementation or binding types are added from other namespaces than the SCA one Target: http://tools.oasis-open.org/version-control/browse/wsvn/sca-assembly/SCA_XSDS/sca-core-1.1-cd04.xsd Description: The Component is defined in sca-core-1.1-cd04.xsd as follows: <complexType name="Component"> <complexContent> <extension base="sca:CommonExtensionBase"> <sequence> <element ref="sca:implementation" minOccurs="0"/> <choice minOccurs="0" maxOccurs="unbounded"> <element name="service" type="sca:ComponentService"/> <element name="reference" type="sca:ComponentReference"/> <element name="property" type="sca:PropertyValue"/> </choice> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="name" type="NCName" use="required"/> <attribute name="autowire" type="boolean" use="optional"/> <attribute name="constrainingType" type="QName" use="optional"/> <attribute name="requires" type="sca:listOfQNames" use="optional"/> <attribute name="policySets" type="sca:listOfQNames" use="optional"/> </extension> </complexContent> </complexType> Let's assume that we extend base SCA by adding a new implementation type: {http://example.com}implementation.xyz. The XSD (xyz.xsd) for implementation.xyz is illustrated below. <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://example.com" xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903" xmlns:t="http://example.com" ..> <import namespace="http://docs.oasis-open.org/ns/opencsa/sca/200903" schemaLocation="sca-1.1-cd04.xsd"/> <element name="implementation.xyz" type="t:XYZImplementation" substitutionGroup="sca:implementation"/> <complexType name="XYZImplementation"> <complexContent> <extension base="sca:Implementation"> <sequence> ... </sequence> ... </extension> </complexContent> </complexType> </schema> Run XML schema validation in Eclipse reports that {http://docs.oasis-open.org/ns/opencsa/sca/200903}implementation and WC {http://docs.oasis-open.org/ns/opencsa/sca/200903}##other create the ambiguity. This issue can be further explained using the following composite files. Now we define an SCA composite (version 1): <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903" xmlns:t="http://example.com" targetNamespace="http://test" name="MyComposite"> <component name="MyComponent"> <t:implementation.xyz .../> <!-- The schema cannot tell if this is ##other or an substitutionGroup of sca:implementation --> </component> </composite> The composite file exposes the ambiguity as the <t:implementation.xyz> can be interpreted as <sca:implemention> or <any namespace="##other">. If we remove @substitutionGroup from implementation.xyz as a workaround, the following composite (version 2) fails the schema validation. <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903" xmlns:t="http://example.com" targetNamespace="http://test" name="MyComposite"> <component name="MyComponent"> <t:implementation.xyz .../> <!-- The schema expects an substitutionGroup of sca:implementation --> <service name="MyService"> <binding.ws uri="http://localhost:8086/MyService"/> </service> </component> </composite> The similar issue applies to bindings too if a binding is defined in a different namespace other than the SCA one. Proposal: None (It doesn't seem to be a simple way to fix it :-( Thanks, Raymond -------------------------------------------------------------------------------- Raymond Feng Senior Software Engineer, Apache Tuscany PMC Member & Committer IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA 94404, USA E-mail: [email protected], Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117, T/L: 367-8117 Apache Tuscany: http://tuscany.apache.org --------------------------------------------------------------------------------
