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: Raw log of 2008-01-10 concall


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


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