19:28:47 RRSAgent has joined #ws-ra 19:28:47 logging to http://www.w3.org/2009/03/31-ws-ra-irc 19:28:49 RRSAgent, make logs public 19:28:49 Zakim has joined #ws-ra 19:28:51 Zakim, this will be WSRA 19:28:51 ok, trackbot, I see WS_WSRA()3:30PM already started 19:28:52 Meeting: Web Services Resource Access Working Group Teleconference 19:28:52 Date: 31 March 2009 19:28:53 +[IBM] 19:29:12 zakim, [IB is Dug 19:29:12 +Dug; got it 19:30:09 Ashok has joined #ws-ra 19:30:18 +fmaciel 19:30:32 gpilz has joined #ws-ra 19:30:56 Katy has joined #ws-ra 19:31:11 +Gilbert 19:31:31 agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0130.html 19:32:00 +[Microsoft] 19:32:19 zakim, [Micro is Asir 19:32:23 +Asir; got it 19:32:29 Gil - I just +1'd your idea for Mode attribute - I think that's a good compromise. 19:32:29 +??P14 19:32:34 zakim, asir has ram 19:32:34 +ram; got it 19:32:50 zakim ??P14 is katy 19:32:51 Ram has joined #ws-ra 19:32:59 +Vikas 19:33:02 +Ashok_Malhotra 19:33:03 zakim, ??P14 is katy 19:33:03 +katy; got it 19:33:16 +??P16 19:33:18 asir has joined #ws-ra 19:34:58 DaveS has joined #ws-ra 19:34:59 Scribe: Asir S Vedamuthu 19:35:09 ScribeNick:asir 19:35:14 Roll 15 folks on the call 19:35:19 Chair: Bob Freund 19:35:53 -??P16 19:36:02 -Asir 19:36:02 SUmeet has joined #ws-ra 19:36:11 dialing back in 19:36:19 pressed the wrong button 19:36:31 +[Microsoft] 19:36:41 +??P16 19:36:44 Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0130.html 19:37:03 Topic: Opening 19:37:07 Vikas has joined #ws-ra 19:37:16 Resolution: unanimously approved the minute from March 24th 19:37:36 Minutes are at http://www.w3.org/2002/ws/ra/9/03/2009-03-24.html 19:37:59 Bob: describing the * | # | X notation 19:38:33 Topic: Acceptance of New Issues 19:38:44 Bob - can you type the list? 19:38:58 New issue 6739 19:39:50 6739 accepted 19:40:02 Assigned to Dug 19:40:55 Infoset issues - WG wanted to review infoset notation for all specs prioring to adoption 19:41:36 Bob: looking for owners 19:48:10

