OpenCSA Liaison Subcommittee

 View Only

Fw: [sca-assembly] [Issue 223] Problems with the Extension Points in theSCA XSDs

  • 1.  Fw: [sca-assembly] [Issue 223] Problems with the Extension Points in theSCA XSDs

    Posted 03-24-2010 09:21

    Folks,

    Could this issue please be added to the agenda for the next Liaison committee meeting, please?


    Yours,  Mike.

    Strategist - Emerging Technologies, SCA & SDO.
    Co Chair OASIS SCA Assembly TC.
    IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
    Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
    Email:  mike_edwards@uk.ibm.com

    ----- Forwarded by Mike Edwards/UK/IBM on 24/03/2010 09:04 -----
    From: Danny van der Rijn <dannyv@tibco.com>
    To: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
    Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, sca-assembly@lists.oasis-open.org
    Date: 23/03/2010 20:39
    Subject: Re: [sca-assembly] [Issue 223]  Problems with the Extension Points in the SCA XSDs





    Thanks, Jeff.  Of course the liason committee is what I meant.  
    Regardless of what my fingers did.  :-)

    On 3/23/2010 1:12 PM, Jeff Mischkinsky wrote:
    > hi danny,
    >   I'd recommend putting this on the liaison SC agenda, rather than the
    > Steering committee. I don't think it takes a TC motion to do that.
    > Just a request for it to be discussed.
    >
    >     cheers,
    >    jeff
    >
    > On Mar 23, 2010, at 11:36 AM, Danny van der Rijn wrote:
    >
    >> +1 to Anish's proposed expansion of the solution.
    >>
    >> Either way we resolve, once we do, we should forward the resolution
    >> to the Steering Committee as a proposed recommendation to all TCs.  
    >> Would this require, procedurally, a New Issue?  If so, I'll happily
    >> file it.
    >>
    >> Danny
    >>
    >> On 3/23/2010 8:14 AM, Anish Karmarkar wrote:
    >>> I like this solution.
    >>> One comment I have is:
    >>> wouldn't it be better if we used <sca:extensions> element for all
    >>> <any>s, regardless of whether we encounter UPA or not? I like the
    >>> uniformity of that. Otherwise, one has to remember whether there is
    >>> a maxOccurs="1" on the substitution group or that there is no
    >>> substitution group, and therefore no wrapper for <any>.
    >>>
    >>> -Anish
    >>> --
    >>>
    >>> On 3/22/2010 7:31 AM, Mike Edwards wrote:
    >>>>
    >>>> Logged as: _http://www.osoa.org/jira/browse/ASSEMBLY-223_
    >>>>
    >>>> Yours, Mike.
    >>>>
    >>>> Strategist - Emerging Technologies, SCA & SDO.
    >>>> Co Chair OASIS SCA Assembly TC.
    >>>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
    >>>> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
    >>>> Email: mike_edwards@uk.ibm.com
    >>>>
    >>>>
    >>>> From:     Mike Edwards/UK/IBM@IBMGB
    >>>> To:     "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
    >>>> Date:     22/03/2010 14:20
    >>>> Subject:     [sca-assembly] [NEW ISSUE] Problems with the Extension
    >>>> Points
    >>>> in the SCA XSDs
    >>>>
    >>>>
    >>>> ------------------------------------------------------------------------
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> Raiser: Mike Edwards
    >>>>
    >>>> Target: sca-assembly-1.1-spec-cd05.doc
    >>>>
    >>>> Description:
    >>>>
    >>>> The SCA XSDs mix two different forms of extensibility and this causes
    >>>> significant problems such as UPA errors.
    >>>>
    >>>> The two forms of extensibility are:
    >>>>
    >>>> 1) The use of substitution groups for the extensibility of:
    >>>>
    >>>> implementation
    >>>> interface
    >>>> binding
    >>>> wireFormat
    >>>> operationSelector
    >>>> importBase
    >>>> exportBase
    >>>>
    >>>> 2) The use of
    >>>>
    >>>> <any namespace="##other" processContents="lax" minOccurs="0"
    >>>> maxOccurs="unbounded"/>
    >>>>
    >>>> for extensibility in many locations
    >>>>
    >>>>
    >>>> A UPA problem potentially exists in any place where ONE or MORE of the
    >>>> elements in the list 1) above is declared
    >>>> to be used within another element in combination with 2) in a sequence
    >>>> or choice where it may occur that one of the
    >>>> list 1) elements is validly succeeded by an <any/> of the form in
    >>>> 2). IF
    >>>> an extended version of any of the 1) elements
    >>>> is created, in a non-sca namespace (this is REQUIRED for any
    >>>> non-standard extension), then a UPA error will be
    >>>> reported whenever such an extension is used.
    >>>>
    >>>> The following locations in the current XSDs are at fault:
    >>>>
    >>>> - ComponentType type
    >>>> - Component type ("lash up" fix applied here)
    >>>> - Callback type
    >>>> - ContributionType type
    >>>>
    >>>>
    >>>> Proposal:
    >>>>
    >>>> For the locations affected, provide flexible extensibility using the
    >>>> following element instead of <any/>:
    >>>>
    >>>> <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
    >>>>
    >>>> ...as has already been done for some elements/types including the
    >>>> "Contract" type:
    >>>>
    >>>> 1) ComponentType
    >>>>
    >>>> <complexType name="ComponentType">
    >>>> <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:ComponentTypeReference"/>
    >>>> <element name="property" type="sca:Property"/>
    >>>> </choice>
    >>>> <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
    >>>> </sequence>
    >>>> </extension>
    >>>> </complexContent>
    >>>> </complexType>
    >>>>
    >>>> 2) Callback type
    >>>>
    >>>> <complexType name="Callback">
    >>>> <complexContent>
    >>>> <extension base="sca:CommonExtensionBase">
    >>>> <choice minOccurs="0" maxOccurs="unbounded">
    >>>> <element ref="sca:binding"/>
    >>>> <element ref="sca:requires"/>
    >>>> <element ref="sca:policySetAttachment"/>
    >>>> <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
    >>>> </choice>
    >>>> <attribute name="requires" type="sca:listOfQNames" use="optional"/>
    >>>> <attribute name="policySets" type="sca:listOfQNames" use="optional"/>
    >>>> </extension>
    >>>> </complexContent>
    >>>> </complexType>
    >>>>
    >>>>
    >>>> 3) ContributionType type
    >>>>
    >>>> <complexType name="ContributionType">
    >>>> <complexContent>
    >>>> <extension base="sca:CommonExtensionBase">
    >>>> <sequence>
    >>>> <element name="deployable" type="sca:DeployableType" minOccurs="0"
    >>>> maxOccurs="unbounded"/>
    >>>> <element ref="sca:importBase" minOccurs="0" maxOccurs="unbounded"/>
    >>>> <element ref="sca:exportBase" minOccurs="0" maxOccurs="unbounded"/>
    >>>> <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
    >>>> </sequence>
    >>>> </extension>
    >>>> </complexContent>
    >>>> </complexType>
    >>>>
    >>>>
    >>>> 4) Component type (strictly this is already "fixed" but is not
    >>>> consistent with the above...)
    >>>>
    >>>> <complexType name="Component">
    >>>> <complexContent>
    >>>> <extension base="sca:CommonExtensionBase">
    >>>> <sequence>
    >>>> <element ref="sca:implementation" minOccurs="0" maxOccurs="1"/>
    >>>> <choice minOccurs="0" maxOccurs="unbounded">
    >>>> <element name="service" type="sca:ComponentService"/>
    >>>> <element name="reference" type="sca:ComponentReference"/>
    >>>> <element name="property" type="sca:PropertyValue"/>
    >>>> <element ref="sca:requires"/>
    >>>> <element ref="sca:policySetAttachment"/>
    >>>> </choice>
    >>>> <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
    >>>> </sequence>
    >>>> <attribute name="name" type="NCName" use="required"/>
    >>>> <attribute name="autowire" type="boolean" use="optional"/>
    >>>> <attribute name="requires" type="sca:listOfQNames" use="optional"/>
    >>>> <attribute name="policySets" type="sca:listOfQNames" use="optional"/>
    >>>> </extension>
    >>>> </complexContent>
    >>>> </complexType>
    >>>>
    >>>>
    >>>> This leaves all the other locations where <any/> is used, but in those
    >>>> cases there is no use of substitution groups
    >>>> in any of the peer elements of the <any/>.
    >>>>
    >>>>
    >>>> Yours, Mike.
    >>>>
    >>>> Strategist - Emerging Technologies, SCA & SDO.
    >>>> Co Chair OASIS SCA Assembly TC.
    >>>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
    >>>> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
    >>>> Email: mike_edwards@uk.ibm.com
    >>>>
    >>>>
    >>>> ------------------------------------------------------------------------
    >>>>
    >>>> /
    >>>> /
    >>>>
    >>>> /Unless stated otherwise above:
    >>>> IBM United Kingdom Limited - Registered in England and Wales with
    >>>> number
    >>>> 741598.
    >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
    >>>> PO6 3AU/
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> ------------------------------------------------------------------------
    >>>>
    >>>>
    >>>> /
    >>>> /
    >>>>
    >>>> /Unless stated otherwise above:
    >>>> IBM United Kingdom Limited - Registered in England and Wales with
    >>>> number
    >>>> 741598.
    >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
    >>>> PO6 3AU/
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>> ---------------------------------------------------------------------
    >>> 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
    >>
    >
    > --
    > Jeff Mischkinsky                              jeff.mischkinsky@oracle.com
    > Sr. Director, Oracle Fusion Middleware                 +1(650)506-1975
    >     and Web Services Standards                       500 Oracle
    > Parkway, M/S 2OP9
    > Oracle                                Redwood Shores, CA 94065
    >
    >
    >
    >
    >
    >
    >
    >
    >








    Unless stated otherwise above:
    IBM United Kingdom Limited - Registered in England and Wales with number 741598.
    Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU