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
<Bob> scribe: Vikas
<scribe> Agenda: Agenda accepted without objection.
RESOLUTION: No objections. The minutes from 2009-06-30 meeting has been approved.
Wu: Requirment document published in group.
Gil: Why do we need a separate BP compliance requirement?
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 and bring back to the WG those points of disagreement.
<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 requirement 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
<Bob> scribenick: Vikas1
Bob: Any objection to the adoption to the change TomR suggested in IRC
No objection raised
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
Bob: Clarify with Yves on the WS-Frag within the charted of the group.
Yves: Should be fine
<asir> Vow, that is a big one!
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?
RESOLUTION: Resolve Issues 6413, 6975, and 7014 with the proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0006.html amrnded with the text at  applied to all four operations where the underlying text exists w/o
<scribe> 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
<scribe> 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].
Asir: last week, Asked for another week.
<dug> (last week)
Bob: Any objection on the proposal 1
<asir> 4 issues in 43 minutes
RESOLUTION: Issue 7039 resolved with proposal 1, remove wse:Identify w/o
<Bob> additional comments by Wu http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0004.html
Bob: Are we ok with the slicing of the issue.
Geoff: Concern with use of extension
... 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
Gil: Support the proposal.
Dug: Just required some tweaking to delivery element description.
Wu: Support Geoff concern...
... 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?
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 :-)
Geoff: When you add new elementâ€¦it may change behavior altogetherâ€¦not clear how these elements interact with other.
Dug: This is not a delivery specific problem. Need to be handled by subscription manager.
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
Wu: default is push, and xml is added to modify itâ€¦.need to know when the default is off.
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