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