OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [NEW ISSUE] SCA Assembly XSD extensibility is broken if new implementationor 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]