See also: IRC log
gil: as event sink, may need more
detail, e.g. SOAP 1.1, 1.2, RPC, ...
... static wsdl is hard to determine the what binding is.
Yeves: binding maybe specified in subscription time to make things easy
bob: 6429 will take further
discussion to the list.
... 6430
<gpilz> ??P5 is a trouble maker
<gpilz> see, told you
<dug> +q
li: propose an attribute to indicate event source
<gpilz> +q
li: we should consider W3C Semantic Annotation for WSDL and XML Schema
dug: I am wondering if this should be at portType level, operation level, etc.
gil: need to do homework and think of a competing proposal using policy
prasad: this may relate to bp issue
asir: some question of attribute
li: it allows to you to subscribe port, not source
asir: it will help to make the context know.
li: in ecma-348, need to indicate in SOAP header
Geoff: what is the mapping in wsdl and what you subscribe
li: this is another submitted issue for ws-e
asir: some background of the
issue is very helpful
... policy assertion apply to shared behavour and event source
may not
<Bob> ACTION: Li in email to the public list, describe the background and implications to 6430 more fully [recorded in http://www.w3.org/2009/01/16-ws-ra-minutes.html#action01]
Geoff: to link the issue with 6425 which is another half will be helpful
bob: 6431 is next
li: propose add pause/resume
operation to ws-e
... it can reduce ws-e overhead in subscribe/resubcribe
gil: seem a good idea, like to see more detail
bob: events will be qued or pause event delivery
li: open to implementation/application at this moment
gil: maybe define pause or queue at start. maybe this is an implementation choice
bob: it may add a lot of complexity. there is any additional cost beyond subscribe/unscribe
<Prasad> What if you pause and forget (to resume) foreever?
li: pause is very common in business case
asir: need to consider cr phase
<Yves> questions about possible cost of a subscription or delivery reminds me of the safeness of WS-Transfer:Get...
<dug> Yves - can you elaborate?
<Yves> if you retreive something using WS-T:Get and something goes wrong, is it safe to re-issue the request or not?
<Yves> ie: is WS-T:Get used in case of payment to retreive information (where you don't want to do twice ;) )
<asir> safe
<Yves> we might clarify that in WS-T then
<Yves> I'll open an issue ;)
wu: we can confine pause as a short-hand of subscribe/unsubscribe then subscribe, which semantics are defined in ws-e
<asir> ok
<dug> are you saying that T.get() will change the fact that a payment happened?
<Prasad> If we introduce pause / resumeetc, semantics need to be simple. No pooling of events until resume etc. Pause will make you lose events until resume also. Otherwise huge overhead on the event-source side and what if the pause is never resumed. There need to be timeout semantics also
<Yves> no, I just wonder if people are tying T.Get and payment (as it may lead to double charging someone if T.Get implies you can safely re-issue the request if something fail, like power failure)
bob: 6398 issue
dug: looking atthe impact on ws-rt
Geoff: we need extensibility.
ws-rt spec is on extending ws-t.
... by making changes suggested, this relation broken
... Thus, this is a significant change to ws-rt
asir: needs to think more
dug: I missed that relation
... one way to solve it is to ask ws-rt to use the same
wrapper
asir: this is significant change and like to see detail
dug: like to know if this wg is o.k. to that geneal direction
asir: need to know more if this is reasonable
<Bob> ACTION: Dug Take proposal for 6398 to the next level of detail including extension to include impact on WS-RT, including deleteRequest (getting us to 8 operations in T) and MEX [recorded in http://www.w3.org/2009/01/16-ws-ra-minutes.html#action02]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/vere/ever/ Succeeded: s/T)/T) and MEX/ No ScribeNick specified. Guessing ScribeNick: wu Inferring Scribes: wu WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Geoff Prasad Yeves Yves asir bob dug gil gpilz gregcarp ie li wu You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 16 Jan 2009 Guessing minutes URL: http://www.w3.org/2009/01/16-ws-ra-minutes.html People with action items: 6398 dug for li proposal take 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[End of scribe.perl diagnostic output]