OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[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'.

A bit of thinking out loud:

I have some issue with that formulation (and actually the 3014 one..) - what is the target of the 2119 statement?  We're not saying that a variable has to include a multiRef, we're saying that it has to include it if [target] wants it to be  multi-valued.  The spec's 2119 language shouldn't concern itself with user intentions.  It seems to me that this conflates 2 things together:  how to encode a semantic intention, and what the requirements for doing so are.  Which is why I don't think 3004 belongs.  Or at least it doesn't belong as 2119 language:

In a WS-BPEL process definition, it is possible for a variable to include an sca-bpel:multiReference extension element that declares that the variable represents a multi-valued reference.

Patil, Sanjay wrote:
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

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Thursday, May 14, 2009 9:26 AM
To: sca-bpel@lists.oasis-open.org
Subject: Re: [sca-bpel] ISSUE 42: SBPEL3004 has an incorrect 'MAY'.

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 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">


From: Najeeb Andrabi [mailto:nandrabi@tibco.com]
Sent: Friday, May 08, 2009 2:06 PM
To: sca-bpel@lists.oasis-open.org
Subject: [sca-bpel] NEW ISSUE: SBPEL3004 has an incorrect 'MAY'.

Title: SBPEL3004 has an incorrect 'MAY'.

Target: SCA BPEL C&I PR 01

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.


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."


S/MIME Cryptographic Signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]