Re: [sca-assembly] Overridable and multiplicity, was Re: [sca-assembly]NEW ISSUE: Incorrect usage of MAY Keyword

[Simon Nash <oasis@cjnash.com>]

Mike Edwards wrote:
> 
> Folks,
> 
> A problem with defaulting the @multiplicity attribute value of a 
> <composite/> <reference/> to use the
> multiplicity attribute of a promoted <component/> <reference/> is where 
> there are multiple promoted
> references and the promoted references have different @multiplicity 
> values - which one do you use?
> 
> Imagine a case where the composite reference promotes 4 references with 
> the multiplicities set to:
> 
> 0..1
> 1..1
> 0..n
> 1..n
> 
> What value does the @multiplicity of the composite reference get?
> 
> I think it's 1..1
> 
> I think that the general rule is:
> 
> The lower bound is 0 if the lower bound of all the promoted references 
> is 0, otherwise it is 1
> 
> The upper bound is n if the upper bound of all the promoted references 
> is n, otherwise it is 1.
> 
I agree with all of the above.  Based on the principle that promotion
of a reference can restrict multiplicity but not extend it, it makes
sense for the default multiplicity of the composite reference to be
the least restrictive setting that satisfies this constraint.

> The worse thing is that the multiplicity changes depending on the set of 
> promoted references
> which may lead to problems with the higher level composition.
> 
Any such change involves making a change to the definition of the
composite reference and it could be argued that this isn't very
different from changing the @multiplicity setting on the composite
reference.  However I accept that changing the default multiplicity
if a promoted reference is added or removed could give rise to
subtle unintended errors.

> Which may argue for requiring the multiplicity to be specified at all 
> times, with no default.
> 
Most of the time, only a single component reference will be promoted.
For this common case, it is simple and natural to say that the
composite reference multiplicity defaults to the component reference
multiplicity.

I think it would make sense to also do this when promoting multiple
component references that all have the same multiplicity.

The above two cases should acount for well over 95% of all reference
promotions.  For the other cases where multiple component references
with different multiplicities are being promoted, there is a good case
for not having a default but requiring the composite reference to
specify @multiplicity explicitly.  I think this would be better than
choosing an arbitrary default of 1..1.

> At least having a fixed default avoids this problem and a tool can 
> always verify that the
> multiplicities are correctly matched within the composite....
> 
A tool could also look at what references are being promoted and
apply the above algorithm to compute the default.  I'm more concerned
about whether this algorithm is consumable/understandable by humans
than whether it's implementable by tools.

In summary, for the simple case of promoting a single reference or
multiple references with the same multiplicity, I think the
composite reference multiplicity should default to the component
reference multiplicity.  For the complex case of promoting
multiple component references with different multiplicities,
I think the simplest approach is to require @multiplicity to be
present on the composite reference.

   Simon
