Re: [sca-assembly] ASSEMBLY-136: Promoting a reference with multiplicity 1..nand targetsshould default to 0..n - Updated Proposal

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

Simon,

Comments inline as <mje>...</mje>

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:	Mike Edwards/UK/IBM@IBMGB
Cc:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	06/08/2009 17:41
Subject:	Re: [sca-assembly]  ASSEMBLY-136: Promoting a reference with multiplicity 1..n and targetsshould default to 0..n - Updated Proposal

---

Mike,
Thanks for this quick reply.  See my responses inline below.

   Simon

Mike Edwards wrote:
> 
> Simon,
> 
> Thanks for the updated document.
> 
> Unfortunately, your new version has the term "multiplicity constraint"
> without anywhere defining what it means.
> 
The meaning of this term is defined normatively in ASM60011:

  "The multiplicity constraint of a component reference is the
same
  as the multiplicity of the component reference, except for the case
  where the component reference has at least one target declared
  in which case a component reference of 1..1 has a multiplicity
  constraint of 0..1 and a component reference of 1..n has a
  multiplicity constraint of 0..n."

<mje>Yes - but I think that using a
normative statement for definitional purposes is not good</mje>

> Separately from the need to fix the document in relation to this term,
> it was the introduction of this concept that
> made me baulk at your original proposal.  I'd prefer not to introduce
> this new term at all.
> 
I understand the reluctance to introduce a new term.  I spent some
time trying different approaches for how to do this, and I thought
the form of words I came up with was quite natural because it
introduces and defines the new term in the context of a normative
rule that uses it directly.

> Would it not be simpler just to state that IF all the promoted 
> references have one or more targets configured, then
> the default multiplicity of the composite reference is 0..1 or 0..n
> where the component references are 1..1 and 1..n
> respectively.  (I happen to think this is still making things
more 
> complex, but I prefer this way of looking at it to
> introducing the term "multiplicity constraint")
> 
This is what I had proposed on the call.  Your reaction was that
this created more complexity because of the repetition of these
words in two different places.  I'd be interested in hearing other
views on the use of a new term vs. the repetitive style.  I'm not
necessarily opposed to the repetitive style (but see the following
for another slight twist to this story).

<mje>
Yes, I have two preferences, in order:
1) Don't do this at all because it makes
things harder to understand ("more complexity")
2) If we do this, do it in as simple a way
as possible - avoiding a new term and essentially
saying that the composite ref does not have
to supply a target if there is already
one on the component ref is enough for me
</mje>

One more thing to point out (in the interests of full disclosure)
is that there is one more slight difference between the approach in
the "v2-simon" document and your original proposal.  This
difference
relates to the rule for when multiple component references can be
promoted by a single composite reference without the need to specify
an explicit multiplicity on the composite reference.

  a) In your original proposal, this was allowed if and only if the
     component references all have the same multiplicity.

  b) In my proposal, this is allowed if and only if the component
     references all have the same multiplicity constraint.

I think b) is a bit more consistent, though some people might see
it as a bit more complex.  Again I'd be interested in other views
on
whether a) or b) is better.

<mje>
b) is certainly more complex.  It would
be simpler to say that in this more complex 
case, there is no default multiplicity and
it must be set manually.
</mje>

<mje>
For me the 90% case is a single ref with
a single promotion
The next most common is 2+ component refs
promoted by the same composite ref, but their
configuration is identical and there are
no internal defaults.
The next  is 2+ component refs promoted
by the same composite ref and their configuration
is identical and there is an internal default.

Cases with 2+ component refs promoted by
the same composite ref but where there is
different configuration is a very small set
of cases for me.  Making the Assembler do
some more work in this case seems a gnat's
bite compared with the complexity that the
Assembler is already heaping on themselves
by constructing a composite in this way.
I note that it is this last case that you
are really trying to "make simpler".
</mje>

   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:                
 OASIS Assembly <sca-assembly@lists.oasis-open.org>
> Date:                
 06/08/2009 09:40
> Subject:              
   Re: [sca-assembly]  ASSEMBLY-136: Promoting a
reference with 
> multiplicity 1..n and targetsshould default to 0..n - Updated Proposal
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> As discussed on Tuesday's call, here is an update to Mike's proposal
> that uses the concept of multiplicity constraint to define both the
> compatibility rules and the defaulting rules for composite references.
> 
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/33674/sca-assembly-1.1-spec-cd03-Rev2%20Issue136v2-simon.doc
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/33675/sca-assembly-1.1-spec-cd03-Rev2%20Issue136v2-simon.pdf
> 
>   Simon
> 
> Mike Edwards wrote:
>  >
>  > Folks,
>  >
>  > Sorry, I was trying to be too clever by half.
>  >
>  > Updated version of the proposal is here:
>  >
>  > 
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/33598/sca-assembly-1.1-spec-cd03-Rev2%2BIssue136v2.pdf
> 
>  >
>  > 
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/33597/sca-assembly-1.1-spec-cd03-Rev2%2BIssue136v2.doc
> 
>  >
>  >
>  > 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:              
   David Booz <booz@us.ibm.com>
