Minutes WS Choreography WG F2F meeting, 17th to 19th November 2004

17th to 19th November 2004
Oracle Headquarters,
Redwood City, CA

Agenda:
	http://lists.w3.org/Archives/Member/member-ws-chor/2004Nov/att-0003/Nov_04_F2F_Agenda_-_0.txt

Proposals:

	Choreography lifeline section changes 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0049.html

	    PF's  comments - http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0055.html
	    Latest from Oracle: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0056.html

	Coordinated Choreographies Proposal 1 - coordination  attribute 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0065.html

	Coordinated Choreographies Proposal 3 - Multiple  Finalizers 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0066.html

	Coordinated Choreographies Proposal 4 - Finalize Activity 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0067.html

	Coordinated Choreographies Proposal 6 - Extending Choreographies 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0068.html
	
		Errata  to proposal: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0068.html

 	Qos and Bindings 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/att-0054/qos_bindings.pdf

	Boolean Conditions 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0058.html

 	Correlating separate channel instances to a choreography instance 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0062.html

Nascent proposals:

	Correlation Issue
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0052.html

	Multiple participants (List/array iterator) 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0046.html

	Text on clocks 
	-  latest at http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0042.html

	Isolation levels
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0011.html 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0036.html

	Issue 901- Proposal on WS-Chor dependencies 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0040.html

	Raise/Throw (aka choreology proposal 2): 
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0057.html

	Timeout on interact and exceptions
	http://lists.w3.org/Archives/Public/www-archive/2004Nov/att-0025/Timeout_exception.pdf

Goals:
	1. To close all major architectural issues for CDL V1
	2. To have precise editing instructions for last call document
	3. Agree plan beyond last call

Wednesday 17th Nov 2004

*** Roll Call ***
Martin Chapman		co-chair
Steve Ross-Talbot 	co-chair
Yves Lafon		W3C staff contact

Monica Martin, Tony Fletcher, Bob Haugen, Peter Furniss, Charlton Barreto, Jeff Mischkinsky, 
Nickolas Kavantzas, Abbie Barbir, Gary Brown

*** Appointment of scribes ***
Tony, Abbie, Charlton, Yves, ???????

Note: Tony scribed from this point 

*** Minutes of last meeting ***
 	9th November 2004
	http://lists.w3.org/Archives/Member/member-ws-chor/2004Nov/att-0010/MeetingMinutes20041109-0.txt
	
	One comment from Steve.  Steve could not find the issue for his action, so he has created a new issue. 
	Tony motioned and Abbie seconded and the minutes were approved unopposed.

*** Agenda Changes ***
	Multiple participants: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0043.html
	Correlating channels (issue 944) http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0052.html
	Text on clocks: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0042.html

*** Action Item Review ***

Actions (from 9 November 2004)
	ACTION 1: Take the TWIST example we're working on, add part of the flow what can go wrong, see what happens when things go wrong.
	DONE: Steve has done now and will send out tonight.  Bob is also working on this, but waiting for a resolution on the instance issues. 

	ACTION 2: Chairs to sort out examples work. 
	PENDING not high priority

	ACTION 3: on Martin to propose text on clocks (Issue 885). 
	DONE already.

	ACTION 4: on the chairs to discuss part 2 of the specification.
	Talk about future plans at this face-to-face.

	ACTION 5: Martin to produce UML model of WS-CDL for the editors to include in spec.
	Martin said he will start doing this during the editing period.

	ACTION 6: Steve to tidy up proposal on locally defined variable (issue 691) and send (including Schema changes) to the editors. 
	To be done

	ACTION 7: Gary to see if he can put together a modified Nick proposal to include the relaxed fault handling 
	DONE (last week)

	ACTION 8: Nick's Lifeline proposal to be on the agenda next week 
	DONE (last week)

	ACTION 9: Editor's look at clarification items in the agenda in preparation for next week's call
	DONE

	New action:
	DONE - Steve has created issued 944

*** Proposals and Issues ***

Red flag issues 
	Multiple participants - refer to issue 938 
	There are two sub issues here: 
		1) How to handle a variable number of participants where the number is only determined 
		   as the choreography description instance evolves. 
		2) How to handle concurrent evolution in a choreography of a variable number of participants. 

Nick: another use case is sending variable number of requests (and receiving a variable number of responses) to a single participant/role.  Nick said he would like to see this issue resolved before last call and has been thinking about it for more than two years. 
Steve agrees - need lists and arrays. 
Nick: there is an issue about how and where the loop counter gets updated. 
Nick has a partial proposal for 'concurrent'. 
Martin: XML schema supports an unbounded number of the same element, but no way of referencing.  Some other XML things tackle this issue such as XPath 2, X Query, Xpointer, SOAP encoding, RDF.
It was suggested that there were a number of options.  We could punt the issue, pick one of the above specifications, orwe could define a function. 
Punt will involve adding a paragraph of text to point out the issue - could document as an issue and solve after last call. 
Abbey said he was in favour of punting. 
Default position is to have 'punting' text. 
Those who care about it should discuss and put forward a proposal.  This might involve, for instance, Tony, Peter, Bob, Gary and Steve. 

ACTION: Martin to produce 'punt' text. 

Concurrent work units issue 938
Add an attribute to workunit named concurrent. 
It was noted that the parallel construct gives a fixed number of things running concurrently.  This new construct is to give a variable number of things running concurrently, where the number is only fixed during the evolution of the choreography Instance. 

Gary and Steve pointed out the need to be careful with the concurrent condition especially if it involved a variable number.  See Gary's e-mail. 

Correlating channels
See Gary's e-mail and minutes for 9th November 2004 and issue the 944. 
Asserted that on wire cannot tell one channel from another.  This is a problem if the system is running several choreographies concurrently.  Nick thinks this is an important problem, but needs further exploration of the different use cases. 

Looked at proposal from Gary.  Which use cases should we try to cover for last call.  Gary explained his 'pre-proposal'.

May need to use information from one session on another session. 
Use cases: multiple instances of a choreography. 
Introduce the notion of a sessionIdentity element which has sub elements of one or more tokens that point to some part of a message that is exchanged.  Use a Channel instance instead?  Need to correlate this with the choreography instance. 
It was noted that we already have identity in a channel type which also has tokens as sub elements. 

This scheme appears to be exactly the same as correlation sets in BPEL. 
Evolve examples 1 and 2 in Gary's proposal.  Example 2 has more than one sessionIdentity in it. Steve said he and Gary could not produce complete text for this week.  Put as a known issue and maybe some proposal will appear in the next week or two and if so the group will have to deal with it. 

*** Bugzilla issues ***
Yes means we need to talk about the issue at this meeting. 
No means we will not need to talk about the issue at this meeting. 

901  Yes, isolation is on the agenda 
913  Yes 
916  Solved - needs to be closed 
923  Closed 
927  Closed 
928  Yes on discussion list 
929  Yes on as the Boolean question 
930  Yes 
EDITORS 937  Editorial 
938  Yes red flag item 
939  Yes on as Boolean question 
EDITORS 943  Editorial 
944  Yes red flag item 
EDITORS 945  Editorial 
946  Fixed in new document 
947  Yes 
464  Yves will do, but yes Nick needs talk about one thing. 
489  Yes 
490  No 
506  Yes as the correlation issue 
554  Yes - Charlton's proposal 
556  Yes - Charlton's proposal 
557  Duplicate of 556 
EDITORS 561  No - but need to do the editorial work 
EDITORS 563  Editorial 
565  Closed? 
PRIMER 566  Yes part - part for a primer 
615  Fixed - review in the specification 
621  Fixed - close? 
662  Done? Check the specification text 
663  Martin actioned 
664  Martin again - for the primer 
665  Done but no language for to 'concrete layer' has been included. 
667  Closed pending review of current text 
PRIMER 747  Primer 
555  Charlton's proposal 
623  Done in the latest draft? Review latest document. 
EDITORS 683  Editors 
691  Action Steve 
693  Closed 
721  No editorial to put in a new section - TBD and fil after last call
EDITORS 724  Editorial and on the list 
PRIMER 741  Examples and primer 
753  Close no action 
782  Closed
792  Close no action
846  Yes - on list 
850  Duplicate of 721 
855  Closed
870  Closed 
872  Close - put in part 2 
885  Martin's text proposal 
898  Close - partially fixed 
899  Done - review 
274  No - leave open? 
487  Done close - review text 
624  No - Requirements document 
661  Yes on list

