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: Formatted minutes of 2008-12-11 telcon


Attached.

Note: we have already approved minutes of 2008-12-11, but I had 
neglected to send out the formatted minutes last year. I'll be uploading 
these formatted minutes to our repository.

-Anish
--
Title: SCA-BPEL - 2008-12-11

OASIS Logo

OASIS SCA-BPEL TC

11 DEC 2008

Attendees

Present
Michael Rowley, (Active Endpoints, Inc.)
Dave Booz, (IBM)
Mike Edwards, (IBM)
Martin Chapman, (Oracle Corporation)
Anish Karmarkar, (Oracle Corporation)
Sanjay Patil, (SAP AG)
Najeeb Andrabi, (TIBCO Software Inc.)
Chair
Sanjay Patil
Scribe
Michael Rowley
Agenda:
http://lists.oasis-open.org/archives/sca-bpel/200812/msg00002.html

Contents

Topics
[1]  Approval of 2008-11-20 minutes
[2]  CamelCase convention from LSC.
[3]  Testing committee
[4]  New Issue: Additional Integrity Constraints for Component Type Side Files
[5]  Issue 26
Table of Resolutions
Table of Action Items

Action Items

New:

Resolutions


Minutes

Scribe: Michael Rowley

<anish>
1. Roll Call
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/roster.php
2. Appointment of scribe
Scribe list attached below
3. Agenda bashing
4. Approval of Nov 20, 2008 minutes
5. Action items review
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/action_items.php
None
6. Administria
a) CamelCase convention recommendation from LSC
http://lists.oasis-open.org/archives/sca-bpel/200811/msg00022.html
b) Participation in SCA-Assembly Testing SubCommittee
http://lists.oasis-open.org/archives/sca-bpel/200811/msg00025.html
7. New Issues
a) Additional Integrity Constraints for Component Type Side Files
http://lists.oasis-open.org/archives/sca-bpel/200811/msg00020.html
Submitter: Dieter Koening
b) Removal of XPath 1.0 query language constraint on implementationRef attribute
http://lists.oasis-open.org/archives/sca-bpel/200811/msg00024.html
Submitter: Najeeb Andrabi
8. Issue Discussion
a) Issue 18 - http://www.osoa.org/jira/browse/BPEL-18
TITLE - Need to rewrite the SCA-BPEL specifications with RFC-2119
keywords/statements
Latest proposal: http://lists.oasis-open.org/archives/sca-bpel/200811/msg00021.html
b) Issue 24 - http://www.osoa.org/jira/browse/BPEL-24
TITLE BPEL C&I spec needs to define how effective CT is synthesized
9. AOB
 
Acting as scribe.
 
Agenda approved

Approval of 2008-11-20 minutes

<anish>
 
Minutes from Nov 20 2008 approved.
<anish>
Resoution: Minutes of 2008-11-20 posted at http://lists.oasis-open.org/archives/sca-bpel/200812/msg00003.html approved
 
Anish & Sanjay can't make the next call.
anish i'm going to be at another f2f
 
Michael R moves that we cancel the next call, seconded by Dieter.
<Mike Edwards>
I think the rest of us should have a party instead
 
Approved unanimously (next call cancelled).
Resolution: 2008-12-18 call canceled
<Sanjay>
Next conf-call: Jan 8th, 2009

CamelCase convention from LSC.

<Mike Edwards>
Latest Assembly spec:
<Mike Edwards>
<Mike Edwards>
Section 1.3 between lines 63 and 77
 
Rowley wonders whether this convention is necessary to include in the specification text.
 
Martin thinks it can be useful and can't harm.
<anish>
here is the text:
<anish>
Naming Conventions
This specification follows some naming conventions for artifacts defined by the specification,
as follows:
For the names of elements and the names of attributes within XSD files, the names follow the
CamelCase convention, with all names starting with a lower case letter.
eg <element name="componentType" type="sca:ComponentType"/>
For the names of types within XSD files, the names follow the CamelCase convention with all
names starting with an upper case letter.
eg. <complexType name="ComponentService">
For the names of intents, the names follow the CamelCase convention, with all names starting
with a lower case letter, EXCEPT for cases where the intent represents an established acronym,
in which case the entire name is in upper case.
An example of an intent which is an acronym is the "SOAP" intent.
 
