Web Services Resource Access Working Group Teleconference

<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.

6401

Wu: Requirment document published in group.

Gil: Why do we need a separate BP compliance requirement?

Wu: Clarified

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

6413+6975+7014

<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 [1] "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

<dug> geicko?

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 [1] 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].

Issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=7039

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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692

<Bob> summary http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0002.html

<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 point.
... 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?

<Tom_Rutt> queue

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.

<Tom_Rutt> s/alonge/alone/

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

<Bob> Adjourned

<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