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

[Mike Edwards <mike_edwards@uk.ibm.com>]

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.

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.

Which may argue for requiring the multiplicity
to be specified at all times, with no default.

At least having a fixed default avoids
this problem and a tool can always verify that the 
multiplicities are correctly matched
within the composite....


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