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: Re: [sca-assembly] ISSUE 177: SCA Assembly XSD extensibility is brokenif new implementation or binding types are added from other namespaces thanthe SCA one


We have seen this kind of problem before in the TC. The reason for this 
is that we are using *both* substitution groups and xs:any as our 
extensibility mechanism and that always bites you in unexpected ways, if 
you don't watch your minOccurs and choice/all compositors. We should 
look for similar issues in other schema elements.

I think we could solve this for the component case by making 
minOccurs="1" for the component element.

-Anish
--

Scott Vorthmann wrote:
> 
> 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
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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