sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema toallow <implementation/> anywhere
- From: David Booz <booz@us.ibm.com>
- To: sca-assembly@lists.oasis-open.org
- Date: Mon, 29 Sep 2008 08:46:46 -0400
constrainingType was designed for a more complex set of use cases. This feature allows for incremental development of components. Top-down was probably not the right characterization, it's more like a meet-in-the-middle scenario.
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 ---09/26/2008 04:32:21 PM--- > > BTW, as a side, why is minOccurs for <implementation> 0? Shouldn't > > it be
From: |
Anish Karmarkar <Anish.Karmarkar@oracle.com> |
To: |
David Booz/Poughkeepsie/IBM@IBMUS |
Cc: |
sca-assembly@lists.oasis-open.org, Simon Laws <simon_laws@uk.ibm.com> |
Date: |
09/26/2008 04:32 PM |
Subject: |
Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema to allow <implementation/> anywhere |
> > 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.
Could you please provide an example of how this would be used? Isn't
this the reason why we have constraining types?
-Anish
--
David Booz wrote:
> 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
> >
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]