See also: IRC log
<trackbot> Date: 28 April 2009
<Bob> trackbot, start conference
<trackbot> Meeting: Web Services Resource Access Working Group Teleconference
<trackbot> Date: 28 April 2009
<Bob> scribe: Ashok
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0169.html
<dug> LOL
Bob: Add 2 new issues to agenda
<Bob> http://www.w3.org/2002/ws/ra/9/04/2009-04-21.html
Minutes from April 21 approved w/o objection
Can we open the 2 new issues and assign to the opener, Doug!
Katy: We have a compromise proposal. We shd be ready next week.
Yves: Where are the emails re. 6413
Katy: We had a telcon
<dug> Yves - it was private email
Geoff: I want to ask abt mssion of
the TF
... is it the mission to create a new spec called, say fragments
and how this works with WS-T
Bob: I expect TF to come back with proposal acceptable to TF and hopefully by the rest of the WG
<Katy> 1+
Geoff: Shall we solve the technical issues?
Dug: We have had lots to discussion ... the TF has to come up with a compromise that is acceptable to IBMand MS and hopefully by the rest of the WG
Geoff: We agreed that there wd be a spec called 'transfer' ... shouldn't that be the starting point
<Yves> I remember saying last time that the ideal place for fragments was... in addressing, close to EPR definition, so having a standalone spec is the best match
Katy: I think the key is to come up with an acceptable proposal
Bob: Let's not talk abt this further until the TF comes back to us
Dug: Strictly editorial
... they use ... for extensibility. Shd use xs:any for
extensibility
<dug> and they rejoiced
RESOLUTION: Accept Dug's proposal in bugzilla to resolve 6787
No changes since last week.
Geoff: We have some comments. We shd create some concrete text.
Bob: ETA?
Geoff: Try for next week
<scribe> ACTION: Geoff to create a conterproposal for 6403 by next week [recorded in http://www.w3.org/2009/04/28-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-60 - Create a conterproposal for 6403 by next week [on Geoff Bullen - due 2009-05-05].
<dug> Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0127.html
Gil: Wanted to get everyone on board
Geoff: WS-PAEPER not necessary
Ashok: Why is there a <Policy> element child of EPR
Li: Generally in agreement with Gil's approach
<asir> I did not understand Ashok's question
Asir, see section 7 of MEX... look at the EPR example ... why are there <Policy> and <Metedata> children for the EPR. No need for <Policy>
li: We have friendly amendements on Gil's propsal and wd like to separate out Policy Negotiation
<asir> awesome Gil!
Gil: Li, Wu and I shd discuss and prepare actual text
<scribe> ACTION: Li and Gil to prepare text by next week [recorded in http://www.w3.org/2009/04/28-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-61 - And Gil to prepare text by next week [on Li Li - due 2009-05-05].
<Zakim> asir, you wanted to answer Ashok's question
Geoff: If we remove <policy< element then we do not need WS-PAEPER?
Ashok: Correct
<asir> Ashok - it appears that is already taken down in the editors' draft, see http://www.w3.org/2002/ws/ra/edcopies/wsmex.html#Metadata-in-Endpoint-References
<dug> phew - I was looking and I couldn't find it
<asir> Good job cleaning up Doug!
TAG will not raise issues on our work
Asir thanks Bob for getting this resolved early
Remove 'mode' from Eventing
Wu: I would like to move on to other issues. This has been extensively discussed. Semantics of WS-Eventing may change based on other issues
Bob: Which issues block this?
Wu: 6432
Bob: I think 6432 is blocked by this one
Wu: I think 6432 goes first
Gil: I don't think 6432 blocks this. It's orthogonal.
Bob: When we spoke abt 6432 last week the issue of 'mode' kept coming up. Let's pick one to solve first.
Wu: We are thinking of proposal for 6432
<dug> brb dog is throwing up....
<scribe> ACTION: Wu to provide new words for 6432 by May 8, 2009 [recorded in http://www.w3.org/2009/04/28-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-62 - Provide new words for 6432 by May 8, 2009 [on wu chou - due 2009-05-05].
DaveS: Why don't we discuss the other one first
<asir> Don't understand where we are?
DaveS: move on 6692
<dug> back
DaveS: Argues why we don't need mode
<gpilz> http://www.w3.org/2002/ws/ra/wiki/Redundant_Extension_Points
<asir> I thought Bob asked Dave to describe where we are re 6692 discussion
<dug> Mode is broken and no one has refuted my points in: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html
Geoff: Mode acts as selection
mechanism
... but we need to move forward. I've been thinking about a
proposal
<asir> a mechanism for a subscriber to specify a delivery mode to an event source!
Geoff: MS is absolutly for a selection concept. Client needs to be able to select the mode.
Wu: I propose we shd keep it in. You don't have to use it.
Bob: How do we move forward ... need some compromise
<asir> of which specification?
Gil: I posed a challenge ... I will
show an alternative method for extension that will be better that
'mode'. No one took me up on that.
... We are within SOAP. No one will implement enevting outside of
SOAP
... real issue is about code preservation
... Mode is like a rounding error ... many other issues involved in
implemening latest WS-Eventing spec
<gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0116.html
DaveS: I want Eventing to stay clean
... if it defines a single mode then that the default mode.
... delete mode and allow attribute extensibility.
Wu: Need specific words... do we maintain fault msg?
DaveS: I don't want to wait. I would like a vote on a direction tonight.
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html
Dug: Please respond to this note. I argued that 'mode' has problems. We have 2 mechanisms for extensibility. It's fundamentally flawed
Wu: I responded
<gpilz> "lots of ways" leads to WS-Man 1.0 Chapter 7.
<gpilz> read it and be afraid
<TRutt> As Dave S stated, the ws eventing spec only defies a simple push delivery semantic. I see some of the proposal allowing use of a consistent use of an xs:any extension element (e.g, http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0055.html ) to subscribe element def to express the same capability of the mode attribute, I do not understand how this would not enable groups such as ws man to use it to give the same capability that their mod
<TRutt> As an alternaive, ws-eventing users might also decide to use other ws-* mechanisms to give these "mode" like capabilities (e.g, ws man could decide to use ws-rm as an alternative to provide the equivalent capabilities of their "push with ack" mode.
Trutt: We can extend in many ways. Supports Dave
<dug> harry?
Geoff: Don't see this as an extension mechanism. See it as a selection mechanism
<Wu> link to my response: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0033.html
Geoff: we have nothing to vote on. We have many proposals on the table
<asir> ~ 7-9 proposals out there, I think
<scribe> ACTION: Geoff to list all the different proposals for 6692 and their pros and cons. In next 2 days. Seperate proposals and argument. [recorded in http://www.w3.org/2009/04/28-ws-ra-minutes.html#action04]
<trackbot> Created ACTION-63 - List all the different proposals for 6692 and their pros and cons. In next 2 days. Seperate proposals and argument. [on Geoff Bullen - due 2009-05-05].
<gpilz> geoff, you're going to do this on the Wiki, correct?
Dug: Discusses wording changes
No objection to proposal.
<Geoff> Gil - Iwas planning to just send an email with the proposals
RESOLUTION: Issue 6788 resolved with proposal in Bugzilla
<gpilz> Bob directed us to use the wiki
<gpilz> and I think that idea has some merits
<gpilz> in that we can co-edit the proposals
<gpilz> Geoff: here's the Wiki page: http://www.w3.org/2002/ws/ra/wiki/index.php?title=Proposals_for_6692&action=edit
Katy: We have another issue for implicit operations
<Katy> (for policy attached to implict operations)
Bob: Please make comments on the scribing.