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

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:  

From:
Danny van der Rijn <>

To:
Mike Edwards/UK/IBM@IBMGB

Cc:
OASIS BPEL <>

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:  

From:

Danny van der Rijn <>

To:

OASIS BPEL <>

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:  

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