>  > To:                
 sca-assembly@lists.oasis-open.org
>  > Date:              
   29/07/2009 19:06
>  > Subject:              
   Re: [sca-assembly]  ASSEMBLY-136: Promoting 
> a reference with
>  > multiplicity 1..n and targetsshould default to 0..n - Updated
Proposal
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Hi Mike,
>  >
>  >  >From the PDF:
>  >
>  > 1) lines 1466-1480 - Is there a formatting problem here
or some typos?
>  > The paragraph doesn't read well. Seems self contradictory.
>  >
>  > *This is caused by me not accepting the deletion of the
old form of the
>  > normative statement in the table in Appendix C -*
>  > *if you don't do this, then the insertion of the reference
to it in the
>  > main text ends up containing both the old deleted*
>  > *version and the new replacement version.  I didn't
check the text
>  > carefully enough.  Sorry.*
>  >
>  > 2) tables on lines 1484 and 1485 show checks and x's but
the table in
>  > the doc file shows numbers (4's and 5's)? Looks like 4's
are checks and
>  > 5's are x's. What's going on here?
>  >
>  > *Well, I was trying to use check marks and crosses to indicate
"allowed"
>  > and "not allowed" in the table, since it looks
more*
>  > *effective on the page.  So I chose the WingDings
font and then used the
>  > symbols from that font for check mark and cross, which*
>  > *happen to be "4" and "5" on the keyboard.
 But I forgot that such fonts
>  > don't necessarily render correctly on everyone's*
>  > *system.*
>  >
>  > *So I've gone back to a much less visually effective form
- "YES" and
>  > "NO" using the standard font.  But at least
everyone will*
>  > *see the same now...*
>  >
>  > 3) As far as the technical content goes, it looks like
what we talked
>  > about. Thanks for writing it up.
>  >
>  > *Yes, I ended by being surprised by how relatively little
change there
>  > was, although I think that the proposal makes things*
>  > *conceptually a lot simpler.  The tables are a useful
clarification,
>  > although not strictly essential.*
>  >
>  > 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 Mike Edwards ---07/29/2009 07:39:41
>  > AM---Folks, Here is a proposal for Issue 136Mike Edwards
---07/29/2009
>  > 07:39:41 AM---Folks, Here is a proposal for Issue 136
>  >
>  > From:              
   
>  > Mike Edwards <mike_edwards@uk.ibm.com>
>  >
>  > To:                
 
>  > "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
>  >
>  > Date:              
   
>  > 07/29/2009 07:39 AM
>  >
>  > Subject:              
   
>  > [sca-assembly] ASSEMBLY-136: Promoting a reference with
multiplicity
>  > 1..n and targetsshould default to 0..n - Updated Proposal
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  >
>  > Folks,
>  >
>  > Here is a proposal for Issue 136
>  >
>  > Concepts in the proposal:
>  >
>  > 1) A component reference can explicitly declare as many
targets as are
>  > compatible with its multiplicity
>  >
>  > 2) When a component reference is promoted, IF the composite
reference(s)
>  > is configured with at least 1
>  > target (ie through the component that uses the composite)
then the
>  > composite reference targets OVERRIDE
>  > the targets declared on the component reference (ie the
component
>  > reference targets are not used)
>  >
>  > 3) When a component reference is promoted, IF the composite
reference(s)
>  > has 0 targets configured
>  > then any targets declared on the component reference are
used (ie the
>  > declared targets act as default targets)
>  >
>  > 4) For x..n component references, it is possible to mark
the reference
>  > @nonOverridable="true". In this case,
>  > the set of targets which are used for the reference is
the set
>  > configured on any composite references which promote
>  > the reference PLUS the set of targets declared on the reference
itself.
>  >
>  > 5) For x..1 component references, @nonOverridable="true"
means that the
>  > reference cannot be promoted.
>  >
>  > 6) To set policy (etc) for "internal" references:
>  > - use intents
>  > - or attach policySets using ExternalAttachment
>  > - or attach policySets directly
>  > (since they can't be configured at all by promotion)
>  >
>  > 7) The default multiplicity of a composite reference is
determined by:
>  > - the multiplicities of the component references it promotes
>  > - whether (all) the promoted component references have
at least 1 target
>  > declared
>  >
>  > with the principle being that the multiplicity must be
set to ensure
>  > that the component references will have
>  > their multiplicity satisfied - 0..x is allowed for the
case where the
>  > component reference is 1..x, if there is
>  > a target declared on (all) the component references.
>  >
>  >
>  > I've done the formal proposal as a marked up version of
CD03-Rev2 (all
>  > changes were accepted BEFORE
>  > adding the changes for this proposal)
>  > _
>  > __
>  > 
> __http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/33566/sca-assembly-1.1-spec-cd03-Rev2%2BIssue136.pdf_
> 
>  > _
>  > 
> __http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/33565/sca-assembly-1.1-spec-cd03-Rev2%2BIssue136.doc_
> 
>  >
>  >
>  >
>  > 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
>  >
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > /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/
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > /
>  > /
>  >
>  > /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
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /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

---

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