Note: Abbie scribed from this point

<mchapman> minutes 9th nov: http://lists.w3.org/Archives/Member/member-ws-chor/2004Nov/att-0010/MeetingMinutes20041109-0.txt

<mchapman> multiple participants: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0043.html

<mchapman> correlating channels (issue 944) http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0052.html

*** TOPIC: text on clock: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0042.html ***
current text is Clock synchronization is unspecified in the WS-CDL technical specification and is considered design-specific. In specific environments between involved parties, all parties may be synchronized to second time boundaries. However, finer grained time synchronization within or across parties, or additional support or control are undefined and outside the scope of the WS-CDL specification
Martin: Personally does not like the text
<gritzinger> The text is a merge of Yves' and Monica's contributions.
<gritzinger> I recall that Martin thought Yves' version was acceptable. Should we use Yves' version?
<Yves> we are amending it
abbie objects to the text
proposed text from Abbie: CDL assumes that there are mechanisms for clock synchronizations during interactions. However, CDL does not spcify such mechanisms and their granularity.
<mchapman> other suggestions for primer:
DECISION: leave text to primer (or was it)

<mchapman> Clock synchronization is unspecified in the WS-CDL technical specification and is considered design-specific. In specific environments between involved parties, all parties may be synchronized to second time boundaries. However, finer grained time synchronization within or across parties, or additional support or control are undefined and outside the scope of the WS-CDL specification.
<mchapman> or
<mchapman> >CDL does not put any assumption on the clock synchronization mechanisms
<mchapman> >between involved 
<mchapman> >parties. In some environments it 
<mchapman> >is assumed that all parties are 
<mchapman> >synchronized on second 
<mchapman> >boundaries. Applications requiring finer grained clock
<mchapman> >synchronization will require additional support which is undefined 
<mchapman> >in this specification.

martin did post the text for primer

discussing boolean conditions
ACTION: Boolean resolution: tony to clarify the text if possible

*** TOPIC: QoS and Bindings  ***
Need to tell wsdl wg that F&P are needed, no action to address this in the specification
http://www.w3.org/Bugs/Public/show_bug.cgi?id=554
<Yves> ACTION: editors to add support to wsdl 1.1 in section 1.4 as constrianed with ws-i basic profile for compatibility
EDITORS NOTE: add to section 6 based on these requirement cdl should be composable with btp, wst WS-CAF
<charlton> see section 2 in BPMN 1.0 spec (pg. 24)
raise issue, look at BPMN and the possibility of a laison etc.
issue 566 text on wsdl messages
ws addressing should be mentioned in cdl as a member submission
<charlton> ws addressing (W3C Member Submission 10 August 2004)
<charlton> (it is referenced in the proposal :-))

ISSUE 566: "Dependency to other technologies - Section 3.5.6"
resolution: close with the text: The editors feel that the proposed statement is out of context for section 2.4.5
but will reconsider it if a more appropriate section of the document is
suggested. Perhaps the proposed statement belongs in the Primer.

ISSUE 464: "CDL - Flesh out section on structured references" -  is closed because it is the reference to wsdl 1.1 as constrained by the basic profile

ISSUE 691: "Locally defined variables: Structure: How are locally  defined variables defined when they are not consistent between roles that participate in the choreography?"
no change (see later in minutes - becomes editorial based on accepted proposal)

NOTE TO SRT: Factor in Tony's stuff at the appropriate point (- must be afternoon).

TOPIC: PARTICIPANTS - variable scoping for a participant with differrent roles
ACTION: editors to change the text to add variables of the same name and clarify the text, variable names that are same can be shared within a  participants with different roles
above is done in section 2.3.2
tony will redo the text
this has also to go into the variable section

TOPIC: RAISE/THROW "Raise Exception activity (Re: Preface to Coordinated Choreography proposals)"
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0057.html
do an amendment to the text, make sure that there is a new line/paragrapgh for the **the assign
DECSION: PROPOSAL ADOPTED WITH THE ABOVE AMMENDMEND

CHECK ACTIONS HERE:
<RRSAgent> ACTION: Boolean resolution: tony to clarify the text if possible [1]
<RRSAgent> ACTION: editors to add support to wsdl 1.1 in section 1.4 as constrianed with ws-i basic profile for compatibility [2]

*** TOPIC: TIMEOUTS/EXCEPTIONS "Timemout Exception Proposal" ***
Context for this proposal: Earlier in the year we adopted both deadline and duration timeouts on interacts. 
Unfortunately CDL does not contain any mechanisms to detect whether a timeout actually occurred or not! 
Attached is a proposal that fixes this.
http://lists.w3.org/Archives/Public/www-archive/2004Nov/att-0025/Timeout_exception.pdf
section 1.1.1 of the above proposal
time out definition: <timeout time-to-complete="xsd:duration"|time-to-complete="xsd:deadline"
NOTE TO SRT: Check against Yves HTML doc
fromRoleRecordReference=ncname
toRoleRecordReference=ncname/>?
tony proposed to split timeout into individual "from" and "to" timeouts
DECISION: PROPOSAL (above) FAILED
peter: can u have an interact that implies a request and send a responce
yes
yes, based on the current text
peter: need text when clock stop/start
martin start when interaction start/ finishes when interaction finishes
see proposal for more text
charlton: xsd:datetime
EDITORS NOTE: record need to change xsd:deadline to xsd:datetime
<Yves> ACTION: editors to fold in http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0042.html - "Revised Proposal on a WS-CDL supplied Duration timeout function" into working draft
<charlton> this is the revised version we agreed to incorporate to section 2.4.3.1
We need to allow variables into timeouts
<charlton> we should be able to pass in variables an XPath expression which is evaluated therein to return the value
steve: variables should be defined in both roles
we have changes time to complete to xpath expression that must evaluate to duration or datetime
charlton: proposal need to be consistent in the text
NOTE: NO DECISION WAS REACHED ON Timeout Proposal final text

Thursday 18th Nov 2004

Note: Yves scribed from here 
peter: what do you do with a given set of records referenced from a single place?
peter: i can set an exception type and not cause an exception
peter: that list of records s/b constrained such that only one exception can be thrown from it
martin: what happens when you have multiple records, and an exception
+is encountered?
peter: in the case where there are records, setting more than one
+exception type, why is it sort of a hidden decision, rather than something
+more explicit as multiple exchange?
right, nick
peter: section 2.5.2.3 - "when two or more record elements..."
+paragraph
martin: the issue is that, in general, if there are two exception
+records, it is non-deterministic which one will be pursued
martin: we don't know which exception actually happened
peter: it is deterministic based on the trigger for the exception
peter: we have multiple exchange elements to handle multiple records
+throwing exceptions
nick: this isn't the same as having alternative recordings
nick: the exchange means you are moving information through the
+communication pipe, possibly exception info; the other is dealing with local
+information
nick: both mechanisms are needed
nick: we can have more than one response; if more than one exception
+response, we are declaring the intent of one these going back, but we don't
+know when it actually will be fired off
nick: e.g. receive-reply (bpel)
nick: there is additional activity between the receive-reply, which
+is modeled in bpel but not in chor
(nick is diagramming this on the whiteboard)
nick: no way to do as bpel does, to choose between multiple responses
nick: no way to decorate the endpoint as per bpel
peter: construct having multiple recordings of a response, such that
+if the recording happens, all responses are returned, and one (or more) of
+these can return exceptions
peter: we have multiple recordings - the use of it s/b that all of
+them apply
peter: doesn't fit throwing exceptions from this
nick: when you have causeException, the corresponding Role gets into
+Exception state
nick: single exit point from multiple recordings
nick: throwing an exception
martin: depends whether an exception is an interopt
srt: causeException is like saying "raise"
nick: not exactly
nick: it is more of a "may fire"
nick: current semantics - non-deterministic, serial
peter: records are just declared and registered with the exchanges
nick: except for timeouts
[charlton, if you have more above that... please send it again to the channel]
peter: PROPOSAL - change where timeout proposal fromRoleRecordReference="ncname", toRoleRecordReference="ncname" to instead each reference a list of ncnames
peter: PROPOSAL, CONTD - and have only one record raise the exception - remove "at most one record elements may be specified..."
martin: any objections?
nick: yes
nick: i agree with doing the list, and object to removing the "at most one record element may be specified..." rule
martin: who can live with not adopting this proposal?
(unmodified version - single ncname, keeping the rule)
5 for adopting peter's proposal, 1 for being able to live without it
martin: objections to adopting the proposal?
none - carried
ACTION adopt Peter's proposal, incorporate into the editor's draft
ACTION:  adopt Peter's proposal, incorporate into the editor's draft
DECISION: PETERS PROPOSAL ABOVE AS AMENDMENTS TO TIMEOUT/EXCEPTION IS ADOPTED

