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 

--------------------------------------------------------------------------------

Reply via email to