You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/08/12 18:01:44 UTC
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
This answers Simon's question on the Tuscany XSDs with substitutionGroup.
From: Raymond Feng
Sent: Tuesday, August 11, 2009 8:33 PM
To: sca-assembly@lists.oasis-open.org
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
--------------------------------------------------------------------------------
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
Posted by Simon Laws <si...@googlemail.com>.
Thanks Raymond, took me a while to spot it ;-)
Simon
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
Posted by Raymond Feng <en...@gmail.com>.
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" <mi...@gmail.com>
Sent: Wednesday, August 12, 2009 2:51 PM
To: <de...@tuscany.apache.org>
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 <ma...@us.ibm.com>
>> *Sent:* Tuesday, August 11, 2009 8:33 PM
>> *To:* sca-assembly@lists.oasis-open.org
>> <ma...@lists.oasis-open.org>
>> *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*//: //_rfeng@us.ibm.com_/ <ma...@us.ibm.com>/, *Notes*//:
>> Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117, *T/L*//: 367-8117*
>> Apache Tuscany*//: //_http://tuscany.apache.org_/
>> <http://tuscany.apache.org/>/ /
>> ------------------------------------------------------------------------
>
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
Posted by Mike Edwards <mi...@gmail.com>.
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 <ma...@us.ibm.com>
> *Sent:* Tuesday, August 11, 2009 8:33 PM
> *To:* sca-assembly@lists.oasis-open.org
> <ma...@lists.oasis-open.org>
> *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*//: //_rfeng@us.ibm.com_/ <ma...@us.ibm.com>/, *Notes*//:
> Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117, *T/L*//: 367-8117*
> Apache Tuscany*//: //_http://tuscany.apache.org_/
> <http://tuscany.apache.org/>/ /
> ------------------------------------------------------------------------