Another issue: setting the @minOccurs to "1" for sca:implementation element ref in sca:ComponentType is probably too much. It makes most of the component type files we have in Tuscany no more conforming. I'm not sure why the implemention element is there in the componentType in the first place.

  <element name="componentType" type="sca:ComponentType"/>
  <complexType name="ComponentType">
     <complexContent>
        <extension base="sca:CommonExtensionBase">
           <sequence>
              <element ref="sca:implementation" minOccurs="1"/>
...

Thanks,
Raymond
--------------------------------------------------
From: "Raymond Feng" <[email protected]>
Sent: Wednesday, August 12, 2009 3:42 PM
To: <[email protected]>
Subject: Re: Fw: [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

Hi,

Thanks for the proposal. I verified it with the Eclipse XML schema validation. This change can at least get implementation.xyz going. At this point, we can live with binding.xyz without specifying the substitutionGroup="sca:binding" if we list Tuscany bindings after those bindings under SCA namespace.

I agree we need to find out a better solution. Should we carry on the discussions on the OASIS ML?

Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Wednesday, August 12, 2009 2:51 PM
To: <[email protected]>
Subject: Re: Fw: [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

Raymond,

As it happens, there is a simple fix for the case you illustrate below -

change the minOccurs="0" on <element ref="sca:implementation"/> to minOccurs="1"

... then it is happy to always accept one of any extension of <implementation/> from any namespace, followed by whatever other extension elements you like.

However, this does not deal with <binding.xxx/> elements - and the problem there is that minOccurs="0" is necessary, so that the simple fix above does not work.

So, we shall probably have to think harder about how to provide for extensibility :-(

One thought is to have an <extensibility /> element which can be of any type and then use xsi:type in instance documents to fix the actual type. However, this is ugly...


Any ideas welcome,


Yours,  Mike.

Raymond Feng wrote:
This answers Simon's question on the Tuscany XSDs with substitutionGroup.

*From:* Raymond Feng <mailto:[email protected]>
*Sent:* Tuesday, August 11, 2009 8:33 PM
*To:* [email protected] <mailto:[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 <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 <http://example.com/>"
    xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903";
    xmlns:t="http://example.com <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 <http://example.com/>"
    targetNamespace="http://test <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 <http://example.com/>"
    targetNamespace="http://test <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]_/ <mailto:[email protected]>/, *Notes*//: Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117, *T/L*//: 367-8117* Apache Tuscany*//: //_http://tuscany.apache.org_/ <http://tuscany.apache.org/>/ /
------------------------------------------------------------------------

Reply via email to