See also: IRC log
<Yves> trackbot, start telcon
<trackbot> Date: 10 February 2009
<Bob> scribe: Mark Little
<Bob> scribenick: marklittle
<Bob> chair: Bob Freund
<scribe> chair: comments on agenda?
<scribe> chair: no comments. agenda approved.
<scribe> chair: comments on minutes? no objection to approving. minutes approved.
RESOLUTION: Minutes from 2009-01-27 approved
<scribe> chair: no objections.
RESOLUTION: Minutes from 2009-02-03 approved
<scribe> chair: clarification of timing of 2009-03-10/12 f2f and possibly changing date. doug agreed that it could be moved.
<scribe> chair: proposes to keep date as scheduled March 10th through 12th.
asir: he and Geoff can't make it last day, so could we change the agenda to substantive work done of the first couple of days.
<scribe> chair: asks for opinions. any objections on mon, tue, wed meeting instead? or shortening to 2 days (tue wed).
<scribe> chair: proposes to put agenda together and try to put less important issues to end of meeting. those who can't make last day check agenda and flag issues with it against timing.
general discussion about logistics and planning. no firm opinion against chair's proposal.
<scribe> chair: status on http://www.w3.org/2002/ws/ra/tracker/actions/2
li: proposal incorporating comments from group done.
<scribe> chair: ok, AI2 can be closed.
<scribe> chair: still open.
<scribe> chair: AI4 can be closed. AI5 too. +AI6.
<scribe> chair: Action item 7? http://www.w3.org/2002/ws/ra/tracker/actions/7
Ashok: wants to talk about it for a few minutes.
<scribe> chair: discuss now or at f2f?
Ashok: discuss now.
<scribe> chair: try to add to agenda today.
<scribe> chair: Approval of docs as FPWG Drafts
<scribe> chair: wants all commentary to occur early enough so we can affect changes in advance of next week's meeting. want to be able to approve them as first public working group draft next week. has everyone reviewed them?
<scribe> chair: asks for any concerns. gets none. we will approve them next week.
<scribe> chair: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6533
Yves: describes issue about safeness properties in WS-Transfer.
<scribe> chair: any objections to accepting? none heard. Accepted.
<scribe> ACTION: Yves as owner of 6533. [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-8 - As owner of 6533. [on Yves Lafon - due 2009-02-17].
<scribe> chair: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6548
Geoff: described reasoning behind issue - make WS-RT less management specific these days than it may have been in the past. Try to update the specification. editorial.
<scribe> chair: any discussion? none. any objection? none. accepted.
<scribe> ACTION: Geoff as owner of 6548 [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-9 - As owner of 6548 [on Geoff Bullen - due 2009-02-17].
<scribe> chair: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6549
Geoff: appears that RT-create verb is too restrictive, e.g., create a resource "like" another resource would appear to be prevented by the current wording.
<scribe> chair: any discussion? none. any objection? none. accepted.
<scribe> ACTION: Geoff as owner of 6549 [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-10 - As owner of 6549 [on Geoff Bullen - due 2009-02-17].
<scribe> chair: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6550
Geoff: PUT operation prevents node-set result sets.
<scribe> chair: any discussion? none. any objection? none. accepted.
<scribe> ACTION: Geoff as owner of 6550 [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action04]
<trackbot> Created ACTION-11 - As owner of 6550 [on Geoff Bullen - due 2009-02-17].
<scribe> chair: asks Geoff to kick of mail discussion on 6550.
<scribe> chair: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6552
<scribe> chair: accepted.
<scribe> ACTION: Geoff owner of 6552 [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-12 - Owner of 6552 [on Geoff Bullen - due 2009-02-17].
<scribe> chair: Geoff to kick of mailing list discussion.
<scribe> chair: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6551
<scribe> chair: expresses opinions on timing in general around this issue.
Lamport!
http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf
chair accepted 6551 as no objections.
<scribe> ACTION: Geoff as owner of 6551 [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action06]
<trackbot> Created ACTION-13 - As owner of 6551 [on Geoff Bullen - due 2009-02-17].
Doug: asks to defer for better proposal formulation. Discuss after 6398. Would like to move it off today's agenda entirely.
asir: are complexities referred to in 6413 captured as new issues?
dug: not sure. will investigate.
Geoff: point number 2 (from last week) cardinality of create. treat it as separate issue from wrapper issue. we believe this affects backwards compatibility. lots of ws-transfer issues that would be adversely affected by this.
dug: changed cardinality such that extension specifications can sit on top and believes it is backwardly compatible. existing implementations can just add a wrapper. no problem with breaking existing implementations.
Geoff: disagrees. you must provide at least one element in create. servers expect that there will be one. But if we say can be zero then servers won't be able to cope with this change. name space changes don't break application code. this issue will break the application code.
dug: we should not avoid making changes because they may break backward compatibility in general. should be addressed on a per case basis. in this case, if a service doesn't support the notion of an empty create then it's not that hard to thrown in an 'if statement'. this should/could be treated as a fault anyway. the benefits outweigh the disadvantage. nice migration path.
<gpilz> +1
+1
Geoff: less of a migration path to change rt?
dug: it's an option.
<gpilz> ?help
dug: the notion of a default constructor is missing currently and that's a hole in the current specification.
+1 to dug (again).
<scribe> chair: any further discussion on 6398?
Geoff: want to discuss higher level issue. some discussion about alignment between transfer and http and what it all means. would like to discuss that further if possible?
<scribe> chair: alignment came from TAG. action item to tag to be more specific. no feedback yet so we would be anticipating what they might say.
Geoff: nope.
asir: 6398 backward compatibility is only one aspect. where are we with the issue as a whole?
<scribe> chair: fundamental point is the inclusion of a wrapper. but discussion has branched off from that on alignment with http, backward compatibility as well. lots of discussion. we seem close to determining a proposal.
asir: disagrees. not sure that we are close at all.
<scribe> chair: close to proposal. not necessarily close to agreement.
<Yves> if the wrapper is meaningless, why giving meaning by having multiple names?
<asir> -1 they are not separate
dug: not much disagreement about whether a wrapper impacts anything. believes general agreement that this doesn't hurt anything. Yes, cardinality may be an issue. higher level issues remain around alignment. but they are separate issues. the wrapper doesn't impact that either way. would prefer to have them addressed as separate issues so we can track them and deal with them through that route.
Ashok: agrees with dug that the issues are separate. speak about envelope separately from alignment with http.
Geoff: disagrees. there is an existing connection between transfer and http. the names of the verbs, separation of verb and message, a connection and alignment exists. current specification agrees with http. the current proposal adds a wrapper inside SOAP body. Why? To support BP 1.1. but BP was defined before addressing and no action verbs. This issue was solved in BP by an outer element surrounding the SOAP body. This proposal is about that BP 1.1 ap
<scribe> chair: asks Geoff is he sees possibility of transfer being used over a non-HTTP transport
Geoff: yes. anything SOAP supports.
gpilz: calls into question supposed alignment between transfer and http. analogy between 4-wheel drive and F1 car (similar but not the same thing.) Where is the technical case for why they are aligned?
<dug> super-charging a 4-runner would be a good idea
<Ashok> There is a SOAP over JMS standard now
<scribe> chair: interrupts because notion of aligning with http came from interpretation of TAGs comments.
dug: does not think chair is correct. thinks TAG was speaking about a parallel because the same verbs are being used.
<asir> we are talking about the current Transfer alignment with HTTP (regardless of TAG's thinking
<scribe> chair: we need to understand the TAG points in more detail before we go further with trying to align anything with the Web or HTTP. Believes the WG does not have alignment as a goal.
<asir> Geoff's point is the current proposal for 6398 disrupts the current alignment between Transfer and HTTP
gpilz: yes, that is my understanding too.
<Bob> although the chair believes that we must respond to issues raised by the tag or anyone else
<dug> yes bob but that's about eprs not wrappers
<dug> or even verbs
<asir> Gil but not the way Transfer uses WS-A action
<TRutt> ws-i BP 1.2 and 2.0 (which include ws-addressing) define the operation signature as the combination of wsa:action value and the specified child element of the soap:body. If we want to be able to have a ws-transfer spec which can be described in WSDL ( to allow potential for other transports than http, which ws-* is intended to allow) and to allow extensions to add extension body content for messages such as a get request, the wrappers become relevant.
<scribe> chair: invites TRutt to speak as expert.
Katy: go back to Geoff's point that adding wrapper creates implied semantic meaning, but believes that is incorrect. just state that there is no semantic meaning.
<Zakim> asir, you wanted to respond to Tom
dug: even if people did interpret body, so what? most/all WS stacks have something in the body that's meaningful and is related to action. Who really cares? but the link between transfer and http does not exist in the specification. it's interesting that the TAG has mentioned a parallel, but that's not mentioned anywhere in the current specifications. the alignment isn't important.
asir: transfer was a protocol for creating and deleting web services resources. was modeled after http. the verb names are not coincidental.
<gpilz> parallel != connected
<scribe> chair: did the authors intend to model http with transfer?
asir: other way round ;-)
<gpilz> Yves: if it helps make you $$, yes
asir: yes they modeled transfer on http.
<dug> yves - maybe since hopefully one day you'll stop since you'll be dead :-)
asir: TRutt definition does not say that you need a distinct wrapper. Just need the element for backward compatibility.
<Yves> gil, make money fast, or make money in the long term? :)
<scribe> chair: we are supposed to be aligned with BP in our charter. so could Geoff or asir make a proposal on how to align transfer with BP 2712. how would you do it?
<scribe> chair: asks asir to take an action to generate proposal and put it on the mailing list.
Geoff: accepts action.
<scribe> ACTION: Geoff to take proposal on defining another approach. [recorded in http://www.w3.org/2009/02/10-ws-ra-minutes.html#action07]
<trackbot> Created ACTION-14 - Take proposal on defining another approach to the resolution of Issue-6398. [on Geoff Bullen - due 2009-02-17].
dug: does not agree with course of action because this has dragged on far too long. why not resolve it today and reopen if another proposal comes along later/
<asir> Thanks Bob!
<scribe> chair: no, once an issue is closed then would prefer to keep it closed.
dug: ok, can we have a firm date for propsal?
+1
<scribe> chair: one week from today for the proposal?
<scribe> chair: makes due date for February 20th. Discuss (and vote) on 24th of February meeting.
Ashok: after reading up still not sure how to address the issue. they are worried about how services are identified - not by URIs but by EPRs. Very fundamental thing. not sure what we can do about this.
Ashok: they want to be able to treat an EPR like a URI. What happens if you do a GET on a URI extracted from an EPR? what do I ask them now?
didn't we have this same conversation during WS-A days?
dug: what if ws-t says that eprs have no meaning relative to identity. and supporting "naked" GET has semantics of transfer GET. Would that address TAGs concerns?
Ashok: thinks that might be fine.
asir: the TAG make the same concerns during the charter phase of the working group. Microsoft asked for concrete details at the time.
asir: TAG concerns down to alignment of transfer with http. what would really help is have the TAG explicitly articulate their concerns.
<Ashok> Note from Stuart Williams Non 12, 2008
<Ashok> FYI, during their distributed meeting of the 6th November 2008, the TAG reached concenus on the following resolution [1] which is relevant to the recently announced [2] "Web Services Resource Access Working Group" [3]. "RESOLUTION: Regarding the WS-Transfer submission: (1) We agree with the Team Comment (http://www.w3.org/Submission/2006/04/Comment) noting that WS-Transfer resources are potentially identified by more than just a URI, making them unsuitable for
<asir> I am not sure how to turn this text into WS-RA technical issues
Ashok: does not believe that the TAG concerns are vague.
<dug> unsuitable for referencing and use in other Web technologies, e.g. in the context of traditional Web links or RDF assertions.
<Ashok> http://lists.w3.org/Archives/Public/www-tag/2008Nov/0008.html
<dug> Team comments: http://www.w3.org/Submission/2006/04/Comment
<Ashok> [1] Team Comment: http://www.w3.org/Submission/2006/04/Comment [2] TimBL: http://lists.w3.org/Archives/Public/www-tag/2006Oct/0061.html
<li> http://www.w3.org/Submission/2006/04/Comment is broken
gpilz: re dug's proposal and ws-eventing issue 6425.
<li> ok, the new one works. thanks.
<asir> that sounds like overriding WS-A Metadata Recommendation
<dug> gil - but WS-Eventing isn't meant to align with HTTP :-)
asir: we don't know how to translate TAG issues into technical issues for the working group.
<scribe> chair: agrees with TAG.
<gpilz> dug - don't tempt me to raise a bunch of issues about aligning WS-Eventing with JMS
<gpilz> JMS has a subscribe, WS-Ev has a subscribe
<scribe> chair: a response can be as simple as 'OK' through to let's rearchitect everything.
<gpilz> JMS sends notifications, WS-Ev sends notifications
<gpilz> they're aligned!!
asir: TAG has good influence in W3C so need an appropriate response.
<dug> you should - clearly ws-eventing was written to align with jms
<TRutt> Ref parms are not for identity, they are to allow needed soap headers to be sent on the wire
<scribe> chair: agrees. say that they cannot be used "on the Web".
TRutt: makes it clear that reference parameters are not for identity purposes.
asir: just looked at TAG agenda. this item is on the agenda. (Ashok requested it.)
<scribe> chair: let Ashok know what to ask TAG *before* the meeting.
Ashok: believes that the TAG has been clear and not sure what else they could say to be clearer.
dug: glad that Ashok is going to the meeting and not him.
<scribe> chair: Ashok could ask 'what if the WG says "you are correct"?' for example.