[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
Anish,
Sorry that I did not see this before sending out the latest draft.
This draft may still be useful to show what the wordier/repetitive
version actually looks like in the spec.
I agree that we have a lot of complexity in this area. Your
suggestion 1) seems sensible and I would be fine with that. It seems
better to have no default than to either have a "bad" default or
complex rules for calculating a "good" default.
Regarding 2), I don't think this adds very much complexity compared
with some of the other items on your list, especially if we make
change 1). I think the feature is useful because it hides internal
details from the assembler, who sees a single reference in a composite
implementation and doesn't need to be aware that this promotes multiple
references within the internal components that make up the composite.
So on balance I don't think we should remove this feature.
Simon
Anish Karmarkar wrote:
> 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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]