> 
> 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: 	Simon Nash <oasis@cjnash.com>
> To: 	sca-assembly@lists.oasis-open.org
> Date: 	23/04/2009 11:44
> Subject: 	Re: [sca-assembly] Overridable and multiplicity, was Re: 
> [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Dave,
> Thanks for the review.  One response inline below.
> 
>   Simon
> 
> David Booz wrote:
>  > my multiplicity induced migraine is back ... inlined below and shortened
>  > to just this topic.
>  >
>  > 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
>  >
>  > Simon Nash <oasis@cjnash.com> wrote on 04/21/2009 05:23:10 PM:
>  >
>  >  > [image removed]
>  >  >
>  >  > Re: [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword
>  >  >
>  >  > Simon Nash
>  >  >
>  >  > to:
>  >  >
>  >  > OASIS SCA Assembly List
>  >  >
>  >  > 04/21/2009 05:23 PM
>  >  >
>  >  > On today's Assembly call I volunteered to produce a reworded paragraph
>  >  > for the first of Eric's items.  See inline below.
>  >  >
>  >  >    Simon
>  >  >
>  >  > Eric Wells wrote:
>  >  > > All,
>  >  > >     I think that in several places in the specification the usage
>  > of the
>  >  > > keyword MAY is not consistent with the definition in RFC2119. To 
> quote
>  >  > > http://www.ietf.org/rfc/rfc2119.txt:
>  >  > >
>  >  > >    5. MAY This word, or the adjective "OPTIONAL", means that an 
> item is
>  >  > >       truly optional.  One vendor may choose to include the item
>  > because a
>  >  > >       particular marketplace requires it or because the vendor
>  > feels that
>  >  > >       it enhances the product while another vendor may omit the
>  > same item.
>  >  > >
>  >  > > In several places MAY is used to indicate the semantics of an
>  > artifact and
>  >  > > NOT that a behavior is optional. I believe other usage of MAY (and
>  > SHOULD)
>  >  > > are consistent with the RFC2119 definition.
>  >  > >
>  >  > > Note I DO NOT want to delay the CD03 vote, so it may be more
>  > appropriate to
>  >  > > handle these issues on the public comment list. However I will 
> defer to
>  >  > > others as to how best to handle these items.
>  >  > >
>  >  > > Best Regards,
>  >  > >               Eric.
>  >  > >
>  >  > > Eric Wells.
>  >  > > Consulting Engineer.
>  >  > > Hitachi Computer Products (America) Inc.
>  >  > > San Francisco, CA. USA.
>  >  > > +1 (415) 656-4346
>  >  > > eric.wells@hitachisoftware.com
>  >  > >
>  >  > >
>  >  > > Based on the CD03 Word document at:
>  >  > >
>  >  > >    
>  >  > >
>  > 
> http://www.oasis-open.org/committees/download.php/31566/sca-assembly-1.1-spe
>  >  > > c-cd03.doc
>  >  > >
>  >  > > I think that the following normative statements need corrections:
>  >  > >
>  >  > > Unmarked normative statement Lines 836 - 840
>  >  > > ============================================
>  >  > > "If the component reference has @nonOverridable==false and
>  > @multiplicity
>  >  > > 1..1 and the reference has a target, then any composite 
> reference which
>  >  > > promotes the component reference has @multiplicity 0..1.by default
>  > and MAY
>  >  > > have an explicit @multiplicity of either 0..1 or 1..1."
>  >  > >
>  >  > > Although this is not marked as a normative statement, I think the
>  > use of the
>  >  > > MAY keyword is probably correct and either value for 
> @multiplicity is
>  >  > > arbitrarily allowed.
>  >  > >
>  >  > > PROPOSAL:
>  >  > > Add a normative reference for the statement. N.B. If a vendor
>  > should NOT be
>  >  > > allowed to arbitrarily choose the value for @multiplicity the 
> statement
>  >  > > should be reworded. (Note there is an extra period in "0..1.by"
>  > that should
>  >  > > be corrected editorially regardless  of this issue).
>  >  > >
>  >  > Here is my proposed rewording of this paragraph.  I have added inline
>  >  > notes as <scn>...</scn> to explain the changes, with a few additional
>  >  > comments.
>  >  >
>  >  >   nonOverridable : boolean (0..1) - a boolean value, "false" by 
> default,
>  >  >   which indicates whether this component reference can have its 
> targets
>  >  >   overridden by a composite reference which promotes the component
>  > reference.
>  >  >   If @nonOverridable==false, the target(s) of the promoting composite
>  >  >   reference replace all the targets explicitly declared on the 
> component
>  >  >   reference for any value of @multiplicity on the component reference.
>  >  >   If the component reference has @nonOverridable==false and
>  > @multiplicity 1..1
>  >  >   and the reference has a target, then any composite reference which
>  > promotes
>  >  >   the component reference has @multiplicity 0..1 by default and 
> can have
>  >  >   an explicit @multiplicity of either 0..1 or 1..1.
>  >  >    <scn> Changed "MAY" to "can" because the normative text 
> covering this
>  >  >    will be added to ASM60011 (see below).
>  >  >    </scn>
>  >
>  > +1
>  >
>  >  >    <scn>I find it surprising that there is no similar special case for
>  >  >    a component reference with multiplicity 1..n and one or more 
> targets.
>  >  >    Is this deliberate?
>  >  >    <scn>
>  > Not deliberate that I recall. A 0..n or 1..n reference that is 
> overridable
>  > would seem to need the same 0..n default on the composite reference 
> with a
>  > full target replacement semantic (as opposed to additive as in the 
> case for
>  > non-overridable references).
>  >
>  >  >   If @nonOverridable==true, and the component reference has 
> @multiplicity
>  >  >   0..1 or 1..1 and the reference has a target, promotion implies 
> that the
>  >  >    <scn>Changed "also declares a target" to "has a target" for
>  > consistency
>  >  >    with the previous wording four lines earlier.  The difference 
> could be
>  >  >    significant if the target is provided by autowiring.
>  >  >    </scn>
>  >  >   promoting composite reference has @wiredbyImpl==true and the 
> composite
>  >  >   reference cannot supply a target, but can influence the policy 
> attached
>  >  >   to the component reference.
>  >  >   If @nonOverridable==true, and the component reference 
> @multiplicity is
>  >  >   0..n or 1..n, promotion targeting is additive.
>  >  >
>  >  > In addition to this change, a change needs to be made to the 
> description
>  >  > of @multiplicity for composite references because the current wording
>  > does
>  >  > not cover this case.  Here's my proposed update:
>  >  >
>  >  >   multiplicity : (0..1) - Defines the number of wires that can
>  > connect the
>  >  >   reference to target services.  When present, the multiplicity can
>  > have one
>  >  >   of the following values:
>  >  >    o 0..1 – zero or one wire can have the reference as a source
>  >  >    o 1..1 – one wire can have the reference as a source
>  >  >    o 0..n - zero or more wires can have the reference as a source
>  >  >    o 1..n – one or more wires can have the reference as a source
>  >  >
>  >  >   The default value for the @multiplicity attribute is 1..1, 
> except where
>  >  >   the promoted component reference has @nonOverridable==false and
>  >  >   @multiplicity 0..1 or 1..1 and the reference has a target, in which
>  >  >   case the default value for @multiplicity is 0..1.
>  >  >   <scn>I find it surprising that the default is 1..1 rather than the
>  >  >   multiplicity setting of the promoted component reference.  Assuming
>  >  >   this was a deliberate choice and not a cut-and-paste error, this
>  >  >   additional special case of a 0..1 default needs to be added.
>  >  >   </scn>
>  >  >
>  >
>  > +1 The words for multiplicity default on a component reference consider
>  > componentType multiplicity in ASM50009 and the following paragraph. The
>  > words you've proposed seem appropriate.
>  >
> I think the words in the paragraph following ASM50009 are fine, but
> I'm less convinced about the words in the paragraph preceding ASM60011.
> 
> This default of 1..1 means that if I promote a component reference that
> has multiplicity 0..n and don't explicitly specify a multiplicity in
> the promoting composite reference, the multiplicity of the composite
> reference will be 1..1.  Therefore, the reference in the componentType
> of the implementation.composite will be 1..1, and it would not be
> possible to wire the reference to multiple targets in any component
> that uses the implementation.composite.
> 
> For example, the following would not work:
> 
> <composite name="Foo">
>   <component name="Bar">
>     <reference name="ref1" multiplicity="0..n"/>
>   </component>
>   <reference name="refp1" promote="Bar/ref1"/>
> </composite>
> 
> <component name="MyComp">
>   <implementation.composite name="Foo"/>
>   <reference name="refp1" target="Service1 Service2"/>
> </component>
> 
> To be able to wire MyComp/refp1 in this way, I would need to write:
> 
> <composite name="Foo">
>   <component name="Bar">
>     <reference name="ref1" multiplicity="0..n"/>
>   </component>
>   <reference name="refp1" promote="Bar/ref1" multiplicity="0..n"/>
> </composite>
> 
> <component name="MyComp">
>   <implementation.composite name="Foo"/>
>   <reference name="refp1" target="Service1 Service2"/>
> </component>
> 
> This seems inconsistent with other promotion cases where
> attributes of the composite service or reference default to
> the corresponding attributes of the underlying promoted
> component service or reference.
> 
>   Simon
> 
>  >  >   The value specified for the @multiplicity attribute of a composite
>  > reference
>  >  >   MUST be compatible with the multiplicity specified on each of the
>  > promoted
>  >  >   component references, i.e., the multiplicity has to be equal or
>  >  > further restrict.
>  >  >   So multiplicity 0..1 can be used where the promoted component
>  > reference has
>  >  >   multiplicity 0..n, multiplicity 1..1 can be used where the promoted
>  >  >   component reference has multiplicity 0..1, 0..n, or 1..n, and
>  >  > multiplicity 1..n
>  >  >    <scn>I have added 0..1 to the above list, assuming that its 
> omission
>  >  >    was accidental rather than deliberate.
>  >  >    </scn>
>  > Seems ok, any multiplicity with an optional aspect could always be
>  > constrained
>  > to 1..1.
>  >
>  >  >   can be used where the promoted component reference has multiplicity
>  > 0..n.
>  >  >   However, a composite reference of multiplicity 0..n or 1..n
>  > cannotbe used to
>  >  >   promote a component reference of multiplicity 0..1 or 1..1
>  > respectively.
>  >  >   In addition, if the promoted component reference has
>  > @nonOverridable==false
>  >  >   and @multiplicity 1..1 and the reference has a target, then the
>  > composite
>  >  >   reference can have multiplicity 0..1. [ASM60011]
>  >  >    <scn>Added additional possibility that is an exception to the 
> normal
>  >  >    rule that promoted references can only restrict multiplicity.
>  >  >    </scn>
>  > Seems ok as you've simply said that once can specify the default.
>  >
>  >  >
>  >  >
>  >  >   Simon
>  >  >
>  >
>  > <snip>
>  >
> 
> 
> 
> ---------------------------------------------------------------------
> 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/
> 
> 
> 
> 
> 
>