Minutes
Scribe: Danny van der Rijn
approval of minutes
Resolution: Minutes of 2009-03-26 located at http://lists.oasis-open.org/archives/sca-bpel/200903/msg00060.html approved
AI review
Neither Anish nor Khaderao had time to get to theirs. Both actions remain open
Testing Schedule
Proposal -- Sanjay: target for first milestone (4/9) may still be achievable. Other dates would be used to trigger discussions
with liason committee.
Anish:
Issue has been raised by Dave, and in other TCs.
MichaelR:
Isn't ##any used for forward compatibility
Motion: Open issue and close with proposal in email (m:Danny, s:Najeeb)
Anish:
Not for UPA, for scope extensibility. If we define our attribute, we define how it's used. WRT to future version allowing
use of a new attribute, this would only come into play if the SBPEL namespace weren't changed.
Michael: Are we going to allow any possibility for a backward compatible change? Determination by SCA seems to be not.
Who are we in BPEL to say ##otherwise?
Motion carries unanimously
Resolution: issue 30 resolved with proposal in JIRA
Test assertion doc and testing
Sanjay:
Anish posted most current version last night, as above
Mike: Where are the 2 attributes attached?
Sanjay:
Question originates in spec ambiguity.
<Sanjay>
The partnerLinkType and partnerRole attributes of the <partnerLink> and the child element <sca-bpel:multiReference> of the
associated multi-valued reference variable MUST be matched.
Mike: An issue needs to be raised. Wording needs to be much more specific. Still don't like wording - isn't specific enough
<anish>
The @partnerLinkType and @partnerRole attributes of the <partnerLink> and the child element <sca-bpel:multiReference> of the
associated multi-valued reference variable MUST be matched.
Sanjay:
Agree with Mike. Need to be more clear. Need an action to open the issue
Action: Sanjay to open the issue
<Michael Rowley>
The partnerLinkType and partnerRole attributes of the partner link MUST be the same as the partnerLinkType and partnerRole
attributes of the <sca-bpel:multiReference> child element of the variable named by the @multiRefFrom attribute of the partner
link.
<anish>
The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole
attributes of the <sca-bpel:multiReference> child element of the variable named by the @multiRefFrom attribute of the partner
link.
Anish:
Does the wording above seem right? Should we try to resolve this now?
<anish>
it would be issue #31
Sanjay:
Question about last clause: "named by ..." part - is it precise enough to be spec language?
<anish>
The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole
attributes of the <sca-bpel:multiReference> child element of the variable named by the @multiRefFrom attribute of the <partnerLink>.
MichaelR:
Will get harder to read if we try to add variable reference semantics
anish added more angle bracket
<anish>
how about s/named/identified/
<anish>
The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole
attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom
attribute of the <partnerLink>.
<Michael Rowley>
Title -- SBPEL3011 Assertion needs to be clarified
<Michael Rowley>
he assertion:
[SBPEL3011] The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST
be matched.
is vague.
Proposal:
It should be changed to the following:
[SBPEL3011] The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType
and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the
value of the @multiRefFrom attribute of the <partnerLink>.
Motion: To open an issue with title and body as pasted into room above (m: Michael Rowley, s: Anish)
Motion carries unanimously
Motion: Resolve new issue according to proposal (m:Michael Rowley, s: Khanderao)
Motion carries unanimously
Resolution: issue 31 resolved with proposal in JIRA
Sanjay:
Back to test assertions...
Action: Sanjay to reword SBL-TA-SP01 to reflect new tighter spec languageanish i think finishing review of TAs by next week is not going to happen
Mike: Not testing a runtime anymore - you have to make a test runtime.
<Sanjay>
Title -- SBPEL3013 and SBPEL3014 use of RFC2119 'MAY' incorrectly
<Sanjay>
Proposal: Use alternative wording for RFC 2119 'MAY' e.g. 'can'.
Motion: Open a new issue, with title and proposal as typed above by Sanjay. (m: Sanjay, s: Danny)
Motion carries unanimously (Issue # will tentatively be 32)
Resolution: Issue 33 is opened
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Title not specified, default title 'OASIS SCA-BPEL TC...' was assumed
citation-detection-scribed: Line 66: Check for possible unrecognized nick 'Motion'
citation-detection-scribed: Line 70: Check for possible unrecognized nick 'Michael'
citation-detection-scribed: Line 88: Check for possible unrecognized nick 'Mike'
citation-detection-scribed: Line 94: Check for possible unrecognized nick 'Mike'
citation-detection-scribed: Line 137: Check for possible unrecognized nick 'Motion'
citation-detection-scribed: Line 143: Check for possible unrecognized nick 'Motion'
citation-detection-scribed: Line 156: Check for possible unrecognized nick 'Mike'
citation-detection-scribed: Line 166: Check for possible unrecognized nick 'Motion'
statistics: Schreiber found 108 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 96: anish: s/partner link/<partnerLink>
edits: Line 168: Danny van der Rijn: s/description/proposal/
citation-detection-irc1: Line 3: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 11: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 19: Check for possible unrecognized nick 'Proposal'
citation-detection-irc1: Line 29: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 32: Check for possible unrecognized nick '3rd draft'
command-scribe: Line 37: Danny van der Rijn recognized
command-scribe: Schreiber detected that this section was scribed online
edit-substitute: command on line 96 succeeded, changed line 92 from 'partner link' to '<partnerLink>'
edit-delete: Line 96 was deleted
citation-detection-irc1: Line 131: Check for possible unrecognized nick 'Proposal'
edit-substitute: command on line 168 succeeded, changed line 166 from 'description' to 'proposal'
edit-delete: Line 168 was deleted
system: Transformer: SAXON 9.0.0.2
[End of Schreiber diagnostic output]