See also: IRC log
<trackbot> Date: 21 July 2009
<Bob> trackbot, start telecon
<trackbot> Meeting: Web Services Resource Access Working Group Teleconference
<trackbot> Date: 21 July 2009
<Bob> scribe: Paul Nolan
<Bob> scribenick: paul
Agenda accepted
RESOLUTION: Minutes of 2009-07-14 approved w/o
Wu: proposal for 6401 will be ready for F2F
gpilz: feels the proposal is far from complete
Bob: F2F. Please register before 28th July
<Wu> welcome to drop us an email and we will try to address it.
Geoff: Shall we have a group dinner?
All: depends on wine list
<dug> I assume breakfast will be served, right?
<Geoff> yes
<dug> great -thanks
<dug> +1 to all of us at your photo shoot
RESOLUTION: New Issue 7122 opened with No objections
<asir> 7 seconds
RESOLUTION: Resolve Issue-7122 with the proposal in Bugzilla
<dug> We should mandate wsdl2.0 :-)
<Yves> :)
<Bob> I hope not
Tom: multi-part messages should not be included
Wu: suggested change to Dougs proposal should only be small
<DaveS> Dave agrees with Geoff
<dug> +1 to Geoff
Geoff: Shall we agree to the proposal and open a new issue for Wu's concern?
<gpilz> +1 to Geoff
Wu: agrees with proposal in
principle.
... minor alteration was discussed
Tom: feels Wu's issue should be handled sperately
Gil: agrees with Geoff. Lets not hold up the proposal over this new concern
Wu: woul rather agree to the proposal and deal with multi-part messages later
Tom: we need to discuss whether multi-part messages should be raised as an issue
Bob: Any objections to accepting the proposal and opening a new issue for multi-part events?
<DaveS> +1 to not expanding the scope of the issue.
<gpilz> +1
Geoff: lets see the proposal for the multi-part messages first
<dug> as issue owner, I disagree, this is just about XPath over the raw event data itself - single part
<gpilz> +1 to Tom
<DaveS> +1 to Tom
<Ashok> +1 to Tom
Tom: this multi-part extension is a bigger issue than implied
Doug: there has been plently of time to raise this issue
Bob: if Wu's concern is controversial we should perhaps not wait another week before deciding whether to raise it as a new issue
Gil: why not close the main issue?
<dug> And that same member has asked for a week, got that week - so let's move on
Bob: if we had straw poll would this help ?
<Tom_Rutt> If we add a statement "if multipart notifications are used" implies that we agree to support multi part notificaitons. This impacts other issues (e.g., 6401) and other text, so I do not want this issue to have a resolution which implies support for multipart
<dug> we're discussing an unknown friendly amendment - don't see what the straw poll will solve?
<gpilz> +1 to Tom; I object to anything that indicates an Event Source might emit multi-part messages
Tom: Wu's change implies support for multi-part
Bob: will anyone implement multi-part?
Doug: lets please split these issues
Wu: is Doug's proposal implying single part?
Doug: it implies neither single or multi-part
<Tom_Rutt> my major concern about multipart, allowing some of the notification content to be in header severly impacts any implementations of federation with other implementation choices to relay notifications (e.g. JMS) It will severly impact such implementations (outside the scope of ws-eventing)
Wu: accepts that since Doug's proposal does not address XX-part messages he can accept it and raise a new issue
RESOLUTION: Resolve Issue-6980 with the proposal in bugzilla. A new issue may be opened for multi-part events
<dug> +1 to cwna
Geoff: perhaps this can be closed with no action
RESOLUTION: Resolve Issue-6711 by closing with no action w/o
Geoff: we are happy to close with no action
Doug: likes wrapper, it adds etensibility point
<gpilz> +1
Geoff: this issue depends on
7015?
... resolution will need to be consistent across these issues
Doug: it just needs to be right
<asir> Not understanding the difference
Dave: what is use case for request extensibility?
Doug: types of data perhaps or information about the metadata
Bob: can we resolve by adopting the proposal?
RESOLUTION: Resolve Issue-6500 by accepting proposal in bugzilla
Ashok: deals with mex dialect and recursive links
Asir: there is a good example for this dialect
<dug> "This value indicates the type of the metadata contained within the Metadata Section. When used in conjunction with Metadata Reference or Location, this allows the inclusion of metadata by reference."
Doug: the wording of the issue does not metion mex dialect
<asir> Here is the full text
<asir> This value indicates the type of the metadata contained within the Metadata Section. When used in conjunction with Metadata Reference or Location, this allows the inclusion of metadata by reference.
<dug> .. /mex:Metadata/mex:MetadataSection/@Dialect ="http://www.w3.org/2009/02/ws-mex/Dialects/ws-mex"
Asir: this text needs clarification
<dug> can we get an ETA?
<scribe> ACTION: asir and Ashok to modify test by 07/28 [recorded in http://www.w3.org/2009/07/21-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-84 - And Ashok to modify test by 07/28 [on Asir Vedamuthu - due 2009-07-28].
Yves: to address 6533 by mid august (Action-45)
Geoff: 6551 no progress
Doug: shall we close with no action
Geoff: agree
RESOLUTION: Resolve Issue-6551 by closing with no action
Doug: will address 6694 by F2F (Action-87)
Yves: 7013 partial put and versioning. Will address by mid August (Action-67)
<scribe> ACTION: Doug 7068 addressed by F2F (Action-85) [recorded in http://www.w3.org/2009/07/21-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-85 - 7068 addressed by F2F [on Doug Davis - due 2009-07-28].
<Bob> 6403 ai re-assign to Asir
<scribe> ACTION: Asir to address 6403 by mid August (Action-86) [recorded in http://www.w3.org/2009/07/21-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-86 - Address 6403 by mid August [on Asir Vedamuthu - due 2009-07-28].
Bob: Ram, Dug How are we doing on 7088?
Ram: Progress is being made, no date yet
Adjourned