08FEE6F34846874BA441ABC7C012A8E9025A78FA@usphle1c.phl.sap.corp"
type="cite">
I think entirely deleting the
SBPEL3004 statement might not be a good idea. SBPEL3005 and SBPEL3006
do specify additional information for using the sca-bpel:multiReference
extension element but these statements by themselves do not describe
the case for using the extension element in the first place. I think
SBPEL3004 precisely does that (i.e. it describes when the
sca-bpel:multiReference extension is to be used).
I like Danny's idea of taking cue
from the statements related to use of the sca-bpel:service attribute.
However I think the right sca-bpel:service attribute related statement
to use as an analogy would be - SBPE3014, which reads as (after
applying the resolution for the issue BPEL-33): "To explicitly
map a partner link to a service, the sca-bpel:service attribute MUST be
specified for the partner link".
Having said that, the SBPEL3004 statement would
then become - "To represent a variable in a WS-BPEL process definition
as an SCA multi-valued reference, the variable MUST include an
sca-bpel:multiReference extension element". How
does that sound as a proposal?
Danny, please feel free to submit new issues (or
remember to bring it up for discussion on the next call) for the
lurking issues you noted below.
--
Sanjay
On today's call, Mike Edwards proposed:
Replace the text of SBPEL3004 with: "To represent an SCA multi-valued reference a WS-BPEL process MUST use a variable which is declared with a sca-bpel:multiReference extension element."
I had some concerns with the statement that were at least echoed by
Sanjay. I was thinking that we lift the style of the text from
SCA-BPEL 2001/2:
[SBPEL2001]
If a partner link specifies a sca-bpel:service
attribute, then a service MUST be generated for the introspected
component type. [SBPEL2002]
The name of the service MUST be the value of the sca-bpel:service
attribute.
As I was looking at what replacement text I might use for 3004 or Mike
Edwards statement, what I came across was actually the next sentences,
SBPEL 3005/6:
When a variable
declaration contains the sca-bpel:multiReference extension, the type of
the variable MUST be an element of sca-bpel:serviceReferenceList.
...
[SBPEL3006] The introspected
component type MUST include a reference with a multiplicity of either "0..n" or "1..n" that corresponds to a
variable with the sca-bpel:multiReference element.
I
I propose that we simply delete SBPEL 3004.
Furthermore, I think there are some issues lurking elsewhere in this
paragraph:
- Since partnerLinkTypes aren't QNames, do we have to insist that the
partnerLinkType attribute of the sca-bpel:multiReference resolve to a
partnerLinkType declared in the same scope?
- Since we want the componentType derivation to be deterministic, how
do we determine whether it's 0..n or 1..n?
- What does . [SBPEL3007] "The type of the
reference MUST be determined by the partner link type and the partner
role attributes of the sca-bpel:multiReference extension element." mean?
- Does 3006 as above need to be tightened up to say that it's actually
not "a reference" but "THE reference pointed to by the partnerLinkType
attribute"?
Michael Rowley wrote:
DFFC62B9AF7BA64C83523FC3D9697B8CAB6BBC95@EXVMBX018-12.exch018.msoutlookonline.net"
type="cite">
http://www.osoa.org/jira/browse/BPEL-42
Title: SBPEL3004
has an incorrect 'MAY'.
Target: SCA BPEL C&I PR 01
Description:
SBPEL3004 states the following:
"In a WS-BPEL process definition, a variable MAY include an sca-bpel:multiReference
extension element that declares that the variable represents a
multi-valued reference."
'MAY' implies that some runtimes may choose
not to implement multi-valued
reference using sca:bpel:multiReference extension element. We want that
the implementation of multi-valued reference using
sca-bpel:multiReference
extension element be
portable across different runtimes.
Proposal:
Replace with --
"In a WS-BPEL process definition, a variable can include an sca-bpel:multiReference
extension element that declares that the variable represents a
multi-valued reference."
-Najeeb