[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw log of chat for 2008-01-17 telcon
anish: Agenda: 1. Roll Call http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/roster.php 2. Appointment of scribe Rotating list attached below 3. Agenda bashing 4. Approval of Jan 10, 2008 meeting minutes http://lists.oasis-open.org/archives/sca-bpel/200801/msg00011.html 5. Action items review http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/action_items.php #0016 Open an issue in SCA Assembly TC regarding agreement/conflict of default values in the CT file and the runtime Michael Rowley #0017 Open an issue in SCA Assembly TC regarding whether default values in the runtime are necessarily represented in the CT file Mike Edwards #0018 Incorporate resolution of issue 11 into the spec Michael Rowley #0019 Start an email discussion on issue 2, especially the distinction between 'how' a CT side file is located v. 'where' it is located Michael Rowley 6. OpenCSA Liaison Subcommittees recommendation for defining conformance targets and use of RFC 2199 keywords http://lists.oasis-open.org/archives/sca-bpel/200801/msg00015.html 7. Approval of latest Working Drafts Latest Working Draft: http://www.oasis-open.org/committees/download.php/26339/sca-bpel-1.1-spec-WD-04.doc 8. New Issues 9. Issue Discussion a) Issue 2 http://www.osoa.org/jira/browse/BPEL-2 TITLE: Does the spec allow a componentType side file SUBMITTED BY: Anish Karmarkar Email thread: http://lists.oasis-open.org/archives/sca-bpel/200710/msg00040.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00041.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00042.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00043.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00044.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00048.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00049.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00055.html http://lists.oasis-open.org/archives/sca-bpel/200711/msg00003.html b) Issue 15 http://www.osoa.org/jira/browse/BPEL-15 TITLE: Define Conformance Targets SUBMITTED BY: Martin Chapman c) Issue 1 http://www.osoa.org/jira/browse/BPEL-1 TITLE: support for BPEL4WS 1.1 SUBMITTED BY: Martin Chapman d) Issue 14 http://www.osoa.org/jira/browse/BPEL-14 Title: Allow sca-aware processes to specify everything that can be specified in a CT side file Submitted by: Anish Karmarkar e) Issue 16 http://osoa.org/jira/browse/BPEL-16 TITLE: Ambigous Service Resolution SUBMITTED BY: Dieter Koenig 10. Next weeks call (may conflict with SCA Policy F2F) 11. AOB anish: Agenda: 1. Roll Call http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/roster.php 2. Appointment of scribe Rotating list attached below 3. Agenda bashing 4. Approval of Jan 10, 2008 meeting minutes http://lists.oasis-open.org/archives/sca-bpel/200801/msg00011.html 5. Action items review http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/action_items.php #0016 Open an issue in SCA Assembly TC regarding agreement/conflict of default values in the CT file and the runtime Michael Rowley #0017 Open an issue in SCA Assembly TC regarding whether default values in the runtime are necessarily represented in the CT file Mike Edwards #0018 Incorporate resolution of issue 11 into the spec Michael Rowley #0019 Start an email discussion on issue 2, especially the distinction between 'how' a CT side file is located v. 'where' it is located Michael Rowley 6. OpenCSA Liaison Subcommittees recommendation for defining conformance targets and use of RFC 2199 keywords http://lists.oasis-open.org/archives/sca-bpel/200801/msg00015.html 7. Approval of latest Working Drafts Latest Working Draft: http://www.oasis-open.org/committees/download.php/26339/sca-bpel-1.1-spec-WD-04.doc 8. New Issues 9. Issue Discussion a) Issue 2 http://www.osoa.org/jira/browse/BPEL-2 TITLE: Does the spec allow a componentType side file SUBMITTED BY: Anish Karmarkar Email thread: http://lists.oasis-open.org/archives/sca-bpel/200710/msg00040.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00041.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00042.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00043.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00044.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00048.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00049.html http://lists.oasis-open.org/archives/sca-bpel/200710/msg00055.html http://lists.oasis-open.org/archives/sca-bpel/200711/msg00003.html b) Issue 15 http://www.osoa.org/jira/browse/BPEL-15 TITLE: Define Conformance Targets SUBMITTED BY: Martin Chapman c) Issue 1 http://www.osoa.org/jira/browse/BPEL-1 TITLE: support for BPEL4WS 1.1 SUBMITTED BY: Martin Chapman d) Issue 14 http://www.osoa.org/jira/browse/BPEL-14 Title: Allow sca-aware processes to specify everything that can be specified in a CT side file Submitted by: Anish Karmarkar e) Issue 16 http://osoa.org/jira/browse/BPEL-16 TITLE: Ambigous Service Resolution SUBMITTED BY: Dieter Koenig 10. Next weeks call (may conflict with SCA Policy F2F) 11. AOB anish: Chair: Sanjay Patil anish: Meeting: OASIS SCA BPEL TC telcon anish: Date: 17-Jan-2008 anish: Scribe: Ivana Trickovic Ivana Trickovic: agenda accepted Ivana Trickovic: Minutes of Jan 10, 2008: approved Ivana Trickovic: Action item #16: Done Ivana Trickovic: Action item #17: It is issue 38 in the Assembly TC. Done Ivana Trickovic: Action item #18: Done Ivana Trickovic: Action item #19: Done Ivana Trickovic: Open CSA Liaison Sanjay: LSC recommendation: Sanjay: Conformance targets can be categorized into 1) document artifacts (or constructs within them) that can be checked statically. 2) SCA runtimes, which we may require to exhibit certain behaviors. We recommend that each TC write its specifications to: 1. Reword the specifications using RFC 2119 keywords. 2. For each appearance of a 2119 keyword, specify the document, construct or runtime behavior that is being constrained. Ivana Trickovic1: MikeE: motion to move with the recommendation Ivana Trickovic1: Charlton: seconded Ivana Trickovic1: motion passed anish by approval, u mean accepting it as a CD, right? Ivana Trickovic1: Latest Working Draft Ivana Trickovic1: Latest Working Draft: http://www.oasis-open.org/committees/download.php/26339/sca-bpel-1.1-spec-WD-04.doc Sanjay: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/download.php/26773/sca-bpel-draft-1.1-spec-WD-05.doc Ivana Trickovic1: MichaelR: Motion to accept WD #5 as CD Ivana Trickovic1: Dieter: seconded Ivana Trickovic1: no discussion on the motion Ivana Trickovic1: no objections Ivana Trickovic1: motion passed Ivana Trickovic1: Dieter: Rename the document to CD Ivana Trickovic1: No new issues Ivana Trickovic1: Issues Discussion Ivana Trickovic1: Issue #2 Ivana Trickovic1: Anish: There are 4 sub-issues: Ivana Trickovic1: 1) how/where the CT side file is found/located 2) extend the /componentType/service and componentType/reference syntax to include partnerlinks (providing the ability to override defaults) 3) compatibility between CT side file and introspected CT. This is more of an assembly issue, but we need to agree on how defaults are treated. 4) Allow the same info to be specified in a side file as well as inlined. This would require new BPEL extensions for service/refs a la multirefs and properties. Ivana Trickovic1: MichaelR: Multiple side files is not at issus. It could be restricted by saying that there must be exactlly one Ivana Trickovic1: MichealR: Regarding #2: we probably do not want to have PLs in component type Ivana Trickovic1: MichaelR: Regarding #3: This is an assembly issue. Ivana Trickovic1: MichaelR: Regarding #4: agree to address it Sanjay: http://osoa.org/jira/browse/BPEL-14 Ivana Trickovic1: Sanjay: Regarding #1: Issue #14 inlcudes this aspect Ivana Trickovic1: correction: Sanjay: Regarding #4: Issue #14 includes this aspect Ivana Trickovic1: Stick to #1 Ivana Trickovic1: Action item: Anish to open a new issue for #2 Sanjay: Michael Rowley's proposal: Sanjay: Michael Rowley wrote: > > The assembly spec currently says: "The location of the component type > file depends on the type of the component implementation: it is > described in the respective client and implementation model > specification for the implementation type." > > In my opinion, the SCA BPEL spec should define _how_ to find a component > type side file for a BPEL process, rather than _where_ to find them. > This is based on the fact that we don't typically use locations to refer > to XML definitions. <implementation.bpel> and > <implementation.componentType> both refer to their implementations by > QName, not by a location. > > Therefore, I think that we should say that SCA finds the ComponentType > for a BPEL process named "foo:bar" by finding any ComponentType document > that has <implementation.bpel qname="foo:bar">, wherever it might be > within the contribution. > Michael Rowley: If <implementation.bpel> is not present, then the component type has to have a contribution URI that is identical to the contribution URI except that the extension has to be changed to ".componentType". Michael Rowley: s/except/of the process, except/ Alex Yiu: +1 to Michael's latest suggestion Alex Yiu: question: where to get the latest XSD file for componentType definition? Mike Edwards: this seems over complex to me Mike Edwards: I dont see a good benefit Michael Rowley: I agree -- <implementation.bpel> should just be required. anish: this would simplify this, but i'm still concerned by the portability issue Mike Edwards: +1 Anish anish: s/by/about/ Mike Edwards: and "portability of skills" matters too Dieter Koenig: requiring <implementation.bpel> sounds good to me Ivana Trickovic1: MichaelR: Motion: Michael Rowley: CA finds the ComponentType for a BPEL process named "foo:bar" by finding any ComponentType document that has <implementation.bpel qname="foo:bar">, wherever it might be within the contribution. While the assembly specification allows <implementation.bpel> to be absent, for SCA BPEL, the component type MUST include an <implementation.bpel> element. anish: s/CA finds/SCA finds/ Mike Edwards: This looks more complex Ivana Trickovic1: MichaelR: Motion to accept this as resolution for issue #2 Ivana Trickovic1: Charlton: seconded Martin C: is it really a MUST Martin C: ? Michael Rowley: y Ivana Trickovic1: anish: Still concerned with the portability issue Dieter Koenig: replace <implementation.bpel qname="foo:bar"> by <implementation.bpel process="foo:bar"> Ivana Trickovic1: The discussion about issue #2 to be continued. Ivana Trickovic1: Sanjay: Any further discussion on the motion Ivana Trickovic1: No discussions Mike Edwards: at the moment I'd vote against Ivana Trickovic1: MichaelR: Move to table the motion Ivana Trickovic1: Chalton: seconded Mike Edwards: +1 to table Ivana Trickovic1: No objections Ivana Trickovic1: Sanjay: Next week is Policy TC f2f. Do you want to cancel next week's concall? Ivana Trickovic1: Charlton: seocnded Ivana Trickovic1: no concall next week Mike Edwards: bye Alex Yiu: bye Ivana Trickovic1: meeting adjourned Ivana Trickovic1: byeR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]