Note: Abbie scribed from here

*** TOPIC  LIFELINE  ***
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0056.html
"Choreography lifeline Proposal (was RE: Proposal: To remove the initiate flag on the Interation)"
martin: proposal w.r.t. lifeline - covers section 2.4.8 (p. 32-33)
martin: replace contents of 2.4.8 with paragraph in http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0056.html
nick: agree with Bob w.r.t. last mail he sent on this
martin: can't address this until we address related issues on agenda
martin: part this for now

ISSUE 691: "Locally defined variables: Structure: How are locally  defined variables defined when they are not consistent between roles that participate in the choreography?"
PROPOSAL ISSUE 691 REVISTED: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0066.html
martin: we agreed to this, it is only an editorial item
so SRT has to address this item for the tutorial/primer


*** TOPIC: Coordinated Choreographies Proposal 1 - coordination attribute ***
http://lists.w3.org/Archives/Public/publis-ws-chor/2004Oct/0065.html

bob: discussion on finalize activity, who in terms of what roles are able to say finalize, possibility of making finalize an element in itself so we can group multiple finalize statements, convenience
bob: finalize and element in itself - can enclose chors such that can confirm or cancel all finalizers
bob: minor elements - whether globalized triggers require coordination or not - prepared to withdraw statement from proposal (coordinated chor proposal 1)
bob: we came up with 3 possible interpretations of globalized trigger
bob: corrected version of proposal (coordinated choreo proposal 3?)
martin: to discuss each coord chor individually
martin: coord chor proposal 1
monica: submitted two editorial changes to proposal 1 - both accepted by bob
nick: only concern with proposal 1 - the moment we start getting into where the coord points are, we get into trouble because we have different opinions as to these issues
nick: requirements not spelled out; if it stays at high level i have no problem adopting it
<Yves> 4
nick: we shouldn't start discussing for LC the details for coord chor
nick: comfortable with all the other proposals as is
nick: proposals 3 & 4
martin: it may not be possible to fully align on coord chor for LC
martin: are these the correct and precise rules for coordination=true
yves: we can say these rules are up for discussion
monica: all these rules can be in an appendix and not normative
martin: what does that mean - it is an exercise for the implementor?
monica: it c/b optional, if there are specific areas that involve exceptions than we can talk about them specifically
martin: let's be vague at this stage ("...we are working on the details...") or ...
nick: we don't have alignment on basics of proposal 1 - that's what makes me uncomfortable
srt: we haven't had a response from the group on this
martin: do we want to put something that may be inconsistent in, or do we just want a placeholder for LC?
peter: these rules ought to be right
peter: strongly suggest we put the rules in, esp. since we have no known inconsistencies
martin: i think it's better to put these in and have people submit LC comments
martin: rather than leave it out and no one knows what we are looking at for coordinated chor
yves: should note all rules are subject to [change]
martin: similar to timeout - i propose we adopt proposal 1 as is - come back to it after lunch for 15 minutes to table amendments
DECISION: group agrees to this proposal as default. That is if no ammendments are adopted then this proposal will be deemed to have been accepted

*** TOPIC: Coordinated Choreographies Proposal 3 - Multiple Finalizers ***
<BobH> http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0066.html
monica: we need to be specific that name is distinct
tony: general rule that ncnames are distinct
monica: 2.4.4: "Change to:" section: "...each much be differentiated by a *distinct* name..."
monica: "Finalizers are particularly useful..." paragraph - without coordination mentioned here, it seems that this paragraph minimizes finalizers' usefulness
nick: this points to some of the rules of coor chor
looking at section 2.4.8
nick: do we know how the lifeline aspects of this written>?
martin: delegate binding-level responsibility to other specs
nick: use ws-addr for action, use soap/http/etc. headers for other features, and likewise delegate bindings to describe coord chor bindings
srt: key issues to resolve
srt: how to i bind to coord protocol?
martin: we set reqs for protocol - concrete level c/b dealt with through other specs
<abbie> help
<abbie> cdl is like abstract wsdl
peter: cdl is analogous to abstract wsdl - what there is not yet is an analogy for concrete wsdl
gary: reference impl - to show you're conformant to CDL spec - align=true, coordination=true are optional, not just defaulting to false
martin: what is wsdl doing about bindings
srt: we bind through wsdl
Jeff: there is wsdl that corresponds to cdl
Jeff: what about java?
ok, where are we on proposal 3?
no changes to this proposal
other than couple of editorials items and reference to a couple of things which refer to other issues: isolation and finalizers, 2.4.7. add for lifeline
martin: PROPOSAL TO REMOVE: "The finaliser workunits are enabled only after the Choreography..." paragraph in proposal 3
no objections
no other comments on proposal 3
martin: are we happy to adopt this and fold it into the document?
none opposed
DECISION: Proposal 3 was adopted subject to amendment above.
PROPOSAL: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0066.html
AMENDMENT: REMOVE: "The finaliser workunits are enabled only after the Choreography..." paragraph 


*** TOPIC: Corrected Coordinated Choreographies Proposal 4 - Finalize Activity ***
PROPOSAL: http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0003.html
ORIGINAL: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0067.html
<BobH> URL (PROPOSAL ABOVE) I sent is for corrected version, but corrections are only in example, not text
discussion around "choreographyInstance=xsd:string" in proposal 4
peter: is the only way of "running" in a chor, performing?
martin: yes
finalizing one's self - is it finalizing root?
martin: proposal 5 - need some text (peter will send it) w.r.t. finalizing at chor level
martin: 'type' it as XPath expression
<SRT> PROPOSAL (AMENDMENT 1): rename "choreographyInstance" to "subChoreographyInstance" 
<Yves> +1
for proposal 4, right steve?
DECISION: AMENDMENT 1 was adopted.

wg agrees to have peter provide amendment to proposal 5 over lunch
martin: who is in favour of doing this?
3 in favour, none opposed

DECISION: Peter to providea mendments to proposal 5 over lunch

*** TOPIC: subChoreographyInstanceId - text for choreology proposal 5 ***
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0072.html
reviewing Peter's text for proposal 5

salient phrase "is run(?) for the indentified inner Choreography"
<mchapman> Otherwise, it is required and the value MUST be different for each instance of the named Choreography which is performed. 
<mchapman>  If the performed Choreography can only be performed once within the enclosing choreography, the subChoreographyInstanceId attribute is optional.
candidate names for this attribute?
performanceId?
subChoreographyId?
subChoreographyInstanceId?
(s/subChoreographyId/subChoreographyInstanceId)
instanceId?
2
performanceId?
3
instanceId=3 & performanceID=3 (3 votes each)
bob: this may cause problems later on
<BobH> just plain instanceID is what may cause problems
correct
martin: does anyone object to choreographyInstanceId?
vote: agreed - rename subChoreographyInstanceId to choreographyInstanceId (AMENDMENT 2)
vote: adopt proposal as amended?
DECISION: Proposal to adopt AMENDMENT 2 (also see AMENDMENT 1) was accepted
ACTION: Peter to redraft proposal 5 as amended (AMENDMENT 2), change the schema as agreed; editors to incorporate amended text from Peter into spec

