Re: [sca-bpel] [ISSUE 62] More on multiplicity 0..1 - Updated Proposal #3

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

Folks,

Comments inline

Updated version of the proposal is here:


http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/36481/sca-bpel-1.1-spec-cd02-rev7-Issue62c.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:	Danny van der Rijn <dannyv@tibco.com>
To:	Mike Edwards/UK/IBM@IBMGB
Cc:	OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date:	19/02/2010 12:34
Subject:	Re: [sca-bpel] [ISSUE 62] More on multiplicity 0..1 -  Updated Proposal

---

Very nice.  Minor quibbles I didn't bring up on the
call yesterday:

- " Wired by Implementation Reference."
 My brain stumbles parsing this.  I can offer suggestions along
the lines of Process-Initialized Reference
<mje>
"Wired by Implementation"
is the term used in the Assembly spec.
I am loathe to move
away from what is used in the Assembly spec.
I'd be happy for you
to raise an issue in Assembly to change the term used in that spec and
then reflect that back
here.  I note that this term was created expressly for the BPEL spec
and is not used by
any other Implementation spec as far as I am aware....
</mje>

- "Note that a 0..1 multiplicity
reference can have no target configured in the using component."  Again,
I stumble with "can have no..."  I offer "Note that
it is possible for a 0..1 multiplicity reference to have no..."
<mje>
OK - how about this
bit of wordsmithing:

"Note that it is valid for the component that uses a BPEL process as an implementation to have no target defined for a 0..1 multiplicity reference"

</mje>


Note the difference in wording between SBPEL2025, and SBPEL2014 in the next paragraph - the .. component vs. any ... component.  Also, 2014 makes the component the conformance target, rather than the Runtime.

<mje>
There are different targets here.  I could make the argument that in one sense SBPEL2014 is redundant in that once the multiplicity of a reference is fixed
then Assembly makes the requirement that the reference is wired or not.  However, I am happy to leave 2014 as it is since it does make things explicit
in the BPEL case..

2025 correctly says "the component" since it is referring to each specific component instance and its specific configuration.

</mje>

- in 3029, sca should be capitialized.
<mje>
Agreed
</mje>

- in 3029, insert "the" into "A variable with the"
<mje>
Done
</mje>

- in 3029 " for the targets of the multi-reference (noun?) represented .. ."
<mje>
The term "multi reference" is defined in section 2.1.1 and it is a noun, so I think that the construction of
the sentence in 3029 is correct.
</mje>

Danny

On 2/19/2010 1:25 AM, Mike Edwards wrote:

Folks,

Thanks to Danny for completing his part of the necessary changes.

I've uploaded a new version of the proposal that contains my changes on top of Danny's:

http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/36479/sca-bpel-1.1-spec-cd02-rev7-Issue62b.doc


Changes that I have made:

1. In section 2.1.1, separated out [SBPEL2025] from bullet #4 to make it stand alone.  Adjusted the
wording so that it now applies to both 0..1 and 1..1 multiplicity references.

2. In section 3.2, created a new normative statement which is the equivalent to SBPEL2025 for 0..n and 1..n multiplicity references.
This is [SBPEL3029].  It makes what was previously a non-normative piece of text into a normative statement

3. Section 3.5 ("Danny's" new section). Gave each new normative statement a final number like SBPEL3026.
Also tinkered with the formatting.



I also note that we have some editorial work to do to bring the BPEL spec into line with the format adopted by most of the other
TCs..  In particular:

a. Every diagram should have a caption containing a number.

b. Every code example should be cleanly separated from the surrounding text (grey background, line above and line below) and each
should have a caption containing a number.

c. All references to "code" examples and to diagrams should be done using the number.

d. All normative statements should have a background colour of yellow.  At the moment it is impossible to determine where a normative
statement ends.


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:	Danny van der Rijn <dannyv@tibco.com>
To:	OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date:	18/02/2010 20:13
Subject:	Re: [sca-bpel] [ISSUE 62] More on multiplicity 0..1 -  Updated Proposal

---

New document uploaded here:

As per the call today, I have taken Mike's proposal and made the following
changes:

minor typo corrections.  pseudo-numbering of normative statements.

For the following comment: 
anish:  the 1st stmt in section 3.5 should be moved to the conformance
section 

- I have removed the 1st statement in 3.5.  It is covered, IMO by
the conformance section 5.2.2

2.               The implementation MUST support the SCA BPEL extensions defined in Section 3, and MUST implement them as defined.

For the following comment:

anish: the 1st SBPELXXXX, do we need it. Or is the fact that this is used in a WS-BPEL doc and therefore WS-BPEL rules apply

- I have removed the entire statement.  As Dieter pointed out, it is most likely covered by WS-BPEL itself.

For the following comments:

MikeE: few stmts contain 2119 stmt but not marked as such
 
... there is a MUST and a SHOULD that is unmarked
 
... the sentence "This function determines whether the partnerRole of the specified partnerLink is set. The argument names the partnerLink, and it MUST have the following properties" doesn't need the MUST
 
... the other stmt that is unmarked is "These properties SHOULD be enforced by static analysis."
<Dieter Koenig> = SBPEL5002
Dieter: SBPEL5002 already covered the SHOULD, so can be removed

- I have reworded to get rid of the leading MUST, and deleted the sentence with the trailing SHOULD


On 2/11/2010 3:43 AM, Mike Edwards wrote:

Folks,

I have done the work item assigned to me in relation to Issue 62 and I have posted an updated document here:

http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/36347/sca-bpel-1.1-spec-cd02-rev7-Issue62A.doc

Comments welcome

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

---

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