anish: Scribe: Dieter Koenig

anish: ScribeNick: Dieter Koenig

Dieter Koenig: 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 Dec 13, 2007 meeting minutes Raw transcript: http://lists.oasis-open.org/archives/sca-bpel/200712/msg00042.html

5. Action items review http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/action_items.php

6. New issues None.

7. Issue Discussion

a) Issue 11 http://www.osoa.org/jira/browse/BPEL-11 TITLE: BPEL variable initialization and SCA properties SUBMITTED BY: Mark Ford Additional Emails: http://lists.oasis-open.org/archives/sca-bpel/200712/msg00027.html http://lists.oasis-open.org/archives/sca-bpel/200712/msg00025.html

b) 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

c) Issue 15 http://www.osoa.org/jira/browse/BPEL-15 TITLE: Define Conformance Targets SUBMITTED BY: Martin Chapman

d) Issue 1 http://www.osoa.org/jira/browse/BPEL-1 TITLE: support for BPEL4WS 1.1 SUBMITTED BY: Martin Chapman

e) 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

8. AOB

Dieter Koenig: agenda accepted

Dieter Koenig: minutes of 2007/12/13 approved

Dieter Koenig: no pending action items

Dieter Koenig: no new issues since last call

Dieter Koenig: next agenda item: issues

Dieter Koenig: issue 11 - http://www.osoa.org/jira/browse/BPEL-11

Dieter Koenig: clarification sent to mailing list - see mail from mike edwards

anish: http://lists.oasis-open.org/archives/sca-bpel/200712/msg00042.html

anish: Michael Rowley: If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration.

Michael Rowley: If the variable has an initialization from-spec then that becomes the default value for the variable in cases where the SCA component does not provide a value for that property. If a value is provided for the property, the initialization from-spec is not evaluated.

If the from-spec is a literal value, where it has the following form:

<from><literal>literal value</literal></from>

then the literal value will be represented as the default value in the component type for the process. Any other kind of initialization from-spec will not be represented in the component type. However, even though the other kinds of initialization from-spec are not represented in the component type, they would still be computed and used as the default value for the property when the component does not provide a value for that property.

Alex Yiu: Michael Rowley: If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration.

Alex Yiu: [there is one more statement from the last chat session from Michael Rowley ... ]

Dieter Koenig: mark ford: bpel is treated differently than java

Dieter Koenig: mark ford: alternatively, one can do bpel initialization first, then modify values using properties

Michael Rowley is in a conflicting meeting, but will leave it to join this call, if there is some specific need for him.

anish mikeR, we are discussing issue 11

Michael Rowley: \me, should I join?

anish if you can, that would be good

anish esp. since you have a proposal

anish that we are discussing

Michael Rowley: \me will do

Michael Rowley: wrong slash

anish: Chair: Anish Karmarkar

anish: Agenda: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/event.php?event_id=16236

anish: Meeting: OASIS SCA BPEL TC Teleconference

anish: Date: 10 Jan 2007

Dieter Koenig: mark ford: when should the property assignment take place: before/during/after bpel variable init

Dieter Koenig: to be consistent with java, it should be after variable init

Mark Ford: should be after the scope's initialization of its variables

anish: mike's wording: "The componentType of a component MAY contain a default value for any property declared by the implementation. However, the implementation MAY have a property which has a default value that is NOT represented in the componentType. "

anish i see u in the Q alex.

Dieter Koenig: alex yiu: bpel implementation and component type may get out of sync

Dieter Koenig: mike rowley: according to the assembly spec, component types must remain "compatible"

Mike Edwards: as Assembly Chair - I agree that the matter of the meaning of the componentType is an Assembly problem

Dieter Koenig: mike rowley should sca-asm open an issue in order to define "compatibility"

Dieter Koenig: action item: open an issue in sca-asm

Dieter Koenig: action item for mike rowley -- open sca-asm issue for defining "compatibility"

anish: Action: mikeR to open an issue regarding agreement of default values in the CT file and the runtime

Dieter Koenig: mike rowley: move to resolve issue 11 with the proposed wording

anish: Action: mikeE to open an issue regarding whether default values in the runtime are necessarily represented in the CT file

Dieter Koenig: mark ford: change wording to reflect the point in time of the sca property assignment to a bpel variable

anish: Here is the proposal again in full:

anish: If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration.

If the variable has an initialization from-spec then that becomes the default value for the variable in cases where the SCA component does not provide a value for that property. If a value is provided for the property, the initialization from-spec is not evaluated.

If the from-spec is a literal value, where it has the following form:

<from><literal>literal value</literal></from>

then the literal value will be represented as the default value in the component type for the process. Any other kind of initialization from-spec will not be represented in the component type. However, even though the other kinds of initialization from-spec are not represented in the component type, they would still be computed and used as the default value for the property when the component does not provide a value for that property.

If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration

Dieter Koenig: alex yiu: by default, bpel uses xpath as expression language which is side-effect free

Dieter Koenig: (one may have other expr languages in bpel)

Dieter Koenig: alex yiu: bpel variables are marked explicitly as being init'd by sca properties

Michael Rowley: Possible new form for the relevent sentence: "If a value is provided for the property, the initialization from-spec MUST be evaluated, but the value of the variable will be changed to the value specified for the property on the component immediately after the initialization is evaluated (before any following variable initialization from-spec is evaluated)."

Michael Rowley: If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration.

If the variable has an initialization from-spec then that becomes the default value for the variable in cases where the SCA component does not provide a value for that property. If a value is provided for the property, the initialization from-spec MUST be evaluated, but the value of the variable will be changed to the value specified for the property on the component immediately after the initialization is evaluated (before any following variable initialization from-spec is evaluated).

If the from-spec is a literal value, where it has the following form:

<from><literal>literal value</literal></from>

then the literal value will be represented as the default value in the component type for the process. Any other kind of initialization from-spec will not be represented in the component type. However, even though the other kinds of initialization from-spec are not represented in the component type, they would still be computed and used as the default value for the property when the component does not provide a value for that property.

If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must be specified on the component type property declaration.

Dieter Koenig: mike rowley: (immediate replacement is different from java but fits better with bpel)

Dieter Koenig: mike rowley: moves to accept resolution for issue 11 with the modified wording (removing the first sentence which is duplicate)

Dieter Koenig: alex yiu: seconds

Dieter Koenig: issue 11 resolved without objection

anish: Action: MikeR to incorporate issue 11 resolution in the spec

Dieter Koenig: next agenda item

Dieter Koenig: Issue 2 http://www.osoa.org/jira/browse/BPEL-2

Dieter Koenig: mike rowley: sca-bpel should specify *how* component types side files are located

Dieter Koenig: anish: component type is tightly coupled to an implementation

Dieter Koenig: <continue discussion on mailing list and in next week's call>

Dieter Koenig: AOB?

Dieter Koenig: meeting adjourned

anish: Action: MikeR to start an email discussion on issue 2, especially the distinction between 'how' a CT side is located v. 'where' it is located