[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ASSEMBLY-136: Promoting a reference with multiplicity1..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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]