OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opencsa-liaison message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]