monica: back to text in proposal 4
martin: any changes to finalize activity?
martin: AMENDMENT 3: to have XPath expressions/xsd:string
monica: "...a choreography may have more than one finalize..." - why do we have this?
martin: this has been adopted as part of proposal 4
tony: may have more than one finalize for convenience - may want to hit it at one point or another in the chor
peter: several of these paragraphs which relate to catching dynamic rules
<SRT> Don't forget that the choreographyInstanceId on a perform is optional, i.e. a "?" is placed after it in the psuedo schema

nick: AMENDMENT 4 strike "...Choreography MAY have more than one finalize..."
nick: AMENDMENT 5 editorial - replace "inner" with "enclosed"
nick: for consistency
<Peter> AMENDMENT 7 For a single choreography instance performed in an enclosing choreography, only one finalize shall be invoked.

xxxxxxxxxx


martin: if have finalize - it is recommending that it be pulled
peter: 2nd paragraph - if have finalize, someone should be able to finalize it one way
<Gary> what about when a performed choreography is in a different package? why can the performed choreo not have a finalizer that is called
bob: if don't have explicit "chor is closed", implicit finalizer to close it
martin: so an inner chor that goes out of scope cannot have any finalizers called on it
martin: implies runtime checking :-)
<SRT> I havn't forgotten your question Gary. I shall seek an answer
martin: only a parent perform can invoke a finalize on its children, nothing outside that
martin: if A encloses B and C, nothing outside of A can call the finalizers on B and C
martin: two choices: either everything gets deinstalled, or we have implicit finalizers
<BobH> I don't agree with implicit finalizer, only with implicit close without firing any finalizers
nick: AMENDMENT 8  Proposed semantics - implicit close
martin: AMENDMENT 9 therefore, the second paragraphy should be "A Choreography SHOULD have at least one finalize element..."
(in proposal 4)
<BobH> If you change it to should, pps 2 and 3 could be merged into one
<Gary> can a finalizer finalize inner choreographies - so a top level finalizer could trigger the finalization of a hierarchy of inner choreographies?
<BobH> answer to Gary's question, yes, but each finalizer must explicitly finalize the next level down
<BobH> (if that made sense)
martin: AMENDMENT 10 Paragraph 2 is definitely now a SHOULD
<SRT> So Bob, you are saying that each finalizer chains based on naming the finalizers for each enclosed choreo all the way down the hierarchy?
<Gary> I think the term "enclosed" needs to be clear
<Gary> thats fine
<BobH> SRT and Gary - for example, in TWIST, finalizer for TradingService will finalize SellerA and SellerB, and Seller finalizers will finalize CreditA and B
<SRT> Section 2.5.3 may have the defn of enclosed (Peter thinks).
peter: 2.5.3 - immediately before the perform syntax - it defines enclosed chor
<SRT> 2.5.3 is fine for me
<SRT> Thanks Bob ;-)
<Peter> AMENDMENT 11 choreographyInstanceId text sent to email : http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0073.html
martin: why don't we add "enclosing choreographies whose finalizers are never invoked will never get finalized"
srt: a model (static) check
martin, srt: "finalizers which are never referenced in a finalized element are never invoked"
martin: chors can be closed without finalizers being invoked
"can be" or "may be"
peter: this occurs when the immediately enclosing chor has gone out of scope
<SRT> Not sure you can model check because the choreographyInstanceId's may not be determined statically.
martin: we agreed - A goes out of scope, B and C are implicity finalized
<BobH> not implicitly finalized, closed without finalization'
AMENDMENT 12 correction - A goes out of scope w/o explicit finalization of B and C, B and C are therefore NEVER finalized
and therefore closed without finalization
<SRT> Bob, can u draft text for this finalization and paste into IRC or email in?
<Peter> For a choreography instance performed in an enclosing choreography, at most one finalize shall be invoked.
<BobH> SRT, text for what?
<SRT> Not sure how to explain just yet .... Peter may well do it.
<BobH> I think we need to distinguish and name states of choreography life cycle, then all will become more clear
ACTION: Peter to consolidate the rules in proposal 4
DECISION: Peter to consolidate rules in proposal 4 including AMENDMENTS 1 through to 13 above

martin: we need to insert the sentence AMENDMENT 13 "the finalize activity may be used in the main body of a choreography, the finalizer block of a choreography, and/or the exception block of a choreography if defined"

martin: finalize a, finalize b vs finalize a & b
martin: finalize a, finalize b vs finalize a & b
srt: finalize multiple performs at once vs. finalizing each perform
srt: <finalize choreography="foo" /> is the minimal element
srt: whatever happens in the finalize stage for the enclosed chors - if in parallel, no contention for the enclosed chors, but for the enclosing chor
martin: proposed AMENDMENT  14- "The Finalize activity is used to enable one or more finalizers..."; changing finalize element to have element nested with a '+'
martin: "...you can have one or more finalizer references in a finalize activity..."
<SRT> FULL TEXT to that AMMENDMENT 14 (rewritten properly) should be "The Finalize activity is used to enable one or more finalizers in particular instances of immediately inner choreographies which have defined finalizers, and thus bring those choreographies to a defined conclusion"

nick: AMENDMENT 15 I propose to delete the three paragraphs starting with "The conditions under which a finalize is chosed is governed..."
monica: AMENDMENT 16 we need to make the preceding paragraph ("The optional attribute choreographyInstance...") needs to be made consistent
<BobH> finalizers are also enabled when their chor is successfully completed, how is that different from finalizer which actually invokes one?
correction: monica: AMENDMENT 16 we need to make the preceding paragraph ("The optional attribute choreographyInstance...") consistent
<BobH> from finalize which invoked one?
<SRT> I think that enabled is the wrong word and that the correct word for your question is "installed". Will check here.
<BobH> ok, as long as it's different
<SRT> Difference being that enabled replaces activated and this is consistent with work units.
srt: when a chor completes, a finalizer is "installed"
<SRT> I was correct
nick: finalizers are installed when the chor completes successfully
martin: they get deinstalled when the finalizer goes out of scope
martin: or when they are called (?)
we have agreed in principle to these changes as captured in the action and associated details 

*** TOPIC: Coordinated Choreographies Proposal 6 - Extending Choreographies ***
PROPOSAL: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0068.html
<m2> chapman: This is interesting but I've not seen others do this before.
<m2> Propose to move to next version.
<m2> Barbir seconds.
<m2> SRT: We share this concern. Is there anything specific in the proposal to cause this concern?
chapman: This is interesting but I've not seen others do this before.
Propose to move to next version.
Barbir seconds.
SRT: We share this concern. Is there anything specific in the proposal to cause this concern?
proposal 6
monica: should we punt on this indicating we need requirements?
srt: we can come up with plenty of requirements
<BobH> TWIST is requirements for one
and FIX?
i then would say it is as well
<BobH> BPSS transaction patterns
<SRT> I would say that this proposal is a sketch. It has no editing instructions and no precise instructions as to what changes in CDL (abstract syntax, schema and text). For this reason alone we cannot deal with it now. Good idea but timesout
martin: in very specific use cases, one can think of chors with interacts, extend them, use set of modifiers - where i set interact X, it is now X'
<BobH> change in CDL is simple and in proposal
abbie: union type
peter: inheritance with sex (two parents)
<BobH> change in CDL: <extends name=ncname/>
srt: change to syntax, schema and supporting text - we don't have something at this point that we can just hand off to the editors
martin: not convinced we're addressing a use case which we have identified
srt: i don't think lack of a use case is sufficient reason not to pursue this
monica: comment - other use cases exist which are not addressed by this proposal
monica: c.f. email sent to bob
<m2> You responded to my email about a child that is not derived from a parent (different use case).
abbie: propose to delay this to > 1.0?
<BobH> m2, that was a different meaning of parent:child rel, not same as extends
<Yves> (was http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0051.html )
peter: issue of reusability - 3 scenarios: end2end (e.g. TWIST scenario), sequential, and overlay (using the features of one chor, and now building on top of that for a more advanced protocol - which is why inheritance is part of the protocol)
peter: summary - of 3 kinds of reuse, the most interesting and useful is the third
peter: sequential has some virtues, end2end/edge2edge not as much
abbie: i see the benefits, but this needs to be debated further - let's look at it in a later version and not forget about it
can we address this in time? 
peter: we can address it before Dec 10
abbie: we need more time to debate it
martin: must be addressed by friday
need time limits on window of addressing this....
martin: we have 3 conf calls before LC
(between now and LC)
martin: ~3 weeks from now we need to have an LC edition - and we need time for this t/b reviewed
srt: a major impact of this is editorial
tony: we didn't write explicit editing instructions
abbie: even if we did, we have to know the consequences in order to be comfortable with this
<BobH> I agree with abbie, consequences are more important than editorial changes
nick: i'm feeling we're dumping a lot of stuff at this last F2F before LC without fully understanding their impact
srt: we also h/t/b to show that chor c/b used in practice - e.g. w/o session keys, we cannot deliver practical functionality to a customer
srt: if we treat this proposal, and say, session keys, identically, we have to make a decision on them by the end of this F2F
martin: i feel it is the content of this proposal that is making people uncomfortable; it is at the conceptual level; different from session keys because that is more concrete and its impact is better understood
martin: let's defer this proposal, put a note in our LC doc, TBD, that this is a proposal, we don't believe it will have a major architectural impact on CDL
agreed
DECISION: Add a note to the LC doc regarding extending choreographies proposal to the status section: indicating that we are working on this proposal, it is not finalized as of yet, and we do not believe it will have a major impact on the architecture
ACTION: On Editors- add a note to the LC doc regarding extending choreographies proposal to the status section: indicating that we are working on this proposal, it is not finalized as of yet, and we do not believe it will have a major impact on the architecture


