[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw notes from TC call of Dec 11
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 Room information was updated by: anish Dial-in: 1-888-967-2253 +1-650-607-2253 +61-2-8817-6100 +44-118-924-9000 Meeting ID: 877770 Meeting password: SCABPEL (7222735) anish: Date: 2008-12-11 anish: Chair: Sanjay Patil Michael Rowley: Acting as scribe. Michael Rowley: Agenda approved Michael Rowley: Minutes from Nov 20 approved. Michael Rowley: Anish & Sanjay can't make the next call. anish i'm going to be at another f2f anonymous morphed into Najeeb Andrabi Michael Rowley: 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 Michael Rowley: Approved unanimously (next call cancelled). Michael Rowley: Topic: CamelCase convention from LSC. Sanjay: Next conf-call: Jan 8th, 2009 Mike Edwards: Latest Assembly spec: Mike Edwards: http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/30358/sca-assembly-1.1-spec-cd01-rev4.pdf Mike Edwards: Section 1.3 between lines 63 and 77 Michael Rowley: Rowley wonders whether this convention is necessary to include in the specification text. Michael Rowley: 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. Michael Rowley: 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. Michael Rowley: 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: Michael Rowley moves to amend to remove the third bullet from that specification text. Michael Rowley: Najeeb seconds. Michael Rowley: 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. Michael Rowley: Sanjay checks for objections (none heard) for treating this as a motion and not a new issue. Michael Rowley: Amendment accepted unanimously Michael Rowley: Main motion accepted unanimously: Michael Rowley: Resolved: 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. Michael Rowley: Topic: Testing committee Michael Rowley: Sanjay asks if we should have a formal representative. Michael Rowley: No support expressed for the idea. Michael Rowley: 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. Michael Rowley: Sanjay believes there should be a formal representative and asks for volunteers. Michael Rowley: No volunteers came forward. Michael Rowley: Topic: New Issue: Additional Integrity Constraints for Component Type Side Files Michael Rowley: http://www.osoa.org/jira/browse/BPEL-25 anish: dieter, is this ready for resolution? Michael Rowley: Dieter moves Anish seconds to open issue BPEL-25. Michael Rowley: Approved no objection. 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." Michael Rowley: 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' Michael Rowley: 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. Michael Rowley: Motion carried without objection Michael Rowley: Topic: Issue 26 Michael Rowley: http://www.osoa.org/jira/browse/BPEL-26 anish: Resolution: Issue 25 is resolved with the proposal in JIRA anish: Resolution: 2008-12-18 call is canceled Michael Rowley: 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. Michael Rowley: Mike E also is concerned. He is also concerned that it reduces the portability of component types, if other expression languages are used. anish: Resoutio: Minutes of 2008-11-20 posted at http://lists.oasis-open.org/archives/sca-bpel/200812/msg00003.html approved anish: s/Resoutio/Resolution/ Michael Rowley: 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" .../> Michael Rowley: Discussion of whether the implementationRef should be an attribute or element. Martin C out of time Michael Rowley: Meeting adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]