ping 19:48:16 ping 19:48:21 pong 19:48:24 ping 19:48:27 ping 19:51:10 scribenick: Gil 19:51:11 Scribe: gpilz 19:51:13 asir has joined #ws-ra 19:51:16 am back 19:51:28 let me dump the missing buffer 19:51:29 Bob: looking for owners 19:51:30 No owners ... these issues are in the "wanted drivers" lot 19:51:30 Resolution: accepted issue 6739 19:51:30 Topic: New Snapshots and WD time? 19:51:30 Bob: time to create a snapshot 19:51:31 Bob: Yves is not on the call. Editors do not touch the drafts 19:51:31 scribenick: gpilz 19:51:33 Bob: plans to create a snapshot 19:51:34 ... goal is review the incorporation of resolved issues 19:51:36 q+ 19:51:39 s/is review/is to review/ 19:51:40 ... send your review comments to the WG mailing list 19:52:07 q+ 19:52:09 topic: 6730 19:52:18 ack asir 19:52:30 aisr: will diffs be provided as part of the snapshots? 19:52:51 dug: I can tag the CVS tree, Yves could produce diffs 19:53:07 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730 19:53:42 q+ 19:53:56 create a tag called "WD-2008-03-31" 19:54:14 ack ram 19:54:16 dave: at the time this was written this redundant text may have been necessary 19:54:28 ...: but, at this time, everyone knows how this works 19:54:41 ram: spec has to define what base behavior is 19:54:52 ...: extensibility behavior should be defined 19:55:08 q+ 19:55:40 ashok: are we asking to remove all occurences of this text? 19:55:45 ack katy 19:55:47 dave: remove it in all places 19:55:49 q+ 19:56:03 cant hear Katy 19:56:17 katy: if we are going to have this extensibility behavior specified, do we need to have it restated over and over? 19:56:25 ...: seems to make more sense just to state it once 19:56:29 ack dug 19:56:44 dug: I see Dave's point; even saying it once is redundant 19:56:58 q+ 19:57:02 ...: we've already defined how extenisbility points must work across all specs 19:57:03 q+ 19:57:10 ...: why is WS-Transfer special? 19:57:15 ack katy 19:57:22 Bob: is it true that none of the other specs have this language? 19:57:24 dug: yes 19:57:40 katy: don't want to do this unless it is specified across all specs 19:57:47 ack asir 19:58:21 asir: this outlines how to extend the transfer operations using the SOAP processing model 19:58:32 ...: we may need to refactor 19:58:39 Bob: how strong is your objection? 19:58:48 asir: I don't understand why we are removing this 19:58:57 repetition should be refactored 19:59:11 DaveS: the offensive text is repeating stuff that is already specified in the SOAP processing model 19:59:19 am not aware of anything hidden 19:59:31 ...: readers may wonder why we are re-stating this? is there some special wierdness that they are missing? 19:59:47 the important aspects are - use SOAP Processing Model and MUST NOT change teh base behavior 19:59:47 ...: it is worse than just being rendundant 20:00:00 ...: it is phrased slightly differently, which is bound to create confusion 20:00:09 ...: and possibly interoperability problems 20:00:13 Circumvention is not the intent 20:00:16 +1 to dave - it will confuse people - they'll wonder why we're repeating it - usually that's because something is different and that's not the case. 20:00:25 ...: may lead readers to the belief that WS-T is circumventing normal SOAP processing rules 20:00:31 q+ 20:00:40 ack ram 20:00:50 Bob: in the legal world, if you restate something that is already stated, you do so to draw attention to a special distinction 20:01:10 q+ 20:01:32 Ram: (agrees that there is a sense of redundancy and some repitition) 20:01:39 ...: perhaps we could re-factor? 20:01:41 q+ 20:01:43 we already have an extensibility section 20:02:08 section 2.4 of WST already has this info 20:02:17 http://www.w3.org/2002/ws/ra/edcopies/wst.html#extensions 20:02:18 not all 20:02:29 ack dave 20:02:31 That section does not capture all bits 20:02:38 - +0120756aabb 20:02:51 Doug: we talked about this on last weeks phone call - we added a section on extensibility to all the specs 20:03:10 DaveS: we need to outline where the extensibility points are 20:03:23 ...: but there is already a section on extensibility (added last week) 20:03:33 ack gp 20:03:52 q+ 20:03:54 Bob: we already have sections on extensibility in every spec 20:03:59 ack asir 20:04:03 ...: given that, how do people feel? 20:04:10 Ashok: I'm ok with it 20:04:18 asir: what is going to be removed? 20:04:25 DaveS: the exact text that is quoted 20:04:42 asir: I'm not sure about that 20:04:53 Ashok: he has the exact paragraph that he intends to take out 20:05:16 asir: I think there might be one or two words that are differnt in each paragraph 20:05:37 DaveS: you can clearly see which paragraphs are copies 20:05:50 dug: speaking as an editor, it is really obvious 20:06:01 asir: it is not the same text, so I don't know 20:06:12 dug: I'm pretty sure the editors can figure it out 20:06:17 Bob: so where do we stand? 20:06:38 asir: I propose that Dave provide us a detailed list of which paragraphs will be dropped 20:06:46 DaveS: have that by the end of the call 20:07:13 topic: 6499 20:07:33 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6499 20:07:49 dug: define an action URI for WS-Enum specifically 20:08:00 ...: WS-Enum is the only section that inlines fault definitions 20:08:11 ...: move these to a common section like all other specs 20:08:16 Bob: any questions? 20:08:27 Ashok: This would bring all 5 specs inline? 20:08:35 dug: w/respect to how faults are defined, yes 20:08:40 Ashok: excellent 20:08:44 vow! 20:08:46 and they rejoiced! 20:08:51 Bob: any objections to accepting 20:09:07 resolved: proposal to 6499 accepted by UC 20:09:13 topic: 6413 20:09:22 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413 20:09:45 Bob: I need to make sure that the text for all our proposals need to be on the W3C website 20:10:05 ...: I've copied the refernced material onto the W3C website 20:10:27 Katy: (go back to March F2F) merge WS-T and WS-RT 20:10:33 proposal at http://www.w3.org/2002/ws/ra/9/03/Issue-6413-2009-03-25.html 20:10:46 ...: key concern was what would be included etc. 20:11:01 ...: we took an AI to create a new proposal that just included the base WS-RT support in WS-T 20:11:20 ...: Doug, Dave, and I worked this and came up with the above proposal 20:12:02 ...: (describes proposal) 20:12:32 This OPTIONAL attribute, when present, indicates the dialect to be used in order to process the child element(s) of the wst:Get and the format of the wst:GetResponse element that is returned. This specification defines a standard dialect in Appendix A. Other dialects may be defined by other specifications. 20:12:32 A resource MUST generate a wst:UnsupportedDialectFault if it does not support the specified dialect. 20:12:32 When this attribute is not present, child elements of the wst:Get MUST be ignored. 20:17:57 dug: the addition of the dialect attribute on the 4 operations, aside from the fragment support, is a good thing for WS-T 20:18:27 ...: a dialect attribute helps to disambiguate some situations that are ambigious in WS-T 20:18:48 ...: e.g. "actual representation" versus "template constructor" 20:18:52 q+ 20:19:00 Bob: comments, reactions? 20:19:04 ack asir 20:19:28 asir: would like to walk through our objections (posted on email) 20:19:38 asire: (walks through objections) 20:19:58 HTTP has no influence on this WG. Neither the charter nor the Transfer specification mentions HTTP at all. 20:20:21 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0151.html 20:20:22 please stay within scope of the WG 20:20:59 s/asire/asir/ 20:21:38 fir example this one http://tools.ietf.org/html/draft-dusseault-http-patch-13 20:22:47 s/fir/for 20:23:06 q+ 20:25:59 Bob: anything that isn't implented by CR will get dropped 20:26:12 asir: these things will end up "at risk" 20:26:54 ...: we found that some WS-RT features are unclear, broken, dangerous and harmful 20:27:06 I don't recall what Asir said 20:27:15 ...: we don't recall asking for another proposal 20:27:29 Asir, pontification and repetition of history is not necessary 20:27:34 ...: this one seems to drop the controversial (???) feature 20:28:12 pontification is my relm 20:28:18 ...: it seems to add a new processing model based on attribute values instead of the standard SOAP processing model which is based on headers 20:28:27 but repeating (your own version of) history allows for more time to be wasted 20:28:50 ...: looking back at the F2F, it appears to us we need to (a) fix inconsistencies between WS-T and WS-RT 20:29:03 ...: (b) don't endanger the "sweet spot" 20:29:09 ...: (c) wider update? 20:29:34 ...: we need to continue to explore and invent partial updat features that compose well with WS-T 20:29:39 ...: we need to do this right 20:29:43 ...: fix isssues 20:29:52 ...: do not endanger the sweet spot 20:29:58 ...: do things right 20:30:06 ack katy 20:30:19 q+ 20:30:27 Katy: on the concerns that Asir has raised: these concerns were raised and acknowledged 20:30:39 ...: we've gone to great lengths to address them 20:30:44 q+ 20:30:55 ...: the fragment level support is optional and should not impact those that do not wish to support them 20:31:34 ...: huge parts of WS-RT are not in this proposal; none of the metadata, none of the qnames, none of the (??) dialect (i.e. the simplest dialect is the only one that has been pulled in) 20:31:48 ...: want to re-emphasize that this is an optional feature 20:31:50 ack ashok 20:32:01 Ashok: Asir, you quoted an IETF draft? 20:32:07 Bob: that was me 20:32:17 ...: Asire mentions "PATCH" 20:32:31 ...: that is a reference to the current draft for PATCH 20:32:45 asir: (history of PATCH) no uptake on this 20:32:57 ...: recently it seems like the Atom community would like this feature 20:33:12 But clearly there is "uptake" for fragment support in the WS* space since wsman and ws-fed use it 20:33:13 ...: I provided a lot of references on this 20:33:26 asir: Katy said she addressed all the issues 20:33:29 Wu has joined #ws-ra 20:33:34 ack asir 20:33:38 ...: one issue was addressed (the controversial boxcarring) 20:33:49 ...: a merger is a merger and we don't understand why we need a merger 20:34:10 ...: it has consequences and impacts other communities and we need to consult with those communities 20:34:21 Bob: we've heard one side w/regards to reservations 20:34:32 ...: is there someone willing to speak on the benefits 20:34:44 dug: two aspects 20:35:01 ...: (1) the definition of a dialect - generally useful for WS-T 20:35:04 q+ 20:35:16 ...: fragment support is a widely used feature in WS-MAN, etc. 20:35:30 q+ 20:35:40 ...: we need to provide guidance to the community on how to do this or we will end up with lots of different ways 20:35:45 ...: that would hurt interop 20:35:50 q+ 20:35:58 ...: we want a single solution that is shared across domains 20:36:07 ...: not domain-sepific solutions 20:36:33 Bob: if, at the end of this process, there isn't the proper number of impls 20:36:41 ...: this feature will be marked "at risk" 20:37:03 ...: this is true regardless of whether these features are part of a separate spec (WS-RT) or in WS-T 20:37:15 DaveS: does the same thing apply to optional features? 20:37:17 Bob: yes 20:37:29 ...: even if a feature is optional, we need to prove interop 20:37:41 ack asir 20:37:48 asir: that's an important point (interop or "at risk") 20:37:59 ...: none of the benefits result from merging 20:38:07 ...: they still have value 20:38:09 q+ 20:38:12 not true - we lose the linking of the features 20:38:16 q- 20:38:38 Bob: are you saying the dialect feature could be added regardless of frag support? 20:38:46 asir: yes, that could be in a separate spec 20:38:57 ack wu 20:39:10 Wu: I remember during the F2F meeting at Raleigh, this issue was discussed 20:39:25 ...: I saw a proposal that I thought was very good - we don't want to merge at this point 20:39:39 ...: develop each as a separate spec, and see if we want to merge at the end 20:40:18 ...: the important thing is to develop WS-T and WS-RT 20:40:36 ack dave 20:40:37 DaveS: value of including frag support in the main spec 20:40:58 ...: within the community there are a lot of different approaches to doing fragments at various levels in the stack 20:41:05 ...: this is about demonstrating leadership 20:41:06 q+ 20:41:24 ...: if we leave this out that leaves the ws community w/out guidance 20:41:42 ...: the proposal here is very conistent with ws architecture w/respect to identify a resource 20:41:52 ...: (no reference parameters, etc.) 20:42:27 ...: demonstrate leadership, uniform frag support, don't worry about implementations (they will come) 20:42:41 asir: leadership is not a function of merging 20:42:59 ...: people will take our leadership seriously 20:43:07 ...: leadership is not a function of merge 20:43:17 ..: leadership is not a function of merge 20:43:34 Bob: let's take a straw poll on the essence of the proposal 20:43:52 Yves is not here to represetn w3c 20:43:56 ...: everyone clear? 20:44:04 ...: "yes" is "in favor of" 20:44:06 q+ 20:44:14 ...: "no" is "not in favor of" 20:44:15 q+ 20:44:16 ack wu 20:44:27 Wu: it is very hard for us to make decisions 20:44:35 ...: because we don't know the consequences 20:44:56 q+ 20:45:21 q- 20:45:31 Bob: everyone clear? 20:45:38 Yves is not here to represent W3c 20:46:00 Oracle - yes 20:46:08 Microsoft - no 20:46:10 IBM - yes 20:46:20 Fujitsu - yes 20:46:25 SoftwareAG - yes 20:46:46 s/SoftwareAG/Hitachi/ 20:47:13 Avaya - abstain 20:47:23 -katy 20:47:35 SoftwareAG - yes 20:48:15 Bob: one 'no', a bunch of 'yesses' and one 'need more time' 20:48:16 Yves is not here 20:48:21 ...: Wu, would one week do? 20:48:44 am very concerned about how we build consensus 20:48:46 Wu: two weeks would be great 20:48:56 q+ 20:49:01 Bob: we'll give Avaya two weeks 20:49:09 q+ 20:49:14 ...: in the meantime, maybe we can move closer to consensus 20:49:20 ack asir 20:49:25 asir: it's too late 20:49:29 +katy 20:49:34 ...: I wanted to mentioned that yves is not here 20:49:42 ...: we don't seem to be building consensus 20:49:44 ack dave 20:49:55 DaveS: point of order - I've posted an update to our previous issue 20:49:57 Wu: 20:50:04 ack wu 20:50:19 Wu: I would also hope that IBM and Microsoft could communicate on this issue - that would help us 20:50:23 -fmaciel 20:50:39 topic: 6730 20:51:37 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730\ 20:51:44 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730 20:52:06 DaveS: (describes update) 20:52:23 q+ 20:52:26 ...: the text to be removed is definitely redundant 20:52:36 Ram: thanks to Dave Snelling 20:52:39 ...: it looks fine 20:52:41 ack ram 20:52:46 ...: I have one question 20:53:03 ...: Section 2.4 of the editors copy talks about extension points 20:53:18 ...: I was wondering if this notion of extension points has been identified in WS-T 20:53:30 DaveS: this issue was solved a couple of calls ago 20:53:38 xs:any and ... are the extension points 20:53:44 ...: all specs call out what their extension points are 20:53:57 Ram: have the extension points for WS-T be described? 20:54:06 ...: I'm fine with Section 2.4 20:54:17 ...: but I'm worried about extension points 20:54:30 ...: I'd like to look at the proposal and reply by email 20:54:42 Bob: we don't usually decide things by email, would you like more time? 20:54:49 Ram: can we wait a couple of days? 20:54:57 DaveS: it's a simple thing 20:55:04 (other): concur 20:55:12 q+ 20:55:27 Bob: I recognize that some folks may need to talk to the mother ship, but this issue has been kicking around a while 20:55:38 ack ram 20:55:42 Ram: it is generally good to have a concrete proposal a couple of days before the call 20:55:49 DaveS: the original proposal was precise 20:55:58 q+ 20:55:59 ...: people just called on more precision for this call 20:56:05 asir: can we have a week 20:56:15 Bob: yes, but any more time is going above and beyond 20:56:17 ack ram 20:56:27 q+ 20:56:39 yyi,ms7ik8yhsdkyujuau7jmkyyhjunmyu7jhnm 20:56:58 ack ram 20:57:18 DaveS: could people actually talk to their product people? 20:57:48 ...: because it seems unlikely that anyone asked their product people about the previous incarnation 20:57:58 http://www.w3.org/2002/ws/ra/BugzillaReports.html 20:58:03 dug: if people need more detail, they should say so before the concall 20:58:19 ...: not wait until the day of the concall to say they need more detail 20:58:37 Bob: people should look at the issues with proposals and be prepared to discuss them 20:58:53 ...: it seems that people are capable of using the email list to discuss proposals 20:59:12 ...: when I don't see any debate, I get the feeling that people are in general agreement 21:00:48 -Gilbert 21:00:49 -Dug 21:00:50 -Tom_Rutt 21:00:51 -Bob_Freund 21:00:53 -[Microsoft] 21:00:56 -Vikas 21:01:02 -Ashok_Malhotra 21:01:03 -??P16 21:01:10 -katy 21:01:31 rrsagent, make logs public 21:01:49 - +1.212.642.aaaa 21:01:51 WS_WSRA()3:30PM has ended 21:01:53 Attendees were +1.212.642.aaaa, +0120756aabb, Tom_Rutt, Bob_Freund, [IBM], Dug, fmaciel, Gilbert, [Microsoft], ram, Vikas, Ashok_Malhotra, katy 21:02:16 rrsagent, generate minutes 21:02:16