Mike E moves that the SCA-BPEL specification have a Naming Convention section that matches the Naming Convention section of the Assembly specification CD01-ref4 from lines 63 to 77.
 
Dave Booz seconds.
<Mike Edwards>
Naming Conventions
64
65 This specification follows some naming conventions for artifacts defined by the specification,
66 as follows:
67
68 For the names of elements and the names of attributes within XSD files, the names follow the
69 CamelCase convention, with all names starting with a lower case letter.
70 eg <element name="componentType" type="sca:ComponentType"/>
71 For the names of types within XSD files, the names follow the CamelCase convention with all
72 names starting with an upper case letter.
73 eg. <complexType name="ComponentService">
74 For the names of intents, the names follow the CamelCase convention, with all names starting
75 with a lower case letter, EXCEPT for cases where the intent represents an established acronym,
76 in which case the entire name is in upper case.
77 An example of an intent which is an acronym is the "SOAP" intent.
 
Michael Rowley moves to amend to remove the third bullet from that specification text.
 
Najeeb seconds.
 
Anish wonders if this should be represented as a new issue (which now require 2/3 majority)
<anish>
if we all agree this is editorial, then i suppose we can skip filling a new issue. If not, i think we should file a new issue. The key here, i think, is that we have a consensus that this is editorial.
 
Sanjay checks for objections (none heard) for treating this as a motion and not a new issue.
 
Amendment accepted unanimously
 
Main motion accepted unanimously:
Resolution: That the SCA-BPEL specification have a Naming Convention section that matches the Naming Convention section of the Assembly specification CD01-ref4 without the third bullet of that section.

Testing committee

 
Sanjay asks if we should have a formal representative.
 
No support expressed for the idea.
 
Mike notes that the BPEL specific work will have to be done by someone, and unless someone specifically signs up, they are unlikely to occur.
 
Sanjay believes there should be a formal representative and asks for volunteers.
 
No volunteers came forward.

New Issue: Additional Integrity Constraints for Component Type Side Files

 
<anish>
dieter, is this ready for resolution?
 
Dieter moves Anish seconds to open issue BPEL-25.
 
Approved no objection.
Resolution: issue 25 opened
<anish>
PROPOSAL from Dieter: Add normative constraints to this section in order to avoid such
useless specifications.
"A service MUST NOT identify a partner link with a partnerRole attribute
referencing a role which is the only role of a partner link type."
and
<anish>
"A reference MUST NOT identify a partner link with a myRole attribute
referencing a role which is the only role of a partner link type."
 
Dieter moves to accept the proposal as the resolution to issue 25. Anish seconds.
<anish>
I'm wondering if we should flip the wordings
<anish>
A service MUST NOT reference a partner link without a @myRole attribute ??
<anish>
(not sure if "reference" is the right phrase here, perhaps the original 'identify' is better)
<Sanjay>
Start with - 'When a partner link type has only one role'
 
Dieter notes that "without a @myRole attribute" isn't sufficient, since the partnerLink may actually have a myRole, even if the partnerLink definition doesn't have a "@myRole" attribute.
 
Motion carried without objection
Resolution: Issue 25 is resolved with the proposal in JIRA

Issue 26

 
 
Rowley is concerned that this is overkill for such a simple need of pointing into an existing BPEL file, and notes that the code dealing with component types may be different from the BPEL engine code, so having to support multiple languages could be onerous.
 
Mike E also is concerned. He is also concerned that it reduces the portability of component types, if other expression languages are used.
 
Najeeb notes that since XPath is the default, people can still use that if they really want portability.
<Dieter Koenig>
you might do this: <service sca-bpel:implementationRef="..." ext:implementationRefQL="XPath_2.0" .../>
 
Discussion of whether the implementationRef should be an attribute or element.
Martin C out of time
 
Meeting adjourned.

[End of Minutes]
Formatted on 2009-01-14 at 15:39:52 GMT-8


Minutes formatted by Schreiber, a collection of XSLT stylesheets by Bob Freund modeled after David Booth's scribe


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