Re: [Issue 223] Problems with the Extension Points in the SCA XSDs

Folks,

I think that the proposal contained
in the JIRA is a version of Anish's option 1)

- ie. fix up those places where there
is an element extended by substitution group alongside

an <any/> element.  There
are 4 such places in the Assembly spec XSDs, all of which are

dealt with in the proposal.

There are 5 more cases in the bindings
XSDs, but we should leave those to the Bindings TC

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:  

From:
Anish Karmarkar <>

To:


Date:
02/04/2010 23:07

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

I looked at the assembly and policy schema and wrapping
all <any>s (as 

suggested by my initial email) seems unnecessary.

For example, elements like documentation, property, value, requires, 

policySetAttachment, bindingType, implementationType, and wire are 

designed to be containers that can hold anything. These elements do not

contain children elements from the SCA NS. Wrapping the <any> inside
an 

<extensions> for <documentation> would be just wrong. IOW,

<documentation> itself is the wrapper.

I still do like the uniformity. What we have right now is:

<component> does not have the <extensions> wrapper child element
because 

even though it has a subtitution group head (<implementation>) its

cardinality is 1..1 and therefore no UPA problem. <componentType>
OTOH 

also includes <implementation> but its cardinality is 0..1 and therefore

needs the <extensions> wrapper. This means I have to remember that

<component> does not have a wrapper but <componentType> does.

Furthermore, it is likely that I may want to provide the same extension,

say <washesDishes>, in both <componentType> and <component>,
which has 

similar/same semantics. But in one case <washesDishes> will occur
inside 

the wrapper, in other case it would be bare.

I would suggest one of the following:

1) instead of ad hoc reliance on UPA problems, wrap all <any>s in

<extensions> whenever the containing parent element has one or more

substitution group heads. This would happen regardless of whether there

is a UPA problem. This probably affects <componentType> and nothing

else, but I haven't looked in all the schemas. OR

2) If we really wanted the <any>s to be uniform, wrap the substitution

group heads instead. For example, all the <binding> elements on a

service would be inside a <bindings> element. But I'm afraid this
might 

be too much of a big change and am not sure how it would affect the 

structural URI.

As a side, I noticed that wireFormat and operationSelector elements are

abstract empty containers *and* have <any>. I can't see what purpose
it 

serves. We should remove those <any>s. But that is a different issue.

-Anish

--

On 3/24/2010 2:43 AM, Mike Edwards wrote:

>

> Folks,

>

> An argument against removing all the <any/> elements from all
locations

> in all the XSDs is that it is making

> more changes than are necessary.

>

> Strictly, this problem only occurs where <any/> elements can
exist

> alongside elements that are extended using

> the substitution group mechanism. The issue description describes
all

> the elements that are extended using

> this mechanism and this implies a limited set of locations which must
be

> changed.

>

> There are currently 58 places in our complete set of XSDs which use

> <any/> (we do like extensibility....)

>

> In my estimation, the fix I propose would need to be applied in the
4

> places listed in the proposal below, plus

> an additional 5 places which are in the specific binding XSDs, making
a

> total of 9 changes.

>

> Do we really need to change the other 49 places?

>

>

>

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

>

>

> From:                
 Anish Karmarkar <>

> To:                
 

> Date:                
 23/03/2010 15:19

> Subject:              
   [sca-assembly] [Issue 223] Problems with the Extension
Points

> in the SCA XSDs

>

>

> ------------------------------------------------------------------------

>

>

>

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

>  >

>  >

>  > From: Mike Edwards/UK/IBM@IBMGB

>  > To: "OASIS Assembly" <>

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

>  >

>  >

>  > ------------------------------------------------------------------------

>  > /

>  > /

>  >

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

>

>

>

>

>

>

> ------------------------------------------------------------------------

>

> /

> /

>

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

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