W3C

- DRAFT -

SV_MEETING_TITLE

16 Jan 2009

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
wu

Contents


 

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]

Summary of Action Items

[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/16 00:57:10 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]