Re: [sca-assembly] ISSUE 177: SCA Assembly XSD extensibility is broken ifnew implementation or binding types are added from other namespaces thanthe SCA one

[Raymond Feng <rfeng@us.ibm.com>]

Would it make sense to define an SCA element
such as <extensions> as the place to add xsd:any? This way, we can
remove the competition between substitutionGroup and xsd:any. It's not
super nice but that's the only I can find out to fix the issue.

The extensions element can look like:

<element name="extensions"
type="sca:ExtensionsType"/>
<complexType name="ExtensionsType>
      <sequence>
         <any
namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
      </sequence>
      <anyAttribute
namespace="##any" processContents="lax"/>
</complexType>

For those SCA elements that require
extensibility, we can just add <extensions> as an optional child.

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
Co-author of Tuscany In Action: http://www.manning.com/laws

---

Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 09/02/2009 06:51:59 PM:

> From:
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 
> To:
> 
> Scott Vorthmann <scottv@tibco.com>
> 
> Cc:
> 
> Raymond Feng/Burlingame/IBM@IBMUS, sca-assembly@lists.oasis-open.org
> 
> Date:
> 
> 09/02/2009 06:52 PM
> 
> Subject:
> 
> Re: [sca-assembly] ISSUE 177: SCA Assembly XSD extensibility is 
> broken if new implementation or binding types are added from other
> namespaces than the 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
> 
> ---------------------------------------------------------------------
> 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
>

S/MIME Cryptographic Signature