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: ISSUE 177: SCA Assembly XSD extensibility is broken if new implementation or binding types are added from other namespaces than the SCA one



http://www.osoa.org/jira/browse/ASSEMBLY-177


On Aug 18, 2009, at 9:25 PM, Raymond Feng wrote:

> 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
>



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