*** RETURN TO TOPIC: Coordinated Choreographies Proposal 1 - coordination  attribute  ***
	http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0065.html
proposal 1: we have a default - adopt this text as TBD, nick has comments/amendments forthcoming for it
nick: any exercises, issues with mixing and matching coord chors?
peter: no
nick: if i have A coord=true, B coord=false, C coord=true
peter: B won't be seen but A and C will



tony: if basically the coord is completely successful, it is pretty much aligned - completely different if have one failure
again, proposal 1 is at http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0065.html
the parties of enclosed chors will be coordinated if the have coord=true
martin: we should add this language to proposal 1
peter: a perform chor may not be coord within a larger chor
peter: coord of an enclosed chor is defined by that chor and does not imply the coord of its enclosing chor
martin: non-transitive coord
martin: sub chor coord is independent of the parent
nick: no auto agreement of outcome from parent to children
nick: but, finalize still c/b called
nick: coord should state guarantees/QoS from agreement
peter: we have that 1.2.1 and 1.2.2
bob: we need some clarification; i will take that on
martin: from here on we need to address reasonable precise changes to text
<Peter> add to end of para before 1: Coordination of choreography applies only to the agreement of how that choreography ended; there is no necessary implication
bob, do you want to take this on as an action?
nick: 1.3.3 - "an exception" 
<Peter> ... on the coordination of any enclosed choreography: this is determined by their own coordination attribute.
<SRT> PROPOSED AMENDMENT 17 FROM NICK: The optional coordination attribute specifies whether a Choreography
<SRT> guarantees that all involved roles agree on how it ended: that is, if
<SRT> the Choreography ended successfully or suffered an exception, and if the
<SRT> Choreography specified more than one Finalizer, which Finalizer
<SRT> happened. To The optional coordination attribute specifies whether a Choreography
<SRT> guarantees that all involved roles agree on how it ended: that is, if
<SRT> the Choreography **completed** successfully or suffered an exception, and if the
<SRT> Choreography specified more than one Finalizer, which Finalizer
<SRT> happened. (I think)
nick: it is possible to have two different exceptions thrown from two different roles?
bob: it is possible for some roles to end in an exception state and others not, and for the enclosing chor to complete successfuly
nick: should enclosing chors throw exceptions to enclosed chors?
peter: current candidate protocols can guarantee that the parties are aware of the unhappy result, but not the details
nick: all top level exception work units must have the same type exception as children in order to trigger that the children exceptions will fire
nick: if coord=false, we cannot police this?
martin: what do we need to change in the proposal?
peter: difficult to get a binding that guarantees that - CDL assumes everything is known everywhere; temporary misalignment can be hidden but not entirely - we can say that everyone experiences an exception, but not the same exception
nick: two different exceptions - one can go to one WU, the other to another WU
martin: if align=true, it creates a problem
peter: we should not perform interacts in exception blocks - even though they are allowed - because we have gone wrong and don't know where the other guy is
peter: if we want to discriminate in an envt where the fault may not occur everywhere, we need to track it separately
martin: different endpoints can detect different exceptions - we have to coordinate somehow
peter: how can B know what happened to A if it hasn't receive a message concerning it?
nick: idea is that you can use exception block as a way to checkpoint a chor
srt: how do you prevent that you get an exception in A, and while it is experiencing this error, how do you prevent B from experiencing the [same] exception?
srt: describing that it shouldn't happen and preventing it are two different things
nick: this can potentially be a show stopper for LC
[NOTE] How was this resolved?
abbie seconds it
reviewing section 2.4.9.1
nick: offending statement: line 17: "An Exception WU MAY have a guard condition..."
martin: when coord=false, A can enter an exception, with B not
nick: you cannot police that both A and B will have appropriate exceptions with this line 17 statement
martin: two diff WUs can be triggered because they have received different things
martin: i don't see a contradiction here
martin: an impt question is how can you guarantee that you trigger the same WU when coord=true
the point is that there are some rules where some times things are ok and other times they are not due to differing coord levels
with coord=true the req on the protocol is the ensure the chor gets to the same WU
peter: i suspect round-tripping on reporting exceptions w/b overkill
peter: you're forcing the protocol to be run twice
nick: we have exception type has to the same (line 19)
nick: we also have this question of coord
martin: we have lightweight coord and heavyweight coord
lightweight - we have an exception but don't necessarily know what it is
heavyweight - they also agree which WU - same WU and same exception being detected - have handshake to ensure we are going to that WU
martin: we also have false - default in spec
nick: lightweight - you don't know the exception - a problem
martin: language in 1.3.3 -> "an exception" = lightweight; "the same exception" = heavyweight
nick: i can live with lightweight... with a condition
martin: AMENDMENT 18 - leave it as is ("an exception" = lightweight), but note that we leave an option to change from "an exception" to "the same exception" (= heavyweight) at a later date
martin: where the note is to the issues list
martin: now we have a knock-down effect
nick: the last sentence of 1.3.2 is also controversial
AMENDMENT 19 -  editors to 'flip around' the last sentence of 1.3.2
now to section 1.4.1
bob: can we remove this paragraph?
martin: AMENDMENT 20 - propose deleting text of 1.4.1
martin: it is no longer really true
srt: AMENDMENT 20 propose taking 1.4 entirely out of here and put it in the primer
nick: if we do that, we do not know what exception we get at the end of the day
martin: 1.4 is all descriptive text
martin: only 1.4.3 introduces semantics not described elsewhere in the rules
martin: we should move/remove the rest of section 1.4
peter: should we not have a named fault?
nick: special info type in the spirit of busn activity protocol
martin: coordination fault - but it is a different proposal
AMENDMENT 21 : Bob to make this correction described below:
Consistent error in this proposal - using "same exception block" where he means "same exception WU" we should correct this in the proposal
martin: AMENDMENT 20 we have a proposal to delete the 1.4 text
nick: don't delete 1.4.3
nick: AMENDMENT 20 move 1.4.3 to the intro to the proposal text
martin: AMENDMENT 20 actually, 1.4.3 becomes  1.3.4
martin AMENDMENT 20  modification - deletion is actually moving the text to the primer
AMENDMENT 20 AGREED

