Re: [sca-assembly] [NEW ISSUE] SCA Assembly XSD extensibility is broken ifnew implementation or binding types are added from other namespaces thanthe SCA one

[Raymond Feng <rfeng@us.ibm.com>]

Hi,

I don't see an issue opened to track
this issue. 

We had to work around the problem in
the XSDs as follows to get XML schema validation working:

* Change the @minOccurs to be 1 for
implementation element under Component
* Remove implementation element under
ComponentType
* Not set the substitutionGroup for
binding elements that are under non-SCA namespaces

I think we should have a better story
as extensibility of SCA assembly is very important. 

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: rfeng@us.ibm.com,
Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117,
T/L: 367-8117
Apache Tuscany: http://tuscany.apache.org

---

From:	Raymond Feng/Burlingame/IBM@IBMUS
To:	sca-assembly@lists.oasis-open.org
Date:	08/11/2009 08:33 PM
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: rfeng@us.ibm.com,
Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117,
T/L: 367-8117
Apache Tuscany: http://tuscany.apache.org

---

S/MIME Cryptographic Signature