RE: [sca-assembly] [ASSEMBLY 122] Incorrect Usage of MAY Keyword - Revised Proposal, Part 1

["Eric Wells" <eric.wells@hitachisoftware.com>]

Simon,
      comments inline below. I will produce a rev that addresses your
comments, those from Dave, and what we discussed during today's telecon.

Best Regards,
              Eric.
Eric Wells.
Consulting Engineer.
Hitachi Computer Products (America) Inc.
San Francisco, CA. USA.
+1 (415) 656-4346
eric.wells@hitachisoftware.com
  

> -----Original Message-----
> From: Simon Nash [mailto:oasis@cjnash.com] 
> Sent: Tuesday, May 05, 2009 5:57 AM
> To: Eric Wells
> Cc: OASIS SCA Assembly List
> Subject: Re: [sca-assembly] [ASSEMBLY 122] Incorrect Usage of 
> MAY Keyword - Revised Proposal, Part 1
> 
> Eric,
> Thanks for these proposals.  See comments inline.
> 
>    Simon
> 
> Eric Wells wrote:
> > All,
> >     I took an AI to make ASSEMBLY-122 more manageable and here is a 
> > revised proposal.
> > 

<SNIP>

> > 1) Section 4.3 Reference, Lines 805 - 813
> > -----------------------------------------
> > Now addressed by http://www.osoa.org/jira/browse/ASSEMBLY-134. 
> > Paragraph has been made non-normative in the attached document.
> > 
> Actually, ASSEMBLY-134 addresses a separate but related point.
> When ASSEMBLY-134 is resolved, I was intending to produce a 
> proposal for the other changes that are needed to this 
> paragraph and section 5.2.  I was expecting to include these 
> other changes as part of this issue, but we could expand 
> ASSEMBLY-134 to cover them or I could raise a separate issue for this.
> 

As the original document did not mark the statement as normative I just
changed "MAY" to "can".
I did not mean to imply ASSEMBLY-134 addresses this issue, rather that it
would probably make its own changes to this text. Hence I thought I should
make the simplest change possible for ASSEMBLY-122

<SNIP>
 
> > 
> > 3) Section 4.3.1.1, Lines 893 - 901 [ASM50018] thru [ASM50021]
> > --------------------------------------------------------------
> > The rules constraining the number of target services use MAY 
> > incorrectly to indicate @multiplicity semantics. Reword as follows:
> > 
> > 	. A reference with multiplicity 0..1 MUST have no more than one 
> > target service defined. [ASM50039]
> > 	. A reference with multiplicity 1..1 MUST have exactly one target 
> > service defined. [ASM50040]
> > 	. A reference with multiplicity 1..n MUST have at least one target 
> > service defined. [ASM50041]
> > 	. A reference with multiplicity 0..n can have any number of target 
> > services defined.
> > 
> These changes look good to me.
> 
> > 	The reference MUST be wired to all of the defined target services
and 
> > able to invoke operations on each target service. [ASM50042]
> > 
> > The new normative statement [ASM50042] needs further checking against 
> > the rules for deployment of unwired composites. ([ASM60021] on lines 
> > 1778 - 1780) I think this is OK as there would not be targets for these 
> > unwired composites?
> > 
> I don't understand why this new statement is needed.  It 
> doesn't have a clear conformance target and the first part 
> appears to be a tautology (specifying target services is one 
> form of wiring).  The second part seems strange as well, as 
> it is not the reference that invokes services.
> 
> If such a statement is needed, it should not appear in 
> section 4.3.1.1, which is about multiplicity.  A more general 
> form of this would be to say that the SCA runtime MUST permit 
> a reference to be used to invoke operations on all target 
> services of the references.  If we need to say this (and I am 
> not sure that we do), section 5.4 seems a more suitable place.
>

I agree. I wasn't particularly happy with this anyway. I wanted to say the
target services should be "invokeable" to align with the Test Assertions and
Test Cases, but I didn't like the wording and thought it should probably be
in a different place.

The subject is moot however as I've deleted [ASM50042] as agreed during
today's telecon.

> > 
> > 4) Section 6, lines 2326 - 2330 [ASM70005]
> > ------------------------------------------------------------
> > Normative statement [ASM70005] uses MAY incorrectly to indicate 
> > possible implementation artifacts. Make the first part non-normative and
reword as:
> > 
> > 	It is possible that an implementation contains additional services, 
> > additional references with
> > 	@multiplicity=0..1 or @multiplicity=0..n and additional properties 
> > with @mustSupply=false beyond
> > 	those declared in the constraining type. However, an implementation 
> > MUST NOT contain additional
> > 	references with @multiplicity=1..1 or @multiplicity=1..n or 
> > additional properties with
> > 	@mustSupply=true [ASM70005]
> > 
> I'm not sure that there is a problem with the original wording.
> It is defining something optional that a component 
> implementation is allowed to either do or not do.  I also 
> think the revised wording is OK.
> 

Reworded as per Daves' suggestion in:
http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/200
905/msg00016.html

I think the original needed correcting as it would be the developer who
determines if an implementation contains the additional items. I don't think
it would be an optional choice of the SCA runtime vendor as to whether or
not  these items are "supported".

> > 
> > 5) Section 8, lines 2740 - 2741 [ASM90004]
> > ------------------------------------------
> > I believe the intent of [ASM90004] is to say the following:
> > 
> > 	To wire to a specific binding of a target service the syntax 
> > "componentName/serviceName/bindingName"
> > 	MUST be used. [ASM90004]
> > 
> This statement is in the wrong place.  It should appear in 
> section 5.4 as a valid alternative to the 
> <component-name>/<service-name> syntax.
> 
> If the componentName/serviceName/bindingName syntax is 
> defined in section 5.4, it would be helpful to also mention 
> it here using a non-normative statement.
> 

I thought this seemed out of place, but I wanted to keep ASSEMBLY-122
focused only on changes to the keywords.

> > 
> > 6) Section 11.6, lines 3697 - 3708 [ASM12013]
> > ---------------------------------------------
> > The MAY keyword is redundant in the list of mandatory 
> (MUST) choices. 
> > Reword
> > as:
> > 
> > 	For components at the Domain level, with References for which 
> > @autowire="true" applies, the
> > 	behavior of the SCA runtime for a given Domain MUST take ONE of the
> > 3 following forms:
> > 
> > 	1) The SCA runtime disallows deployment of any components with 
> > autowire References.
> > 	In this case, the SCA runtime MUST raise an exception at the point 
> > where the component is deployed.
> > 
> > 	2) The SCA runtime evaluates the target(s) for the reference at the 
> > time that the component is
> > 	deployed and not update those targets when later deployment actions 
> > occur.
> > 
> Change "and not" to "and does not" in above sentence.
> 

A typo - fixed in the next rev.

> > 
> Looks OK, with the small wording change suggested above.
> 
>    Simon
>