[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bpel] ISSUE 42: SBPEL3004 has an incorrect 'MAY'.
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
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"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]