Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema toallow <implementation/> anywhere

[David Booz <booz@us.ibm.com>]

See below

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 09/24/2008 01:32:46 PM:

> [image removed]
>
> Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/>
> schema to allow <implementation/> anywhere
>
> Anish Karmarkar
>
> to:
>
> Simon Laws
>
> 09/24/2008 01:34 PM
>
> Cc:
>
> sca-assembly
>
> Simon:
>
> I agree, that doesn't work wrt UPA.
> I don't know how we can accommodate the cardinality of these elements
> and still not run into UPA problem.
>
> Few alternatives:
> 1) remove flexibility -- fix the order.
> Dave: folks who use text editors will have to know the order. Is that
> such a bad thing? If they don't want to, can't they just use one of the
> many xml editors that support schema validation? It seems to me that
> getting around UPA problem is a "hard" requirement and flexibility a
> "soft" requirement.
Certainly.

>
> 2) remove flexibility only wrt <implementation>
> This is what we have today. So <service>, <reference>, <property> can be
> in any order but <implementation> must occur at a specific place.
> Dave: you suggest that <implementation> should be last, I'm fine with that.
Ok, as long as that also doesn't run into UPA problems.

>
> 3) complete flexibility in schema, restrictions in spec
> Make the schema cardinality of <implementation> to be unbounded, include
> <implementation> in the <choice> element and in the spec text add a
> restriction that there must not be > 1 <implementation> element.
> I don't like this option. Doesn't make sense to not restrict it in
> schema and not allow schema-enabled editors to enforce it.
I did think about this as an alternative.  We already have validation
cases that cannot be described in schema (e.g. autowire) so it's not
like we'd be adding the first reason for SCA specific validation. I would
be ok with this solution if others felt strongly about it.

>
> Dave: wrt your suggestion of creating a separate element for extension.
> That is indeed a good suggestion. There has been some discussion in
> other fora regarding this. One criticism of this is that it does not
> work well for versioning and evolution of spec/schema, especially when
> the newer version is meant to be backward compatible. For example,
> someone might create an extension <foo:bar> for version 1.1 that becomes
> wildly popular and in SCA 1.2 we decide to include it in the spec. It
> would be nice if the extension element stayed in the same place
> (especially if it is minOccurs="0" and therefore backward compat).
How often is it true that standardization doesn't change the name
of something. :-) I see your point.  We may have even discussed this
before and I just don't remember it.

>
> Can someone educate me wrt what UPA problem exists for the schema that
> we have today (with <implementation> as the 1st element and any order
> for <service>, <reference> and <property>)? Or do we not have a problem
> today?
AFAIK, the UPA problems we have today have nothing to do with impl, serv,
ref, prop.  This issue was opened because the feedback we're getting
about this strict requirement of impl being first; it's
counter-intuitive AND annoying.

>
> BTW, as a side, why is minOccurs for <implementation> 0? Shouldn't it be
> 1? What would it mean for a component with no implementation?
:-) minOccurs is zero because it should be possible to have a valid component
that specifies no implementation.  This is described in the spec text as useful
for top down development.  I would not agree to changing it.