nick: change 1.4.3
martin: "...to roles where the exception was not detected, is the silent fault raised"
martin: Change "silent fault" to "silent exception"
AMENDMENT 22: Bob to change "silent fault" to "exception", change the first line to say "...the coordination mechanism will throw an exception to roles which have not detected an exception..."
if haven't defined a specific exception type, must have a catch-all exception WU
nick: comment: exception should bubble up...? 
nick: AMENDMENT 23 delete 2. globalizedTrigger() paragraph
<Peter> When coordination=true, if an exception occurs the coordination mechanism will throw (raise ?) and exception at all roles that have not otherwise experienced an exception. This exception will be caught by an unguarded Exception work unit.
nick: 3. is OK conditional on proper alignment with other changes to coord proposal 1
AMENDMENT 24: editors to delete 2. globalizedTrigger() paragraph and align 3. in proposal 1
AMENDMENT 24 ADOPTED

*** RETURN TO PREVIOUS TOPIC: LIFELINE ***
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0056.html
<BobH> Tony, did I hear correctly that you have good notes on changes to prop 1?
<Tony> Just sent on email to you - have you received - missed later word smithing
<BobH> tony - got email, thank
<abbie> topic: in boolean condition need to figure out when conditions are evaluated and done
<abbie> same for the WU  (guard =m true)
<abbie> in lifeline text (new life-line section text) proposal to change the text to state the condition is contiously evaluated.
<abbie> is a completed condition equvalent to putting a guard on each condition
<abbie> no diagreement on semantic put debate in on language
<abbie> AMENDMENT 25: Replace once with when in paragraph three of the proposal above
<abbie> Peter: AMENDMENRT 26: suggestion in paragraph three change line six to The complete condition MUST be possible to match the condition in all roles participating in the choreography
<Peter> It must be possible to determine the matching of the completiong condition in all roles ...
<BobH> peter, does that differ from the endpoint-projection interpretation of gt's?
<abbie> AMENDMENT 27: change last two sentences in para 3 to the new text below:
<abbie> when a chereography completes all enclosed choreographies whose whose complete conditions has not been matched will automatically become matched
<abbie> note this text is to replace the last two sentences in paragraph 3
<abbie> add to the text all uncompleted choreographies and closed choreographies will become complete
<abbie> retyping text:when a choreography completes all uncompleted enclosed chereogrphies will automatically become complete
AMENDMENT 27 ADOPTED
<Peter> para from multiple finalizers for lifeline section: After a Choreography completes successfully, any Finalizer blocks
<Peter> specified in the Choreography are enabled.  In other words, as long as
<Peter> Finalizer blocks are enabled, the Choreography is still alive until one
<Peter> of the enabled Finalizers is fired and completes its own Work Unit, at
<Peter> which time the Choreography is closed.
<BobH> change "enabled" to "installed' in peter's addition

<RRSAgent> ACTION: adopt Peter's proposal, incorporate into the editor's draft [1]
<RRSAgent>   recorded in http://www.w3.org/2004/11/18-ws-chor-irc#T18-06-50
<RRSAgent> ACTION: Peter to redraft proposal 5 as amended, change the schema as agreed; editors to incorporate amended text from Peter into spec [2]
<RRSAgent>   recorded in http://www.w3.org/2004/11/18-ws-chor-irc#T21-44-59
<RRSAgent> ACTION: Peter to consolidate the rules in proposal 4; editorial to ensure consistency in text [3]
<RRSAgent>   recorded in http://www.w3.org/2004/11/18-ws-chor-irc#T22-23-46
<RRSAgent> ACTION: editorial - add a note to the LC doc regarding this proposal to the status section: indicating that we are working on this proposal, it is not finalized as of yet, and we do not believe it will have a major impact on the architecture [4]
<RRSAgent>   recorded in http://www.w3.org/2004/11/18-ws-chor-irc#T23-26-51
<RRSAgent> ACTION: editors to 'flip around' the last sentence of 1.3.2 [5]
<RRSAgent>   recorded in http://www.w3.org/2004/11/19-ws-chor-irc#T00-57-43
<RRSAgent> ACTION: Bob to make this correction [6]
<RRSAgent>   recorded in http://www.w3.org/2004/11/19-ws-chor-irc#T01-05-22
<RRSAgent> ACTION: Bob to change "silent fault" to "exception", change the first line to say "...the coordination mechanism will throw an exception to roles which have not detected an exception..." [7]
<RRSAgent>   recorded in http://www.w3.org/2004/11/19-ws-chor-irc#T01-13-06
<RRSAgent> ACTION: editors to delete 2. globalizedTrigger() paragraph and align 3. in proposal 1 [8]
<RRSAgent>   recorded in http://www.w3.org/2004/11/19-ws-chor-irc#T01-20-21
<RRSAgent> ACTION: editors to implement the above text (from abbie) [9]
<RRSAgent>   recorded in http://www.w3.org/2004/11/19-ws-chor-irc#T01-48-21
<RRSAgent> RRSAgent has joined #ws-chor
<abbie> reminder on AMENDMENT insert the finalize complete paragrapgh at the end of the life line section
<Peter> Messages that were sent as part of a choreography that has since completed from the perspective of the receiver must be ignored.
<Peter> s/from the perspective of the receiver/
agreed that we should accept this text and roll it into the text
ACTION 1 = insert the finalize complete paragraph at the end of the lifeline section; editorial to roll this into the text

*** TOPIC: Issue 913 Clarification on workunit guard projection ***
http://www.w3.org/Bugs/Public/show_bug.cgi?id=913
peter: if we have a choice of interactions going on, there are implicit guards on both interacts; where each interact is from A to B, if we have a guard condition on one role, the other role doesn't have anything to do; if we have WU with guards on B, A will never know when to trigger the interact.
nick: w/a guard on B, we have an unguarded send from A
nick: as such we can send something which can possibly never be received
martin: this violates our lock step understanding of CDL
martin: projection - A, always do this interact; B, can do this interact if this condition holds; we have an inconsistency here
martin: what happens here - if no align?
nick: spec indicates that A sends it out, and it goes; when align=false, the interact is successful from A's perspective
martin: what happens to B?
nick: if condition == true, it will be consumed; otherwise it will not be consumed
(this is for a one-way)
nick: extreme endpoint - bpel global map
nick: what cdl does is use a globalizedTrigger() or both, but with a global activity which can be balanced or non-balanced
tony: answer to gary's question w.r.t. this is that B has to look at the message that comes along, determine from it what choice A has made, and act upon it as appropriate
martin: what gary is saying is whether the rule proposed in 913 is a good rule
martin: guard's on B - only B can initiate with A
martin: guard has to be on A for send
peter: globalized will put them on both
martin: If put guard on B, it is not expecting to receive a message
martin: the reason we approach this declaratively is so that each party knows what it is expected of it
martin: if B is false, this interact never happens
nick: if this isn't completing, the WU will never be active
martin: we have boiled the issue down - we will address it first this in the morning with Gary present

Friday 19th Nov 2004

