sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] ASSEMBLY-136: Promoting a reference with multiplicity 1..nand targetsshould default to 0..n - Updated Proposal
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
- Date: Tue, 11 Aug 2009 11:13:43 +0100
Anish,
I agree that complexity is the problem
here.
In a previous note I spelled out what
I thought were the common cases when using composite references and promotion
and I noted then that a lot of the discussion
on this issue centered on seldom used configurations - and that we seem
to be
making things easier for the complex
cases at the price of making the simple things more complex, which I don't
like.
Regarding your thoughts below:
1) - I'd be happy with. Always
explicitly state the multiplicity - or as one slight further step, always
have the multiplicity default to 1..1
(which I think is acceptable in all
cases). If the assembler doesn't like that, then put in what they
want explicitly and there are no doubts.
I note that if this is the case, the
composite ref multiplicity is not affected by anything - some combinations
of composite ref multiplicity
and component ref multiplicity are illegal,
but these are easily explained.
2) - removes useful function and seems
like throwing the baby out with the bathwater
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:
| Anish Karmarkar <Anish.Karmarkar@oracle.com>
|
To:
|
|
Cc:
| OASIS Assembly <sca-assembly@lists.oasis-open.org>
|
Date:
| 11/08/2009 08:54
|
Subject:
| Re: [sca-assembly] ASSEMBLY-136:
Promoting a reference with multiplicity 1..n and targetsshould default
to 0..n - Updated Proposal |
The changes are certainly more consistent.
Like MikeE, I also like definitions to *not* be numbered normative
statements. But I do think that if something is used in two places, it
is better to define it once and use it in multiple places. It is very
easy to get them out of sync.
As I mentioned on the last call, I'm very concerned about the complexity
here. We have the following wrt multiplicity of wires:
1) Multiplicity of the reference in the CT (defaults to 1..1)
2) Multiplicity of the component reference (defaults to the CT
multiplicity).
3) wiredByImpl: don't ever wire it (0..0)
4) nonOveridable: default is false. Specifies if composite wires
override component wires.
5) Promotion: can promote only 1 ref or multiple refs, rules of what can
be promoted aren't simple. Value of nonOverridable and existing wires
affect it.
6) Defaulting of multiplicity of composite refs: depends on other
existing wires
I'm trying to figure out if there is a way to simplify this. Two ideas:
1) no default on composite refs. The assembler must include the
multiplicity attribute. This doesn't seem like much of a burden on the
assembler. Especially if it avoids complexity (in trying to calculate
the default based on the existing wires, recursive composition, CT.
Figuring out the multiplicity for composite refs with several levels of
nesting would not be simple.)
2) Disallow composite ref from promoting multiple component references.
This is more "radical" than (1) above and will result in loss
of a
feature. In the absence of this, the assembler would have to ensure that
the same target values for multiple promoted refs get used, if the
assembler wants to ensure that the targets are the same.
Thoughts?
-Anish
--
Simon Nash wrote:
> Mike,
> Responses inline.
>
> Simon
>
> Mike Edwards wrote:
>>
>> 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>*
>>
> This could be moved out of the normative statement, but this would
> mean that Appendix B contains a normative statement that uses a term
> which isn't defined in Appendix B. For a simple definition like
this
> it seems awkward to require the reader of Appendix B to hunt around
> in the main chapter for the relevant definitional sentence.
>
>> > 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>*
>>
> I am OK with approach 2). Explaining it this way makes it easier
to
> understand than just saying that 1..1+target => 0..1. I'll
update my
> proposal to add these words and remove the "multiplicity constraint"
term.
>
>> 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>*
>>
> The phrase I used was "more consistent". Simplicity
is in the mind
> of the beholder :-) However, I think there is a concern that
if two
> promoted references have 1..1 multiplicity and one is targeted but
the
> other isn't, the default for the composite reference shouldn't be
> 1..1 (as it would be according to your original proposal). As
you are
> saying here, it would be better to only have a default multiplicity
> at the composite level if the promoted multiplicities match AND the
> promoted component references are either all targeted or all untargeted.
> I'll add this to my updated proposal.
>
> Simon
>
>> 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/
>>
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]