See also: IRC log
<Bob> scribenick: wu
<Bob> scribe: Wu Chou
bob: ready to go
... accepting new issues and go through submitted WS-E issues
li: issue opened in response 6397
... three issues may be caused by it
<Yves> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6397
li: propose to move subcription manager to from field of the SOAP header to reserve these identifier
geoff: perhaps there are use cases might be useful
dug: how use of subscription manager in subend
li: used by subscriper
gpilz: question assumtion of subscriber
Geoff: its a use case and people may be
gpilz: epr comparison is hard to compare
Geoff: existing implementation may use this feature, do we want to be backward competible
li: even we treat epr a block, it is in the from field and will be echoed back by WS-A
dug: the reason for correlation. epr comarison we should not avoid
gpilz: bk competibility, we change namespace may break bk competibility, we can use epr we can compare
dug: featurewise we may not lose much
<dug> s/much/anything/ :-)
bob: gil opposes accepting this as a new issue
wu: we should exmine this, espcially there are exsting implementation
bob: we do not accept this issue at this time and wu/gil will discuss this issue
... we will set this issue to no action at this moment
<Bob> The only opposition to not accepting this new issue was Avaya of those present
asir: push also through mailing list
bob: to make our discussion on the pub mailing list in addition to bugzilla
li: an example is attached and listed examples of infoset model
gpilz: should accept this issue, understand benefits
<Prasad> +1
gpilz: show some benefits of abstract properties
li: original benefits are listed in wu's presentation
yves: exi is a xml format
... which is beyond soap
<Yves> http://www.w3.org/XML/EXI/
bob: there are other cases and a reason for WS-A
dug: if valuabe, should apply to others
Yves: there are many standards use Infoset
<Yves> like SOAP1.2 WSDL2, Addressing etc... It also allows the use of MTOM, for example, or other optimization that may be needed
li: Infoset in eventing clear advantages may apply to others
bob: implication of adopting Infoset
Yves: just define Infoset and apply it to various cases
wu: it will be one standard, but make it more readability
Yves: it should not affact readability
<asir> not a general statement, but for WS-A I like the infoset speak
asir: maybe wu can try write it for one section
<Prasad> The spec is readable as is. Adding infoset notation to make it more readable is a lot more work (for editors to create) and whole WG to review and make sure it is correct etc. is unnecessary work IMHO. Like Dug and others, I find Infoset notation more confusing than helpful
bob: likely to support to take a prototype chapter?
<dug> Prasad - any reason you didn't get on the Q to say that?
bob: Li are you willing to take one chapter?
li: a section?
<Prasad> Dug, I can jump the q and say it exactly the way want it (in the minutes:)
Geoff: yes, say for example a section - subscribe
<Bob> ACTION: Li Produce a exemplar of the proposal for an operation such as subscribe [recorded in http://www.w3.org/2009/01/16-ws-ra-minutes.html#action01]
gpilz: could be important for WS-E since data can be large
li: the proposal using EPR to address event source
... two examples included in the proposal, including an example in csta for dynamic event source
bob: where part in WS-E spec will be affacted
li: in subscribe section
gil: how well can you do it and not sure how to address someting
dug: not sure what spec is missing
bob: they ask for the pointer which part of WS-E will be affacted
li: if we want to subscript to one of 10 port, subscribe to one of them
... if only with top level address to send message to, not clear how to address lower or dynamic resources
Geoff: full example to compare before and after may help
li: port type is from Annex of WS-E, annotate portType as event source, how to subscribe to this type ...
gil: port has address, support single binding
asir: can support multiple ports in wsdl
bob: maybe follow Geoff suggestion as next step
li: OK
<Bob> ACTION: Li to produce a before/after text demonstrating the change desired for 6425 [recorded in http://www.w3.org/2009/01/16-ws-ra-minutes.html#action02]
li: WS-E delivery is a single element. It is in wrong place to move to WS-E delivery
... schema does not reflect this element properly
... proposal is to address this
gil: i agree, thanks to bring this issue
... the mode is left open ended
... however, example schema has an error
... delivery type should have some form of any for extension
li: good
asir: proposal seems concrete
bob: to make the amandament to the proposal, send it to public mailing list
Geoff: put section number in to help understanding it
<Bob> ACTION: Li to update proposal for 6426 to the public list [recorded in http://www.w3.org/2009/01/16-ws-ra-minutes.html#action03]
dug: Don't have ocncrete proposal. one thought is using WS-policy
gil: putting policy in side wsdl is not very natural
<gpilz> actually describing operations inside policy isn't very natural
dug: different portType ... looking for suggestions
Geoff: two points to consider, run time, compile (develop) time. we should lose track of both of those
gil: agree to two aspects, inventing new describe language may not be good
... maybe raise an issue to WS-I and it does not apply here
... tell WS-I R2303 not apply here
prasad: the reason of WS-I is binding, outside WS-E may still a problem
... I have no issue since I argued to keep notification
bob: is binding is properly specified in ws-e
dug: changing BP to do this, may not be a reasonable thing to do
bob: write a W3 Note, not W3C recommendation but referrencable
<dug> actually, it may or may not be reasonable - we just need to check because changing BP will have impact on people
bob: this is about outbound operation binding
wu: Binding must be in the context of subscribe/notify web service interaction, which is stateful.
bob: Gil to carry to BP group to extend R2303 allow binding through sub/notify
... how to close this as no action?
dug: this may be an issue
bob: restiction is raised because of binding. ws-e provided this binding
gil: may be try WS-I to see how WS-I react
wu: tool should not be a reason to limit standard
bob: we have charter to be aligned with with BP
dug: BP important to us, most our tools using it
... BP not fair not awaring this. there is other way. I am not suggesting that
gil: BP complaint mode vs. ws-transfer complaint can be hard
bob: if BP 1.2 or BP2.0 can make the situation different
<gregcarp> fine
<Bob> ACTION: Gil to carry BP output-only operation prohibition to WS-I [recorded in http://www.w3.org/2009/01/16-ws-ra-minutes.html#action04]
gregcarp: odd to prohibate valuable apps due to profile. prohibate forever due to not in the profile is not perceivable
bob: Gil has action to take up this with WS-I
<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0040.html
dug: this is an updated proposal from yesterday discussion
Geoff: thank for improvement, but not like overloading term format
resolution: resolve Issue-6405 with last proposal (Comment#3 in Bugzilla
li: proposal is to copy the default value to schema for benefit of apps and tools
dug: can we do more for other standards?
... this is all or just an example
li: only an example and there are more in ws-e
<gpilz> test
asir: send a list to the group to look at it, than change it
bob: wu list all such changes in ws-e, share with group, then move on
li: 6428 about mode attribute in ws-e, which is used for separate things
... it should be open/extensible, suggest to add new attribute "Format"
dug: you may need more information than URI than Format, which can be something to consider
... you may need more than URI to address it
gregcarp: is it cleaner way or you can do something additional
<dug> a new element, sibling to Delivery/Mode, might be cleaner
li: it would odd to do two things on one URI
Geoff: maybe consider dug suggestin, adding more than URI
... I would like to think if there is additional extensibility
li: this is related to delivery mode. propose to define standard wrap interface
gil: recommand this a separate WSDL
li: exactly, this is the WSDL for the event sink
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.
li: propose an attribute to indicate event source
... 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#action05]
Geoff: to link the issue with 6425 which is another half will be helpful
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)
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#action06]
see you next Tuesday, Meeting adjourned