Minutes
Approval of 2008-11-20 minutes
Minutes from Nov 20 2008 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>
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.
<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.
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.
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