See also: IRC log
<trackbot> Date: 07 July 2009
<Bob> trackbot, start telecon
<trackbot> Meeting: Web Services Resource Access Working Group Teleconference
<trackbot> Date: 07 July 2009
<dug> does anyone else hear an echo?
<dug> he who smelt it dealt it ;-)
<Bob> scribe: Vikas
<scribe> Agenda: Agenda accepted without objection.
RESOLUTION: No objections. The minutes from 2009-06-30 meeting has been approved.
<scribe> Topic : 6401
Wu: Requirment document published in group.
Gil: Why do we need a seperate BP compliant issue.
Dug: Ask for clarification on the uddi compliance part of the requirement.
Geoff: BP compliance should be fine.
Asir: Allow everyone some time to look at the requirement.
Bob: If any one has issue.
... Wu and Gil work offline to resolve the issue on the requirement part.
<scribe> ACTION: Wu and Gil. Work on the requirment clarification. [recorded in http://www.w3.org/2009/07/07-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-79 - And Gil. Work on the requirment clarification. [on wu chou - due 2009-07-14].
<Ram> Proposal for issues 6413+6975+7014: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0006.html
<dug> the mother of all proposals!
Dug: (and Ram) Quick walk through the proposal.
Bob: Do any one need more time to review the proposal
<Tom_Rutt> so why not change "Use of this URI indicates that the contents of the Delete element should be processed as specified by the WS-Fragment [WS-Fragment] specification. to "Use of this URI indicates that the contents of the Delete element MUST be processed as specified by the WS-Fragment [WS-Fragment] specification."
<dug> +1 - for all OPs
<Vikas1> Bob: Any objection to the adoption to the change TomR suggested in IRC
<Vikas1> No objection raised
<Vikas1> Bob: Any objection to the other three parts in the proposal
<dug> "The Working Group may organize the structure of the specifications into one or more documents."
<Zakim> asir, you wanted to ask a question
<Vikas1> Bob: Clarify with Yves on the WS-Frag within the charted of the group.
<Vikas1> Yves: Should be fine
<asir> Vow, that is a big one!
<Vikas1> No objection on the proposal 6413+6975+7014
<gpilz> 3 issues in one day, I think that's a WS-RA record
<Geoff> should we just finish now? It can't get any better can it?
<Vikas1> Resolution: No objection on the proposal 6413+6975+7014 proposed by Dug/Ram
<Tom_Rutt> Resolution: proposal as amended by Tom Rutt's text, to be applied to all operation types
<Vikas1> ACTION: Dug : Open a new issue initial workign WS-Frag spec. [recorded in http://www.w3.org/2009/07/07-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-80 - : Open a new issue initial workign WS-Frag spec. [on Doug Davis - due 2009-07-14].
<DaveS> Dave S will alos help draft the Frag spec.
<dug> thanks Dave
<Vikas1> ACTION: Ram and Dug: Generate a proposal for WS-frag Spec [recorded in http://www.w3.org/2009/07/07-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-81 - And Dug: Generate a proposal for WS-frag Spec [on Ram Jeyaraman - due 2009-07-14].
<Vikas1> Asir: last week, Asked for another week.
<dug> (last week)
<Vikas1> Bob: Any objection on the proposal 1
<asir> 4 issues in 43 minutes
<Vikas1> Resolution: No objection, Issue 7039 resolved with proposal 1
<Bob> additional comments by Wu http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0004.html
<Vikas1> Bob: Are we ok with the slicing of the issue.
<Vikas1> Geoff: Concern with use of extension point.
<Vikas1> Geoff: Concern specifically with the semantics a possible pull mode.
<dug> +1 the wse:NotifyTo is the "default extension"
<asir> what is out of scope for this WG?
<dug> asir - so?
<dug> if wse:NotifyTo works for both then that's fine - nothing more is needed to be said
<Vikas1> Gil: Support the proposal.
<Vikas1> Dug: Just required some tweaking to delivery element description.
<Vikas1> Wu: Support Geoff concern...
<Vikas1> ...semantically structure extension using policy.
<dug> ....the wse:NotifyTo element MUST be present and be the EndpointReference to which notifications are sent.
<dug> bob - I'd like to ask him a follow on
<Geoff> what is the point of this question?
<Vikas1> Wu: ....if you allow arbitrary xml, it can be issue.
<dug> tom:AltNotifyTo would need to say how it works with wse:NotifyTo - no biggie
<gpilz> This specification defines only a default asynchronous method of delivery for notifications from the event source to event sink. Other methods or combination of methods may be defined through the use of delivery extensions.
<dug> "...the EndpointReference to which notifications are sent."
<Geoff> not necessarily
<Geoff> indeed :-)
<Vikas1> Geoff: When you add new element…it may change behavior altogether…not clear how these elements interact with other.
<Vikas1> Dug: This is not a delivery specific problem. Need to be handled by subscription manager.
<Vikas1> Gil: Every spec defines extensibility point…idea of having arbitrary xmls…is common across any ws* spec.
<Tom_Rutt> The semantics of including notifyTo along need to be clarified
<Geoff> yes there might
<dug> wse:NotifyTo is just the default extension
<asir> Both SOAP and WS-Policy processing models did not introduce any default semantics for extensions, everything is explicit
<dug> so.. s/default/well-defined/
<asir> Doug - not sure why you are modifying my statements :-)
<dug> I didn't - i was clarifying mine
<asir> but the sed script applies to the most recent one :-)
<Tom_Rutt> we need ot clarify the semantics of having a notifyTo along in the delivery element. Any extension has to explain how it differs from the default semantics
<Vikas1> Wu: default is push, and xml is added to modify it….need to know when the default is off.
<Vikas1> Bob: To Wu are you proposing all implementer should support policy.
<asir> F2F agreement is at http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692#c6
<dug> <wse:NotifyTo/> + <tomsPush/> + <pull/> + <pushWithAck/> + <pullWithAck/>
<Geoff> if there is no PUSH then pushWithAck can fail
<asir> well .. subscriber shall not lie!
<Geoff> because it knows that that it is no longer push
<Geoff> <wse:NotifyTo/> + <tomsPush/> + <Ack/>
<asir> well .. one of the concerns that we addressed to avoid combinatorial explosion is not to use compund names
<asir> instead of Pushwithack .. you all wanted Push + Ack
<Geoff> how does Ack know if it is a push or a pull?
<dug> I don't see how we can close 6692 if there is such a basic disconnect between the two groups
<li> qnames is a refactoring of mode uri
<asir> asir explained that there is no basic disconnect. the outstanding issue is to figure out how to represent the default behaviour - explicit or implicit
<asir> it appears that the implicit representation collides with the extensibility model
<Bob> note that asir's last two comments were made after the conclusionoof the conference call
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/issues/proposals/ Succeeded: s/though/through/ Succeeded: s/Tpoic/Topic/ Succeeded: s/Ask/Asked/ Succeeded: s/Asked/last week, Asked/ FAILED: s/alonge/alone/ Found Scribe: Vikas Inferring ScribeNick: Vikas WARNING: No "Present: ... " found! Possibly Present: Ashok Asir Bob DaveS Geoff Gil Ram TomRutt Tom_Rutt Vikas1 Wu Yves dug gpilz joined li tom trackbot ws-ra wse You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0003.html Found Date: 07 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/07-ws-ra-minutes.html People with action items: dug ram wu[End of scribe.perl diagnostic output]