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