Isolation issue
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0011.html
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0036.html
Decided yesterday that having a workunit guard on the receive side is a desired feature.
Chapman:  Decided yesterday that having a workunit guard on the receive side is a desired feature.
No more constraints will be added to work units. Close 913 without any action.
SRT: Three areas of concerns: (1) How map isolation levels to BPEL [not addressed in this proposal].
SRT: Locking that looks more like scoping.
NK: BPEL and CDL both have serializable. Different products support different levels (BPEL). Vendor specific issue.
NK: Can take functional approach-variable exists or not [exists once-mutable].
NK: Other approach allows for change.
NK: Serializable gives you some hints on doing this.
SRT: Proposal just changes wording somewhat but not the semantics.
<Gary> What about if you have two concurrent activities within the same choreography, there is no way to prevent them from updating the same variable
NK: What is visibility?
SRT: We used visible scope.
Furniss: DB people may be most confused by current terminology.
NK: Coordination changes some things.
SRT: This proposal doesn't address any coordination items.
SRT: It is an issue against the spec in general and also can affect our proposal.
Furniss: Endpoint projection is getting close to implementation as well.
Furniss: The functional description in this proposal is useful.
SRT: The current terminology suggests implementation.
SRT: We are asking to change terminology and the surrounding descriptions. Existing text is not clear.
NK: This new text on visible scope may conflict with visibility horizon.
Review overall text vs. proposal description.
NK: Objecting to defining enclosing choreography because this is defined in the current text.
Section 2.4.5 choreography
Chapman: Should we be addressing isolation in terms of visibility horizon?
NK: AMENDMENT 28 Propose isolation true/false. False is effectively dirty-write and true is serializable.
Chapman: This is in BPEL.
SRT: This simplifies things.
<charlton> +1 for isolation true/false
NK: Simplify to BPEL.
<Gary> +1 for new proposal
<Gary> Gary has joined #ws-chor
+1 on proposal
<Gary> +1 for new proposal
vote: existing - None.
voting: existing semantics +1 Fletcher
voting: 5 for new proposal, 1 abstain.
Accepted.
AMENDMENT 28 ADOPTED
ACTION: Editors to update Section 2.4.5 isolation='true', default is false. See notes for more details.
<Gary> what about nesting of isolated choreographies? BPEL does not allow serializable scopes to be nested
Furniss: What happens to your sibling when you are watching the variable.
It sees old variable. Current text on isolation may mean that but doesn't say that.
Chapman: Reword the semantics of isolation=true. "Changes to the variable information MUST only be visible after the choreography has completed."
ACTION:  Reword the semantics of isolation=true. "Changes to the variable information MUST only be visible after the choreography has completed."
NK: What do we mean - ended or closed?
Leave text as is.
SRT: Address GB question: What about nesting of isolated choreographies? BPEL does not allow serializable scopes to be nested.
NK: Don't agree with this representation.
Chapman: Should we be silent on this condition?
Furniss: Recommend we be silent because the examples are implementation specific.
NK: Assign issue still exists. Assign semantics are atomic but not isolated. See Section 2.5.4.
Leave as is.

*** TOPIC: Session Keys ***
http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/att-0084/CorrelationIssue.ppt
<charlton> SRT presents his example
SRT: How can the buyer determines the specific purchase order?
SRT: Buyer doesn't know what delivery belongs to what conversation. See brief by Steve.
SRT: Correlation issues also exist in BPEL.
Furniss: Not necessarily, partner or elephant (dispatcher) issue.
SRT: Options 1) Adopt same channel insteance between all roles.
SRT: 2) Correlation set of sorts (session encoding)
3) Use channel passing. Forces particular design, not easily implemented in systems.
Team: Had an inconclusive discussion on this item.
Multiple Participants/parallel work units
<charlton> No proposal at this time

