what is the passcode for this call?

<kliu> sorry I forget the Zakim meeting id, can somebody help?

me too

<TonyR> async

<Marsh> http://www.w3.org/2001/01/cgi-irc

<marc> i'd also like to know the dial in info

<scribe> scribe: anish

<scribe> Scribe: anish

<marc> ah, found it: +1.617.761.6200, conference 27962

mark: glen has agreed to chair the TF meetings
... we have 3 more weeks to present to the WG at the tech plenary

greg presents what he sent out on the ML

glen: there are lot of usecases where WSDL gets generated into server side code
... i take the wsdl and the code generated is the programming model

greg: from a logical perspective this could be a single portType, but if they are split up then they are going to be different things

glen: wsdl is one layering of looking at messages on the wire
... another layer is bpel

<kliu> glen, to me the scope of wsdl and bpel is clear: wsdl mep deals with message exchange within an operation, bpel deals with operations, and only in the abstract level

<kliu> the issue is now if an abstract wsdl mep is splitted into mulitple binding meps

<kliu> then bpel will not be able to compose the binding meps

discussion between anish and glen about bpel and wsdl. General agreement about various ways to do this and coming up with pros and cons and presenting it to the WGs

ugo: wsdl 1.1 does allow this thru extensibility

glen: yes, but syntactically it does not say how

jonathan: this (greg's approach) seems more creative than daveo's approach

anish: well regardless of which approach we take I think we need to do what daveo has suggested as well as what greg is trying to do
... daveo is looking at MEPs and bindings where as greg is looking at things on the wire and WSDL

glen: at the very least we need to come up with a SOAP one-way MEP

kevin: we also need to provide a poll (out-only operation)

<more discussion on out-only operation and SOAP binding>

glen: we need to come up with question and possible answers to those, such as do we need to create a new MEP etc

jonathan: wouldn't it help enumerate what we want to support?

<kliu> sounds I didn't make myself clear

<kliu> what I was trying to say is that

greg: the three models are: one-way, request-response, and response-response over different transport
... sounds like glen is asking for a fourth case

<kliu> no matter it's in-only or out-only)

marc: there is a std way to do this in HTTP by saying get the result of this from this URI

<kliu> ...we can define a http binding

<kliu> ... for one-directional meps

marc: one of the problems is dealing with NATs for post followed by a get

<kliu> ... which specifies how to deal with the http response, just like what's in BP

glen: there is a case where the response may have a choice of binding (thru replyTO)

greg: in slide 16 of my presentation

<kliu> ... that http binding is applicable for both in-only and out-only wsdl meps

greg: won't the server need to know apriori what the binding will be

glen: the high order bit here is -- the given operation is bound asynch or synch?

greg: or different transports

<more discussion on how the bindings/transport>

glen: two things - same transport different connections, different transport different connections

anish: this ties in to the WSD issue about allowing binding at the input and output level

micheal: another thing to do is -- same operation and the server decides whether the response is sent synchronously or asynchronously

<discussion about synch v. asynch and client programming model>

tony: to my mind the important thing about asynch is not what the server sees but what the client does while the client is waiting for the response
... the only issue is if the client side is trying to do something else
... if it is, then it is asynch

michael: we need to be more organized, we have good input from today's discussion. But need to list things out

<MSEder> +1

kevin volunteers to summarize the options

anish to help kevin

marc: willing to dig out stuff about HTTP and using GET

<scribe> ACTION: kevin to send out a summary with various option for WSDL 2.0

<scribe> ACTION: glen to start discussion for appropriate wsdl granularity for aynch binding

<scribe> ACTION: 2 to glen to start discussion for appropriate wsdl granularity for multi-transport binding

ACTION 2=glen to start discussion for appropriate wsdl granularity for multi-transport binding

ACTION 3=

<scribe> ACTION: marc to look into HTTP POST+GET approach

adjouned

This is scribe.perl Revision: 1.109  of Date: 2005/01/21 04:36:25  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/keving/kevin/
Found Scribe: anish
Inferring ScribeNick: anish
Found Scribe: anish
Inferring ScribeNick: anish
Scribes: anish
ScribeNicks: anish

WARNING: No "Topic:" lines found.

Default Present: MarkN, Rigo, Steve, MSEder, Ugo_Corda, Glen, Jonathan_Marsh, TonyRogers, Greg, +1.503.417.aaaa, anish, KevinL, [Sun], Roberto, Marc, [webMethods], asir, [IBM]
Present: MarkN Rigo Steve MSEder Ugo_Corda Glen Jonathan_Marsh TonyRogers Greg +1.503.417.aaaa anish KevinL [Sun] Roberto Marc [webMethods] asir [IBM]
Got date from IRC log name: 2 Feb 2005
People with action items: 2 glen kevin marc

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report