[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/> schemato 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]