*** TOPIC: Multiple Participants and Parallel Workunits ***
<charlton> Issue 944 - summary of issue (multiple participants/parallel WU)
<charlton> gary: only possible to do unbounded repetition of set of activities inside a WU with a repeat clause; that only allows those activities to be performed sequentially; we also need ability to say "we need n instances of this set of activities to be performed concurrently". at present we only have the ability to define concurrent activities through the parallel construct
<charlton> SRT: we can treat this as so important that we have to deal with it before LC?
<charlton> Gary: With the existing parallel construct, can have more than one element of that construct accessing a single variable, so we have an issue to address.
Gary: only possible to do unbounded repetition of set of activities inside a WU with a repeat clause; that only allows those activities to be performed sequentially; we also need ability to say "we need n instances of this set of activities to be performed concurrently". at present we only have the ability to define concurrent activities through the parallel construct
SRT: we can treat this as so important that we have to deal with it before LC?
Gary: With the existing parallel construct, can have more than one element of that construct accessing a single variable, so we have an issue to address.
Gary: If you can repeat activities concurrently, perform with isolation could overcome problem.
NK: Small problem still exists.
Data that you are using in the work unit, guard etc. has to be declared earlier.
Gary: Need how to declare how many instances there are.
NK: As we discussed yesterday, flexible model has advantages.
NK: What does the fixed instance buy you?
Furniss: Pushes guard of work unit into the parallel construct itself.
<Gary> there could be a 'concurrency' attribute that is an XPath expression that results in an integer, which is the number of concurrent threads
NK: CDL can't do event handlers right now.
<Gary> this attribute would be mutually exclusive with the repeat condition
This relates to previous London Enigmatic proposal.
You could create a declaration unit within a work unit.
Work units could validate (idea I thought about).
SRT: Proposal from Gary: There could be a 'concurrency' attribute that is an XPath expression that results in an integer, which is the number of concurrent threads. This attribute would be mutually exclusive with the repeat condition.
Dynamic
Furniss: Have to tie into index variables.
Note: Delete NK comment from notes ( Work units could validate (idea I thought about).
SRT: Proposal from Gary: There could be a 
Chapman: ID could be passed down.
Furniss: You need to have a variable that provides the index.
Chapman: Need to solidify the proposal by 23 Nov 2004.
SRT: May approach this as an issue and discuss later.
Furniss: This is of sufficient utility to announce.
Chapman: Agree.
<BobH> I think we need some analysis of the facets of problem as prep for a proposal.
Chapman: Propose how to handle unbounded number of roles of the same type, interactions to an unbounded number of participants (seq and parallel).
NK: This is too drastic.
<Tony> Monica is not on a mic - some distance away down the room -- Peter has now moved up room can you hear better now?
Chapman: Document as too many specs.
SRT: PROPOSAL: Due to a lack of clarity in existing specifications, we are unable at this time to recommend an approach for lists and arrays.
SRT: List specifications in above.
AMENDMENT 29 Add [XML specifications].
<mchapman>  AMENDMENT 30: Due to a lack of clarity in existing XML specifications, we are unable at this time to recommend an approach for accessing and modifying members of lists and arrays.
AMENDMENT 30 ADOPTED
ACTION: Editors to insert in new section of last call issues:  Due to a lack of clarity in existing XML specifications, we are unable at this time to recommend an approach for accessing and modifying members of lists and arrays.

*** TOPIC: Review and Planning ***
Chapman: Are we happy with the decisions and the document from this F2F?
NK: Need another editors' draft.
Chapman: Straw poll - are we ready for last call?
Chapman: In principle.
Team: No objections expressed.
Planning
Chapman: Absolute deadline is 20 Dec 2004.
10 Dec working draft
Must be available to Lafon by open bus 13 Dec 2004.

RESOLUTION: LATEST EDITORS DRAFT WAS ADTOPED AS A WORKING DRAFT 
RESOLUTION: IT WAS AGREED THAT THE WORKING DRAFT PLUS AGREED AMENDMENTS FORMED THE BASIS FOR A LAST CALL DOCUMENT

Use editors' call 9 a.m. 6 December. Bridge already available.
2 hour call 
PST
7 December regular call (2-hours0
30 Nov regular call-Address first 25 pages of existing editors' draft.
<Yves> ACTION: Yves to send irc transcript to the wg ML
Fletcher will assist editors' team.
No meeting 23 Nov 2004.
Editors' can use the meeting if they wish.
Chapman: May need a triage on issues at some point after 10 Dec.
<nikos> gary: per your question regarding perform/choreography?
<nikos> i did that to accomodate your issue for having inlined performed choreos
<Yves> ACTION: martin to create last call categories form issues
<Gary> Nick: don't think this addresses the issue, so it would be better to remove
<gritzinger> I sent the Word formatted draft as a .tar.gz and again as .doc (zipped) to member-ws-chor-editors
<nikos> why not?
<Yves> http://www.w3.org/2004/11/19-ws-chor-irc.txt
<Tony> Meeting re-starting for wrap up
<Tony> Things that need doing after LC doc - includes Primer
<Tony> Start last call just before or just after Chistmas
<Tony> Martin to send an email to members list on program for next few weeks  Resume next year 11 Jan 05 first call
<Tony> Next F2F with W3C Plenary 28 Feb - 1 March or 3 & 4 March 05
<Tony> One after that June 05
<Tony> Work topics post 10 Dec 04
<Tony> Primer and part 2 doc
<Tony> Tony to send his Primer proposed TOC to list
<Tony> Martin / Greg to update Bugzilla with agreed resolutrions from this meeting
<Tony> Triage issues list
<Tony> Set up last call category in Bugzilla
<Tony> Looking for volunteers for Primer and Part 2 - make these Notes rather than Rec track docs
<Yves> Steve volunteer for the primer
<Tony> Steve volunteers to lead on Primer and Tony to help out
<Yves> ACTION: Chairs to make exit and implementation criteria proposal for the group
<Tony> Ask W3C management if we can extend charter for 6 months to do Primer and Part 2 and to shepherd the main spec. 
<Tony> We currently know of at least two implementations in progress
<Tony> Aim for CR around end April 05
<Tony> Yves recommends asking for one year which will include keeping the group in existance after Rec status to process comments on the Rec
<Tony> Yves will do this - actually ask for 9 months plus the 3 months delay at the start.
<Tony> Aim PR July 05
<Tony> Rec in Sept 05
<Tony> Errata processing to end of 2005
<Tony> Need Primer by CR time around April 05
<Tony> Draft primer for next F2F
<Tony> Need to do call for volunteers fro part 2 doc
<Tony> Noted that we end up amalgamating primer and Part 2 - but not make that decsion yet
<Tony> Meeting thanked Oracle for hosting  - meeting closed

*** SUMMARY ACTION ITEMS ***

[NEW] ACTION: Martin to produce 'punt' text. 
[NEW] ACTION: Boolean resolution: tony to clarify the text if possible
[NEW[ ACTION: editors to add support to wsdl 1.1 in section 1.4 as constrained with ws-i basic profile for compatibility
[NEW] ACTION: editors to change the text to add variables of the same name and clarify the text, variable names that are same can be shared within a  participants with different roles
[NEW] ACTION: editors to fold in http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0042.html - "Revised Proposal on a WS-CDL supplied Duration timeout function" into working draft
[NEW] ACTION: adopt Peter's proposal, incorporate into the editor's draft
[NEW] ACTION: Peter to redraft proposal 5 as amended (AMENDMENT 2), change the schema as agreed; editors to incorporate amended text from Peter into spec
[NEW] ACTION: Peter to consolidate the rules in proposal 4
[NEW] ACTION: On Editors- add a note to the LC doc regarding extending choreographies proposal to the status section: indicating that we are working on this proposal, it is not finalized as of yet, and we do not believe it will have a major impact on the architecture
[NEW] ACTION: insert the finalize complete paragraph at the end of the lifeline section; editorial to roll this into the text
[NEW] ACTION: Editors to update Section 2.4.5 isolation='true', default is false. See notes for more details.
[NEW] ACTION:  Reword the semantics of isolation=true. "Changes to the variable information MUST only be visible after the choreography has completed."
[NEW] ACTION: Editors to insert in new section of last call issues:  Due to a lack of clarity in existing XML specifications, we are unable at this time to recommend an approach for accessing and modifying members of lists and arrays.
[NEW] ACTION: Yves to send irc transcript to the wg ML
[NEW] ACTION: martin to create last call categories form issues
[NEW] ACTION: Chairs to make exit and implementation criteria proposal for the group
[NEW] ACTION: Bob to change "silent fault" to "exception", change 
... the first line to say "...the coordination mechanism will 
... throw an exception to roles which have not detected an 
... exception..." 
[NEW] ACTION: Bob to make this correction 
[NEW] ACTION: editors to 'flip around' the last sentence of 1.3.2 
[NEW] ACTION: editors to delete 2. globalizedTrigger() paragraph 
... and align 3. in proposal 1 
[NEW] ACTION: editors to implement the above text (from abbie) 

*** SUMMARY OF DECISIONS ***
DECISION: leave text to primer (or was it)
DECISION: PROPOSAL (above) FAILED
NOTE: NO DECISION WAS REACHED ON Timeout Proposal final text
DECISION: PETERS PROPOSAL ABOVE AS AMENDMENTS TO TIMEOUT/EXCEPTION IS ADOPTED
DECISION: group agrees to this proposal as default. That is if no ammendments are adopted then this proposal will be deemed to have been accepted
DECISION: Proposal 3 was adopted subject to amendment above.
DECISION: AMENDMENT 1 was adopted.
DECISION: Peter to providea mendments to proposal 5 over lunch
DECISION: Proposal to adopt AMENDMENT 2 (also see AMENDMENT 1) was accepted
DECISION: Peter to consolidate rules in proposal 4 including AMENDMENTS 1 through to 13 above
DECISION: Add a note to the LC doc regarding extending choreographies proposal to the status section: indicating that we are working on this proposal, it is not finalized as of yet, and we do not believe it will have a major impact on the architecture

*** SUMMARY OF AMENDMENTS ***
AMENDMENT: REMOVE: "The finaliser workunits are enabled only after the Choreography..." paragraph 
<SRT> PROPOSAL (AMENDMENT 1): rename "choreographyInstance" to "subChoreographyInstance" 
vote: agreed - rename subChoreographyInstanceId to choreographyInstanceId (AMENDMENT 2)
martin: AMENDMENT 3: to have XPath expressions/xsd:string
nick: AMENDMENT 4 strike "...Choreography MAY have more than one finalize..."
nick: AMENDMENT 5 editorial - replace "inner" with "enclosed"
<Peter> AMENDMENT 7 For a single choreography instance performed in an enclosing choreography, only one finalize shall be invoked.
nick: AMENDMENT 8  Proposed semantics - implicit close
martin: AMENDMENT 9 therefore, the second paragraphy should be "A Choreography SHOULD have at least one finalize element..."
martin: AMENDMENT 10 Paragraph 2 is definitely now a SHOULD
<Peter> AMENDMENT 11 choreographyInstanceId text sent to email : http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0073.html
AMENDMENT 12 correction - A goes out of scope w/o explicit finalization of B and C, B and C are therefore NEVER finalized
martin: we need to insert the sentence AMENDMENT 13 "the finalize activity may be used in the main body of a choreography, the finalizer block of a choreography, and/or the exception block of a choreography if defined"
martin: proposed AMENDMENT  14- "The Finalize activity is used to enable one or more finalizers..."; changing finalize element to have element nested with a '+'
nick: AMENDMENT 15 I propose to delete the three paragraphs starting with "The conditions under which a finalize is chosed is governed..."
monica: AMENDMENT 16 we need to make the preceding paragraph ("The optional attribute choreographyInstance...") needs to be made consistent
correction: monica: AMENDMENT 16 we need to make the preceding paragraph ("The optional attribute choreographyInstance...") consistent
<SRT> PROPOSED AMENDMENT 17 FROM NICK: The optional coordination attribute specifies whether a Choreography
martin: AMENDMENT 18 - leave it as is ("an exception" = lightweight), but note that we leave an option to change from "an exception" to "the same exception" (= heavyweight) at a later date
AMENDMENT 19 -  editors to 'flip around' the last sentence of 1.3.2
martin: AMENDMENT 20 - propose deleting text of 1.4.1
srt: AMENDMENT 20 propose taking 1.4 entirely out of here and put it in the primer
AMENDMENT 21 : Bob to make this correction described below:
martin: AMENDMENT 20 we have a proposal to delete the 1.4 text
nick: AMENDMENT 20 move 1.4.3 to the intro to the proposal text
martin: AMENDMENT 20 actually, 1.4.3 becomes  1.3.4
martin AMENDMENT 20  modification - deletion is actually moving the text to the primer
AMENDMENT 20 AGREED
AMENDMENT 22: Bob to change "silent fault" to "exception", change the first line to say "...the coordination mechanism will throw an exception to roles which have not detected an exception..."
nick: AMENDMENT 23 delete 2. globalizedTrigger() paragraph
AMENDMENT 24: editors to delete 2. globalizedTrigger() paragraph and align 3. in proposal 1
<abbie> AMENDMENT 25: Replace once with when in paragraph three of the proposal above
<abbie> Peter: AMENDMENT 26: suggestion in paragraph three change line six to The complete condition MUST be possible to match the condition in all roles participating in the choreography
<abbie> AMENDMENT 27: change last two sentences in para 3 to the new text below:
AMENDMENT 27 ADOPTED
NK: AMENDMENT 28 Propose isolation true/false. False is effectively dirty-write and true is serializable.
AMENDMENT 28 ADOPTED
AMENDMENT 29 Add [XML specifications].
<mchapman>  AMENDMENT 30: Due to a lack of clarity in existing XML specifications, we are unable at this time to recommend an approach for accessing and modifying members of lists and arrays.
AMENDMENT 30 ADOPTED