>
> -Anish
> --
>
> Simon Laws wrote:
> >
> > Hi
> >
> > I played with this a bit and also ended up with something similar to
> > Anishe's last suggestion;
> >
> > <sequence>
> >  <choice minOccurs="0" maxOccurs="unbounded">
> >    <element name="service" type="sca:ComponentService"/>
> >    <element name="reference" type="sca:ComponentReference"/>
> >    <element name="property" type="sca:PropertyValue" />
> >  </choice>
> >  <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" />
> >  </choice>
> >  <any namespace="##other" processContents="lax" minOccurs="0"
> >              maxOccurs="unbounded"/>
> > </sequence>
> >
> > Unfortunately it seems that this also suffers from the UPA problem. For
> > a component like
> >
> > <component name="MyComponent">
> >   <service .../>
> > </component>
> >
> > You don't know if the <service/> element belongs to the first choice or
> > the second choice.  I tried a few other configurations but  haven't yet
> > found anything that validates successfully with both the parsers I have
> > to hand.
> >
> > Regards
> >
> > Simon
> >
> > Simon Laws
> > Open Source SOA Development
> > tuscany.apache.org
> > Mail Point 146, Hursley Park, Winchester, Hampshire, SO21 2JN
> > Tel: Internal 248708  External +44 (0)1962 818708
> > Email: simon_laws@uk.ibm.com
> >
> >
> >
> > *David Booz <booz@us.ibm.com>*
> >
> > 24/09/2008 13:05
> >
> >    
> > To
> >    sca-assembly@lists.oasis-open.org
> > cc
> >    
> > Subject
> >    Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema
> > to allow <implementation/> anywhere
> >
> >
> >    
> >
> >
> >
> >
> >
> > WRT inflexibility, we have strong requirements to support creation of
> > composites with a simple text editor. Since a text editor can't provide
> > schema assistance, the human has to remember the order of the elements.
> > That's where the inflexibility comes in. I know that not everyone in the
> > TC shares this requirement.
> >
> > I like the idea at the end of your email.
> >
> > What if we moved the extension point into it's own element, forcing
> > extensions to be child elements of this new element? And what if we
> > forced the extension element to be a singleton and at the end of the
> > list? Does this help?
> >
> > If we end up hard coding the sequence of elements, I'd like to see
> > implementation last in the list; serv, ref, prop and then
> > implementation....but this might cause a UPA problem?
> >
> >
> > Dave Booz
> > STSM, BPM and SCA Architecture
> > Co-Chair OASIS SCA-Policy TC and SCA-J TC
> > "Distributed objects first, then world hunger"
> > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> > e-mail:booz@us.ibm.com
> >
> > Inactive hide details for Anish Karmarkar ---09/23/2008 07:02:04
> > PM---The UPA problem occurs because we have (a) elements and eAnish
> > Karmarkar ---09/23/2008 07:02:04 PM---The UPA problem occurs because we
> > have (a) elements and extensibility points occurring in any order
> >
> > From:    
> > Anish Karmarkar <Anish.Karmarkar@oracle.com>
> >
> > To:    
> > David Booz/Poughkeepsie/IBM@IBMUS
> >
> > Cc:    
> > sca-assembly@lists.oasis-open.org
> >
> > Date:    
> > 09/23/2008 07:02 PM
> >
> > Subject:    
> > Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema
> > to allow <implementation/> anywhere
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > The UPA problem occurs because we have (a) elements and extensibility
> > points occurring in any order (b) with the elements and extension points
> > cardinality > 1 and (c) we use substitution groups (hopefully someone
> > more knowledgeable about UPA will chime in and confirm or refute this).
> >
> > I'm curious wrt what the flexibility buys us.
> > OR what is so inconvenient in saying: implementation comes first,
> > followed by all the services (if any), followed by all the references
> > (if any), followed by all the properties (if any), followed by extension
> > points (if any). The order of service/reference/property isn't important
> > as long as we pick *one* that we like.
> >
> > Instead of:
> > <component ...>
> >  <service ...>
> >  <property ...>
> >  <service ...>
> >  <reference ...>
> >  <implementation ...>
> >  <property ...>
> > </component>
> >
> > I think it is cleaner to have:
> > <component ...>
> >  <implementation ...>
> >  <service ...>
> >  <service ...>
> >  <reference ...>
> >  <property ...>
> >  <property ...>
> > </component>
> >
> > Also, <implementation> has maxOccurs of "1" whereas <service>,
> > <reference> and <property> are unbounded. To allow any order of those
> > elements and still specify that implementation has maxOccurs of '1'
> > would be doable in schema but it would look ugly. Something like:
> >
> > <sequence>
> >  <choice minOccurs="0" maxOccurs="unbounded">
> >    <element name="service" type="sca:ComponentService"/>
> >    <element name="reference" type="sca:ComponentReference"/>
> >    <element name="property" type="sca:PropertyValue" />
> >  </choice>
> >  <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" />
> >  </choice>
> >  <any namespace="##other" processContents="lax" minOccurs="0"
> >              maxOccurs="unbounded"/>
> > </sequence>
> >
> >
> > -Anish
> > --
> >
> > David Booz wrote:
> >  > The hard wired sequence you've shown below is where we started years
> >  > ago. That structure was deemed inflexible, and the choice was added. I
> >  > still agree with the notion that a flexible structure would be
> > beneficial.
> >  >
> >  > Since opening this latest issue, several schema experiments have been
> >  > attempted to arrive at a solution, but none of them has been successful
> >  > (UPA failures). I'm no longer certain if this issue is solvable given
> >  > schema rules AND where we have placed the extensibility points. I was
> >  > hoping you'd have a brainstorm.
> >  >
> >  >
> >  > Dave Booz
> >  > STSM, BPM and SCA Architecture
> >  > Co-Chair OASIS SCA-Policy TC and SCA-J TC
> >  > "Distributed objects first, then world hunger"
> >  > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> >  > e-mail:booz@us.ibm.com
> >  >
> >  > Inactive hide details for Anish Karmarkar ---09/23/2008 01:33:07
> >  > AM---I've always wondered why we have that choice. Apologies, Anish
> >  > Karmarkar ---09/23/2008 01:33:07 AM---I've always wondered why we have
> >  > that choice. Apologies, if this was discussed before and I have fo
> >  >
> >  >
> >  > From:
> >  > Anish Karmarkar <Anish.Karmarkar@oracle.com>
> >  >
> >  > To:
> >  > David Booz/Poughkeepsie/IBM@IBMUS
> >  >
> >  > Cc:
> >  > sca-assembly@lists.oasis-open.org
> >  >
> >  > Date:
> >  > 09/23/2008 01:33 AM
> >  >
> >  > Subject:
> >  > Re: [Issue 82] NEW ISSUE: Relax <component/> schema to allow
> >  > <implementation/> anywhere
> >  >
> >  > ------------------------------------------------------------------------
> >  >
> >  >
> >  >
> >  > I've always wondered why we have that choice. Apologies, if this was
> >  > discussed before and I have forgotten the reason.
> >  > What's wrong with saying:
> >  > <sequence>
> >  >   <implementation />
> >  >   <service minOccurs="0" maxOccurs="unbounded"/>
> >  >   <reference minOccurs="0" maxOccurs="unbounded"/>
> >  >   <property minOccurs="0" maxOccurs="unbounded"/>
> >  >   <any minOccurs="0" maxOccurs="unbounded"/>
> >  > </sequence>
> >  >
> >  > Doesn't that make the UPA problem more manageable?
> >  > OR what is the advantage of allowing service/ref/prop to occur in any
> > order?
> >  >
> >  > -Anish
> >  > --
> >  >
> >  > David Booz wrote:
> >  >  > TARGET: Any version of the Assembly spec
> >  >  >
> >  >  > DESCRIPTION:
> >  >  > The schema for <component/> and others requires <implementation/>
> > to be
> >  >  > the first child. This seems overly restrictive and should be relaxed.
> >  >  >
> >  >  > PROPOSAL:
> >  >  > Move the <implementation/> element inside the <choice/> containing
> >  >  > <service/>, <reference/> and <property/>.
> >  >  >
> >  >  >
> >  >  > Dave Booz
> >  >  > STSM, BPM and SCA Architecture
> >  >  > Co-Chair OASIS SCA-Policy TC
> >  >  > "Distributed objects first, then world hunger"
> >  >  > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> >  >  > e-mail:booz@us.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/
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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
>