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

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

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.

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