15:36:18 RRSAgent has joined #ws-ra 15:36:18 logging to http://www.w3.org/2009/06/11-ws-ra-irc 15:36:20 RRSAgent, make logs public 15:36:20 Zakim has joined #ws-ra 15:36:22 Zakim, this will be WSRA 15:36:22 ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start 6 minutes ago 15:36:23 Meeting: Web Services Resource Access Working Group Teleconference 15:36:23 Date: 11 June 2009 15:42:08 Paul has joined #ws-ra 15:46:53 Bob has joined #ws-ra 15:47:11 trackbot, start teleconference 15:47:13 RRSAgent, make logs public 15:47:15 Zakim, this will be WSRA 15:47:15 ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start 17 minutes ago 15:47:16 Meeting: Web Services Resource Access Working Group Teleconference 15:47:16 Date: 11 June 2009 15:47:59 rrsagent, this meeting spans midnight 15:49:53 WS_WSRA(3 day)11:30AM has now started 15:50:00 +??P7 15:50:15 Geoff has joined #ws-ra 15:50:32 zakim, ??P7 is Oracle 15:50:32 +Oracle; got it 15:50:54 asir has joined #ws-ra 15:52:22 + +0208234aaaa 15:52:45 zakim, aaaa is Paul 15:52:45 +Paul; got it 15:53:40 zakim, Oracle has Yves, Geoff, Bob 15:53:40 +Yves, Geoff, Bob; got it 15:54:13 zakim, Oracle has Asir 15:54:13 +Asir; got it 15:54:29 Tom_Rutt has joined #ws-ra 15:54:47 zakim, Oracle has Tom 15:54:47 +Tom; got it 15:56:39 Vikas has joined #ws-ra 15:56:58 dug has joined #ws-ra 15:59:58
  • li has joined #ws-ra 16:00:00 zakim, Oracle has Prasad, Wu, Ram, JeffM 16:00:00 +Prasad, Wu, Ram, JeffM; got it 16:00:10 +Bob_Natale 16:00:27 +Vikas 16:00:55 +li 16:01:54 Ram has joined #ws-ra 16:02:13 Not knowing who is chairing or who scribed recently, I propose Ram 16:03:28 Scribe Ram 16:03:44 Wu has joined #ws-ra 16:03:58 chair: Bob Freund 16:04:24 scribe: Ram 16:05:09 PrasadY has joined #ws-ra 16:06:28 Ashok has joined #ws-ra 16:07:42 Doug: Yesterday, when we talked about 6712, we removed the implied value. But we need to define an implied/default value for interop. 16:07:48 This specification defines one ContentDescription URI, http://.../ContentDescription/Representation, to indicate that the child element is the literal representation of the resource. 16:08:21 Gil: Should this be another issue? 16:08:41 Dug: If this can be handled editorially, no need to open a new issue. 16:09:38 Dug: It is encumbent upon us to define an default URI, if the contentDescription hint is used. 16:09:50 Geoff: I need a little time to think about this. 16:10:06 Bob: OK. We will give Geoff more time and come back to this later. 16:10:12 PrasadY has joined #ws-ra 16:10:17 Issue 6401 discussion. 16:11:33 Gil: One of points of consensus yesterday was that existing WSDL tools be able to handle writing event sinks. 16:12:38 Gil: Recap: It is important to advertise notification types. As a developer, I should be able to look at a event source and identify the notifications. It is important to do this using existing WSDL based tools. It becomes murky when we talked about wrapped vs raw. 16:12:56 q+ 16:12:57 Gil: We need to re-examine the approach of wrapped notifications and think it over. 16:13:33 Geoff: Is the definition of notification a subset of message types? 16:14:03 Gil: Notification is defined to a SOAP message. Section 5 says notification can be ANY message. A subset of all notifications that exist out there can be described using a type. 16:14:22 q+ 16:14:59 Gil: Two notifications can have different wire contents and yet still have the same type. For example, one of them could be raw and the other wrapped. 16:15:25 Geoff: Is your description language describing any possible notification? 16:15:33 Gil: No. 16:15:39 Geoff: Is that a problem? 16:16:01 Gil: By describing a large subset of things you want to do, we can accomplish what is reasonable. 16:16:36 Gil: Are there any important use cases that cannot be handled by my approach? 16:17:08 Doug: Can anything that appears in a WSDL can appear as a notification? 16:17:30 Gil: This proposal has the effect of constraining which WSDL operations can appear as a notification. 16:17:47 Gil: With my approach, we cannot have application content in a SOAP header. 16:18:24 Dug: That is not correct. Your thing is not about wire presentation and hence it does not constrain. 16:18:30 Gil: Yes. 16:18:57 q? 16:19:39 Geoff: I understand that. It appeared that the description language could not describe all things I could do in the WSDL. 16:20:20 Geoff: Can the WSDLs that are generated in your approach capable of generating WSDL as it would be produced by the raw approach. 16:20:44 Geoff: Would it cover all possible cases of WSDL usage? 16:20:45
  • q? 16:20:58
  • q+ 16:21:29 Dug: The notification description describes the events, just like Schema describes data, and WSDL describes what is sent on the wire. 16:21:40 Dug: It is not meant to replace WSDL. 16:21:53 Dug: It is used as part of the WSDL. 16:22:10 ack wu 16:22:27 PrasadY has joined #ws-ra 16:22:32 Wu: There is a lot of commonality between the two approaches. 16:23:01 Wu: One question I have: How can an event sink know what service the source can offer from the notification type? 16:24:08 Gil: That is a separate issue. That is, how we are going to express this via policy. More work needs to be done. 16:24:35 zakim, who is on the phone? 16:24:35 On the phone I see Oracle, Paul, Bob_Natale, Vikas, li 16:24:36 Oracle has Prasad, Wu, Ram, JeffM 16:24:56 Gil: I am an event source. I support raw/wrapped, format/filters, etc. The purpose of this issue is to decouple the policy issue from the notification type. We should tackle them separately. 16:25:29 Wu: My point is very simple. An endpoint has a WSDL and I can tell by looking at the WSDL I can tell what notifications that service supports. 16:26:11 Gil: Without policy how do you know where to find the notification WSDL? 16:27:15 Dug: How does the event source describe the various formats, filters, it supports. That is a separate issue. 16:28:27 Wu: Event source today publishes event source and notification WSDL. 16:28:33 Gil: There is no notification WSDL. 16:28:56 Wu: Why can't we attach a notification WSDL to the source WSDL. 16:29:06 Gil: Via policy. 16:29:12 Wu: May be. 16:29:49 ack li 16:30:50 Li: My sense is that the difference between the proposals is the event source publishes the service description and how the sink consumes it. 16:31:52 q+ 16:31:55 Li: It would help me if we understand in Gil's approach we can understand the steps from publication of Notification WSDL to the subscriber finding out about the Notification WSDL. 16:32:33 Li: The event source and sink would take the Notification WSDL and generate their own WSDLs. Are the generated WSDL on different sides communicated to the other side? 16:33:24 Li: Are they in sync? what is their purpose? It is just code generation? 16:34:12 Gil: I as a sink do not know what all notifications I may receive. The only way I can support this is via wrapped. 16:34:46 Gil: Let us say that I can handle a set of notification types (wrapped). I want to know about the raw notifications that are contained in the wrapped form. 16:35:24 I would do a Mex.GetMetadata call to get a description of the raw notifications. 16:36:07 Gil: The generated WSDL from the raw notification information may contain only the raw notifications that the sink is interested in. 16:36:44 Gil: This issue about WSDL compatibility is a funny one. It is possible to have different WSDL produce wire compatible messages. 16:37:32 Gil: Section F of my proposal says how the portype and other associated data is generated. 16:38:12 q? 16:38:27 ack asir 16:39:04 Gil: It is not important that the event sink and source WSDLs match exactly. At a minimum, the Action URI and GED must match. My approach relies on doc-literal binding. 16:39:30 Asir:Gil: Notification WSDLs describes only the notification types. 16:40:54 Asir: I saw that you are mapping the independent notification types to a wrapped or a raw notification. How do you generate wrapped Notification WSDL? 16:41:16 Gil: The whole point about the wrapped Notification WSDL is that not all operations/notifications need to be described. 16:41:28
  • q? 16:41:34
  • q+ 16:42:20 Gil: I may want to filter messages based on wrapped notification types, such as using XPath. 16:44:12 Dug: Gil's proposal provides a mechanism to provide additional data that may not be present in the WSDL. 16:44:38 Dug: This also includes information that may not appear on the wire. For example, topics and queues for notifications. 16:46:28 Li: The major difference in the proposal is why do we need a new metadata construct? 16:46:35 I am still hazy on why we need a new metadata language, notification description 16:46:37 q+ 16:46:42 q+ 16:47:13 Li: Why can't we use the existing WSDL as UDDI does? 16:47:32 ack li 16:48:28 Li: Why do we need the notification description? WSDL can already do that! 16:48:53 Gil: You are correct that you don't need all the notification description. But at least we need the port type. 16:49:33 Gil: The qname of the GED and the Action URI associated with the port types are essential. 16:49:49 Li: In the notification description approach, the WSDL needs to be generated. 16:50:07 Gil: If you use only the wrapped notification, no need for WSDL generation. 16:50:19 Li: I am talking about raw event notifications. 16:52:36 Li: How do you do the serialization/deserialization of raw events? Don't you need a WSDL anyway for raw events? 16:53:46 Li: My question really is that I have problem understanding the critication advantage of notification description mechanism as opposed to simple WSDL approach. 16:55:20 Gil: It is hard to use the WSDL approach to do this. 16:55:32 Gil: What about typing? 16:55:57 Gil: Sorry what about topics? Notification descriptions provides us a nice mechanism to do the same. 16:58:16 Li: There are shortcomings where information cannot be captured in notification description. 16:59:32 q+ 16:59:42 Gil: Notifications map to one-way application message. 17:00:33 Li: The shortcoming is when you want to capture notification with acknowledgements. 17:00:36 -Bob_Natale 17:00:54 Notification 17:00:56 A one-way message sent to indicate that an event, or events, have occurred. 17:01:02 Li: WS-Eventing is a protocol establishes the channel. What flows on the channel should remain unconstrained. 17:01:48 Wu: How about we present our proposal? 17:01:49 I think what Li is saying is that any proposals for 6401 should not interfere with the delivery model in Eventing 17:02:00 ack geo 17:02:05 q- 17:02:28 ack dug 17:03:10 Dug: When the event source sends out only wrapped notifications, should the WSDL include the message descriptions for the raw notifications? 17:03:14 Li: No. 17:03:29 Dug: How does the sink get information about what the source supports? 17:04:12 Li: I will replace the notification description with a WSDL. The subscriber will use the WSDL to get that extra information. 17:05:49 Dug: Technically, you may be able to put the notification description into a WSDL. But are we not overloading the WSDL mechanism? 17:06:17 Dug: In both cases, I need to write custom code. Which is better? 17:06:25 Dug: There are pros and cons either way. 17:09:28 Vikas has joined #ws-ra 17:20:28 +Bob_Natale 17:23:50 gpilz has joined #ws-ra 17:23:53 Back from break. 17:24:01 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401 17:24:10 Issue 6401 discussion continuation. 17:25:42 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0029/Web_Services_Eventing__WS-Eventing_.htm 17:25:48 Li to discuss his proposal. 17:26:01 q+ 17:26:16 q+ 17:26:22
  • http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0029/Web_Services_Eventing__WS-Eventing_.htm 17:26:48 Li: Go to Appendix A in the proposal. 17:27:15 Wu: This approach does not have any changes except Appendix A. 17:27:33 Asir: Can Li describe what problem he is trying to solve and what is the motivation. 17:27:57 Li: The motivation is to address the BP R2303 restriction about WSDL output-only operations. 17:29:11 Li: and to make WS-Eventing BP compliant. 17:29:58 Gil: I would like to know when you step through the linkages between the event notifications and notification description. 17:30:18 Li: This proposal is based on Gil's original idea. 17:30:46 Li: Go to Appendix A in the proposal. 17:32:50 ack asir, gpi 17:32:51 Li: Take the ouput-only operations in the source WSDL and put them in the Notification WSDL. 17:32:56 ack asir 17:33:00 ack gpi 17:33:54 Li: The idea is to replace offending operations. 17:34:03 Dug: Why do we need two WSDLs. 17:34:38 Li: The first WSDL is for the subscriber. The other is for the event source to have a normal request-response operations. 17:34:57 Li: The second WSDL is defined by the event source from the perspective of the event sink. 17:35:36 -Vikas 17:35:42 Li: The subscriber can only choose what the event source can support. 17:36:22 Gil: Is the explicit goal of your proposal to make WSDLs Basic Profile (BP) compliant? 17:36:42 Li: Yes, Appendix A describes how to acheive that goal. 17:38:04 Li: If the event source conforms to Appendix A it can be BP compliant. 17:38:32 Li: The source published the Notification WSDL. 17:39:53 Li: Policy relates the Event WSDL to the Notification WSDL. 17:40:16 state: correction: Is it an explicit goal of your proposal to support the migration of old-style, member submission WSDLs into WSDLs that are BP compliant? 17:40:36 Li: The event sink can use the policy to know about the linkage between the WSDLs. 17:41:46 Li: We have a policy wrapper, we have a policy assertion. The parameter serves as the link between the source and notification WSDLs. 17:42:45 Li: Would this work with policy intersection? 17:43:02 Correction: Dug: Would this work with policy intersection? 17:43:25 Asir: One the qname matching is done and there is no domain specific processing. 17:43:37 + +1.408.202.aabb 17:45:58 Asir: The proposal has one policy assertion whose name is out:outbound. That is the only qname used for policy intersection. The parameters are not used in the intersection. 17:46:30 Dug: The out:outbound qname is a single element and is static. Does this mean everything will match? 17:47:07 the pseudo-schema in A.1 is incorrect - no big deal as we've figured out what was intended, but it shold be fixed to prevent later re-confusion 17:47:31 Asir: out:out-bound is the advertised behavior. When the behavior is engaged, there is a bag of additional information you can use that in in the policy parameters contained inside the policy assertion. 17:48:42 Gil: Li needs to write a psuedo schema to clarify this. 17:49:27 Li - you may want to look at other psuedo schema examples in the eventing doc 17:50:09 Li: For the event source, it has to generate an event as described in the Notification WSDL. 17:50:28 q+ 17:50:34 Li: For the subscriber, it has to subscribe to a specific Notification WSDL via the use of policy. 17:51:02 Li: The event sink has to implement the subscribe operation indicated by the policy parameter. 17:51:42 Gil: What are the attachment points? WSDL portype, binding, port element of a WSDL service. 17:52:00 Gil: We are looking at A.1.2. 17:52:34 q+ 17:52:50 Li: Binding is not an attachment point, we do not see a case for it yet,. 17:52:57 ack gpi 17:53:02 ack dug 17:53:33 Dug: Why is the interace and binding element names different? 17:54:42 Li: If the WSDL has mixed inbound and outbound operations in a porttype, this process separates them into two port types. The policy links the two port types. 17:55:11 jeffm has joined #ws-ra 17:55:30 q+ 17:55:35 Li: A binding links to a port in WSDL and we use the same approach. 17:56:15 Dug: If you follow the binding link in the WSDL file, would you not end up in the same port type? 17:56:20 Li: You are quite right! 17:56:44 Li: Let me explain why we added this port type. 17:57:39 Li: If another standards body defines new event types, the policy can be used to link them. The implementation can use the policy link. 17:58:22 Li: We do not define binding, but only the port types. 17:58:57 Li: This proposal simply refactors the offending WSDL into Event WSDL and Notification WSDL without any binding information in them, 17:59:01 q? 18:00:54 In this approach, policy assertions with Endpoint Subject with the ability to describe the outbound operations in abstract WSDL to facilitate late binding. 18:02:01 Dug: The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy. 18:03:10 q+ 18:03:31 Dug: The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy. 18:03:41 The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy. 18:04:43 q+ 18:04:48 ack gpi 18:04:48 q- 18:04:50 ack wu 18:04:53 q- 18:05:11 Wu: Let us press on with the description. 18:06:47 Gil: How do you check linkage consistency? 18:06:58 Li: We use the tools to traverse the linkages. 18:07:04 q+ 18:08:37 Asir: Any consistency check needs to be done by the policy implementor. 18:08:50 ack om 18:08:56 ack tom 18:09:07 Tom: This is incredibly inventive. Anything that is processing this will need to handle this in a specialized way. 18:09:26 Tom: This seems like we are using policy in place of WSDL documentation. 18:09:44 SAWSDL 18:09:54 provides a way to describe as well. 18:10:06 q+ 18:10:35 Wu: Policy is expressive and does what we want (linkage). 18:11:05 Wu: Policy is supported by tools. We followed Gil's proposal and extended it. 18:11:32 q+ 18:12:01 ack dug 18:12:21 Dug: Is policy being actually used here or is it just for syntax? 18:12:45 q+ to answer Doug's q 18:12:49 Dug: It seems that you are not establishing the link via policy but the linkage is done outside. 18:13:01 - +1.408.202.aabb 18:13:22 + +1.408.970.aacc 18:13:31 The basic idea is to reverse the outbound operations in an event source WSDL to inbound operations in a separate WSDL called notification WSDL, and use WS-Policy assertions to link these operations. 18:15:26 q? 18:15:46 q+ 18:16:02 q+ 18:16:43 ack gpi 18:17:20 Dug: The policy is really a carrier and contains domain specific information. 18:19:12 ack asir 18:19:12 asir, you wanted to answer Doug's q 18:20:10 Asir: Look at section A1. That explains the behavior. 18:21:29 Dug: What does the subscriber need to do? 18:21:50 Li: The subscriber needs to subscribe to the port based on the policy information. 18:22:46 q? 18:23:02 ack geo 18:24:08 q+ 18:24:51 Geoff: Dug mentioned the need to searching on notifications. It seems that requirements and design have gone beyond the original Appendix A replacement. It is good to have the set of requirements well defined. 18:25:49 Bob: The WG should not extend the issue beyond the original requirements/intent. 18:27:20 q- 18:28:22 Li: Moving on to A.1.4. WSDL examples. I suggest looking at second example source. The notification WSDL is short. 18:31:15 - +1.408.970.aacc 18:32:47 q+ 18:33:09 Li is reviewing / describing the WSDL examples. 18:37:46 q+ 18:37:51 q- 18:37:59 ack gpi 18:38:02 ack dug 18:38:52 Dug: I think I understand how when you are in an environment when the event source only sends notifications in one particular format, how the WSDL files can be traversed to reach the Notification WSDL. 18:39:32 q+ 18:39:52 Dug: If the event source supports two wrapped notifications (wrapped1 and wrapped2), how do I know which WSDL to pick up? 18:40:53 Li: You start with the binding as you suggested. I will create two ports each corresponding to wrapped1 and wrapped2. 18:41:21 Dug: How do I know the association? What inside the WSDL tells me? 18:42:55 Dug: I have to know what I am looking for to know what I am looking for. If I already know what am I seaching for? 18:43:48 q+ 18:43:49 Li: You traverse the policy and then indirect. 18:44:11 Gil: What if the outbinding has a qname that uniquely defined a notification format? 18:46:15 state: correction: What if the out:Binding element had an additional attribute that had the value of the Format QName? 18:46:26 Li: In WS-Eventing, we have two formats: Wrapped and Unwrapped. 18:47:08 Li: We need to provide a link between the URI and WSDL; it is currently missing. 18:47:24 q? 18:48:25 Dug: Subscriptions allow number of search types such as bookmarks, etc. How do I know which WSDL to grab. If it is just an URI I may have many WSDLs. 18:48:45 Dug: We need a linkage mechanism so the subscriber can find the right WSDL that matches. 18:51:24 Dug: The WSDL was there to advertise which events are sent. It is not just about BP compliant. 18:52:44 the notification wsdl is constrained to have one binding per port. what did you mean when you talked about "surrogate" port which supports multiple bindings? Are you trying to get at a notification endpoint address which supports multiple notification service ports? 18:53:53 Gil: Issue 6661 deals with this. It is separate. But it is hard to separate doing the proposal for without touching it. 18:54:58 ack tom 18:54:59 Gil: Can the surrogate port support the raw format as well? 18:55:57 Li: Each port can support only one binding. 18:56:52 ack asir 18:57:07 Correction: Li: Each binding can support only one port. 18:57:28 q+ 18:57:35 Asir: 6402 describes policy for event notifications. 18:58:32 q+ 18:58:51 time warning 18:59:03 Dug: These issue are different. 18:59:38 ack geoff 19:01:28 Geoff: In the proposal we had an appendix I. It is not broken. Just that it is not BP compliant. The core issue on the table was to turn what was in Appendix I BP complient. But I am seeing new things like format, etc. While these are important, it is not clear why we are mixing all these things together. 19:01:37 q+ 19:02:17 Gil: Issue 6661 describes the problem. I claim that both my and Avaya's proposal addresses 6661 as it turns out. 19:02:36 Gil: Issue 6401 is different in scope. 19:04:42 Recess until 12:45PM PT. The meeting will reconvene at 12:45PM PT. 19:05:00 -Bob_Natale 19:14:11 -li 19:42:42 -Paul 19:43:26 + +0125660aadd 19:43:43
  • li has joined #ws-ra 19:43:55 Zakim, aadd is Paul 19:43:55 +Paul; got it 19:44:45 +li 19:52:52 [Resuming] 19:52:56 ScribeNick asir 19:53:02 Scribe: Asir S Vedamuthu 19:53:08 ScribeNick: asir 19:53:15 Continuing 6401 19:53:38 Back to traditional engineering 19:54:01 Define problem, determine requirements, propose solutions, prove reqs covered and consider cost 19:54:31 issue 6401: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401 19:54:54 Bob: appropriate to merge 6401 and 6661 19:55:03 s/6661/6661?/ 19:55:10 Wu: scope of 6661 is not clear 19:55:16 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661 19:55:59 ... someone should clearly articulate what needs to be addressed for 6661 19:57:02 Bob: suggests that we merge 6401 and 6661, then march down the list (define problem, determine reqs, ... 19:57:16 Wu: wants to ensure group consensus on what is the scope for 6661 19:57:55 Bob: lets identify reqs 19:58:05 ... some of the reqs now 19:58:18 Bob: are there any objections to merge? 19:58:30 Wu: want to know what is 6661 all about, then merge 20:00:06 Gil: the drill that Geoff and I plan to go through will describe the scope of the problem 20:01:15 Bob: should we defer the engineering exercise to taskforce 6401 20:01:43 ... should we use the F2F 20:02:24 + +1.408.970.aaee 20:02:27 ... okay with using the F2F, but like to reserve some time for the formal objection 20:02:35 [Gil jumped to the board] 20:02:54 fmaciel has joined #ws-ra 20:03:00 Bob: any objections to consolidating these issues? 20:03:11 Wu: we need to decide on the boundary first 20:03:25 only two hours designated for this 20:03:35 http://assets.comics.com/dyn/str_strip/000000000/00000000/0000000/200000/80000/6000/200/286254/286254.full.gif 20:06:46 [Talking about a possible Aug F2F] 20:06:54 Bob: how about the first week of Aug 20:07:33 Geoff: week of Aug 4th is fine with us 20:08:08 Bob: we inadvertently scheduled Sep F2F because it conflicts with a religious holiday 20:08:44 ... Paul - can we do Sep 30- Oct 2nd? 20:09:09 Action: Paul Nolan to check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd 20:09:09 Sorry, amibiguous username (more than one match) - Paul 20:09:09 Try using a different identifier, such as family name or username (eg. pnolan, pfremant2) 20:09:27 Action: pnolan to check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd 20:09:27 Created ACTION-71 - Check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd [on Paul Nolan - due 2009-06-18]. 20:12:35 Action: Geoff to check if MSFT could host a F2F meeting in the first week of August 20:12:35 Created ACTION-72 - Check if MSFT could host a F2F meeting in the first week of August [on Geoff Bullen - due 2009-06-18]. 20:13:01 tentative location is Redmond, Aug 4-6th 20:13:31 Hursley is also tentative from Sep 30-Oct 2 20:13:35 back to 6401 20:13:43 Trascribing the white board 20:14:21 I. Developer of Event Sink generates code to dispatch and marshal Notifications using current WSDL tools a) raw notifications b) wrapped notifications 20:14:53 II. Subscriber searches for a set of potential Notifications for elements that match a specific criteria 20:15:30 III. Subscriber retrieves schema (s) for potential notification set for purposes for authoring appropriate filter expression (s). 20:15:53 IV. Service designer describes abstract interface such that all implementations thereof will be Event Sources 20:17:27 Amending I. c) Extension that impact on-the-wire mesages 20:21:15 Extensions - subscription, formats, filter 20:21:22 Gil: send bookmarks 20:23:06 Bob: we have extension points 20:23:21 ... delivery, subscription, filter, format, endTo, notifyTo 20:23:33 ... and any future extension points 20:25:43 ... need to be feature-wise backward compatibility 20:30:22 Geoff: shouldn't boil the ocean, are we trying to find one solution that solves all problems 20:30:28 Gil: not so 20:31:55 Geoff: may not be able solve for every possible extension 20:32:19 ... boil the ocean | set of things that definable and implementable 20:32:28 Gil: add a non-functional requirement 20:33:01 ... I.c make these easy 20:34:34 Bob: may be we can't do wrapped notifications, general extension points 20:34:52 Geoff: there are 10 different dimensions of easiness 20:36:57 My point was that general extensibility points that affect the appearance of messages of the wire is not a new, unique, or unsolved concept 20:37:03 Geoff: II sounds like brand new 20:37:14 ... not part of Eventing 20:37:41 ... how can a subscriber pick one and subscribe? 20:38:15 q+ 20:38:42 ack gp 20:38:46 ack wu 20:39:02 Wu: do we have to define II in the Eventing spec? 20:40:13 Gil: am interested in weather notifications? 20:41:01 ack dug 20:41:12 q+ 20:41:41 ack asir 20:41:44 q+ 20:42:02
  • q+ 20:42:38 Asir: what do you need for II in the protocol? 20:42:51 q+ 20:43:56 Gil: linkage between the event source and some endpoint that describes the set of notification types 20:44:20 s/some endpoint/something/ 20:44:32 ... want to know what that set of info would look like 20:45:32 q- 20:47:11 II. Subcriber can see a set of potential notifications that may be emitted 20:47:30 s/emitted/emitted by an event source/ 20:47:31 q- 20:47:37 ack wu 20:47:54 the above sentence replaces II 20:47:57 q+ 20:47:59 ack li 20:48:29 Li: who is the target for these use cases, people or machines 20:48:40 Bob: struck search from the whiteboard 20:49:36 ack prasad 20:49:52 Prasad: what about security? Subsriber may not have the authority to see all notifications 20:50:19 Add a non-functional use case - II 'screened' based on authz 20:50:37 Bob: more or less okay with I, okay with II 20:51:47 q+ Asir 20:52:34 q- Asir 20:53:19 Annotate II with schema 20:55:27 effectively 20:55:28 II. Subcriber can see a set of potential notifications (including schemas) that may be emitted by an event source 20:57:15 q? 20:57:33 II. Subcriber can see a set of potential Events (including schemas) that may be emitted by an event source 20:58:29 q 20:58:30 q+ 20:58:46 Ashok: why don't we say metadata instead of schemas 20:58:48 q+ 20:59:16 ack dug 20:59:20 q- 21:00:15 II. Subcriber can see metadata about a set of potential Events (including schemas) that may be emitted by an event source 21:00:22 q+ GEoff 21:00:39 ack wu 21:00:43 ack geo 21:02:33 Dropped III 21:03:09 q+ 21:03:33 ack asir 21:04:06 q+ 21:05:04 lots of confusion about IV 21:05:11 Li is summoned 21:06:23 Li: walk through a use case from ECMA/348/CSTA 21:06:53 q+ 21:07:11 ... we want to be able say .. make that WSDL BP compliant 21:07:27 ... want to separate those outbound operations to inbound operations 21:08:03 ... this is useful for other standard bodies, abstract event services, let the impl take care of details 21:09:03 Doug: should we describe, providing a mechanism by which service designer can be handed an abstract interfaces that can be implemented as an Event Source 21:09:23 q+ 21:10:03 q- 21:10:23 ack asir 21:11:21 Asir: based on what I heard it appears that ... 21:12:08 ... A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source 21:12:13 Doug: agrees 21:18:25 Li: sounds okay 21:18:40 III. A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source 21:19:25 q+ 21:19:34 q+ 21:19:38 q+ 21:19:50 ack sir 21:19:56 ack asir 21:22:15 IV. Realize I, II and II without metadata 21:23:24 s/II/III/ 21:23:26 ack dug 21:23:58 Doug: source supports sends out multiple variations of notifications 21:24:23 ... that is 21:24:37 ... source can support mutliple variations of notifications 21:26:00 q+ 21:26:02 V.Event Source can transmit multiple variations of Notifications (Raw, Wrapped, *) 21:26:03 source can support any combination of A&B in I 21:26:38 q+ 21:26:47 ack geo 21:28:56 talking about stars on the sky 21:29:38 q+ 21:30:55 okay with V 21:32:56 q+ 21:36:49 q? 21:39:43 VI Proide Subscriber with metadata that describes the variations of Notifications 21:40:47 q+ 21:42:04 Geoff: Non-fuctional Requirement - all use case must have a 'reasonable' solution for constrained environments 21:42:22 Bob: accepted 21:42:42 ack asir 21:42:49 ack wu 21:43:01 Wu: are we going to dispose this in one short or incremental 21:43:05 ... divide and conquer 21:43:10 Bob: premature q 21:43:16 Wu: want to ask the question 21:43:40 ack prasad 21:43:45 Bob: thinks the work is reasonable 21:45:54 state: Correction: An adquate spec ought to deal with these use cases 21:47:10
  • q+ 21:47:24 s/thinks the work is reasonable/An adquate spec ought to deal with these use cases/ 21:47:58 ack dug 21:48:31 Doug: a mechanism by which a subscriber can determine the shape of the WSDL based on how it subscribed to an event source 21:50:19 q+ 21:52:20 q+ 21:52:40 ack asir 21:53:58 Asir: don't understand the usecase, what mechanism? 21:56:34 q+ 22:00:02 A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source. 22:07:24 - +1.408.970.aaee 22:17:25
  • q? 22:24:50 + +1.408.970.aaff 22:24:59 zakim, aaff is fmaciel 22:24:59 +fmaciel; got it 22:26:44 Bob wants to add a non-functional req 22:27:29 Bob: we need to finish the work, we started with a charter, to make it reasonable, need to limit invention 22:27:51 -Paul 22:28:10 Bob: non:functional req: limit inventions to application of well known technologies 22:28:33
  • q+ 22:29:21 Bob's non-functional req: limit inventions to application of well known technologies (such as WSDL, MEX) 22:29:35 Bob: we have a limited scope problem, solutions should play within 22:29:36 q- 22:30:04 7: A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source. 22:30:21 Bob: want to get to a draft that is more right than wrong 22:30:44 here is the summary .... 22:31:09 I. Developer of Event Sink generates code to dispatch and marshal Notifications using current WSDL tools a) raw notifications b) wrapped notifications c) Extension that impact on-the-wire mesages (example, new formats) 22:31:09 Non-functional requirement - make it easy 22:31:09 II. Subcriber can see metadata about a set of potential Events (including schemas) that may be emitted by an event source 22:31:09 Non-functional requirement - II 'screened' based on authZ 22:31:10 III. A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source 22:31:13 IV. Realize ALL USECASCES without metadata 22:31:15 V.Event Source can transmit multiple variations of Notifications (Raw, Wrapped, *) 22:31:17 VI. Proide Subscriber with metadata that describes the variations of Notifications (eg supported formats) 22:31:19 VII. A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source 22:31:22 Non-fuctional Requirement - all use case must have a 'reasonable' solution for constrained environments 22:31:22 Non-functional requirement - limit inventions to application of well known technologies. 22:31:49 s/technologies./technologies (such as WSDL, Poliy, MEX)./ 22:32:27 q? 22:32:37 Bob: gil to pick up the summary and turn this into a doc 22:33:28 Bob: in the next meeting, we should review the draft reqs and deal with amendments 22:33:37
  • i have another requirement to add the next time 22:34:10 Bob's picture is non-normative 22:34:44
  • q- 22:35:50 Topic: Sep F2F 22:36:03 Scheduled for Wed Sep 30-Oct 2 22:36:06 Hursley confirmed 22:36:33 Action: Bob to send out a notice about the Sep F2F and other F2F meetings 22:36:33 Created ACTION-73 - Send out a notice about the Sep F2F and other F2F meetings [on Bob Natale - due 2009-06-18]. 22:37:14 Action: Gil to transcribe the draft reqs from the minutes into a doc for review 22:37:14 Sorry, couldn't find user - Gil 22:38:03 my camera may be non-normative, but it is very literal 22:38:15 Action: Gilbert to transcribe the draft reqs from the minutes into a doc for review 22:38:15 Created ACTION-74 - Transcribe the draft reqs from the minutes into a doc for review [on Gilbert Pilz - due 2009-06-18]. 22:40:27
  • bye folks be nice 22:40:44 -li 22:40:48 q+ 22:41:52 Resolution: Agreed to merge 6401 and 6661 22:41:56 Topic: 6924 22:42:22 Gil introduces his proposal 22:43:01 Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0035.html 22:45:20 ack geo 22:45:34 Geoff: perhaps, change update denied to put denied (fault) 22:45:45 Bob: any objections 22:45:46 None 22:45:55 s/UpdateDenied/PutDenied/ 22:46:06 q+ 22:46:21 Tom: is all or nothing on put? 22:46:26 Gil: all or nothing 22:46:34 Ashok has joined #ws-ra 22:47:53 A successful Put operation updates the current representation associated 22:47:55 with the targeted resource. An unsuccessful Put operation does not affect the resource. 22:48:25 ack dug 22:48:30 Doug: am okay with the issue/proposal 22:48:47 ... it is important that a client knows what the server would do 22:49:35 ... include a flag that indicates what the server would do when it encounters read-only data 22:49:52 Bob: where should we put that 22:49:59 Doug: wiki :-) 22:51:52 Bob: move to wiki 22:52:10 Two amendments 22:52:29 a) s/updatedenied/putdenied/ 22:52:50 b) A successful Put operation updates the current representation associated with the targeted resource. An unsuccessful Put operation does not affect the resource. 22:52:51 Could what the server would do with read-only data vary based on the specific resource, and may not be a generic one applicable across the board to all resources 22:53:17 Resolution: accept http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0035.html + the above two amendments to resolve issue 6924 22:53:43 Action: Doug to add the 6924 related metadata possibility to the wiki 22:53:43 Created ACTION-75 - Add the 6924 related metadata possibility to the wiki [on Doug Davis - due 2009-06-18]. 22:53:58 gpilz has joined #ws-ra 22:54:00 metadata == things to advertize 22:54:02 Topic: 6956 22:54:51 Geoff walks through the updated proposal 22:54:53 Proposal 22:55:05 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0033.html 22:57:38 Resolution: proposal accepted to resolve issue 6956 22:57:48 q+ 22:58:10 Thank you Ram! 22:58:27 Thank you Asir. 22:58:37 ack asir 22:58:41 ack asir 22:59:45 +[Oracle] 23:00:00 Bob: Discuss formal objection. 23:00:14 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0014.html 23:00:25 Geoff: Microsoft submitted a formal objection to issue 6398. 23:00:49 It is not about the process it is about a technical objection. 23:02:42 Geoff describes the technical objection. 23:03:32 q+ 23:04:19 Geoff: There are other possibilities to address the technical objection. We should open up that issue and arrive at a mutually satisfactory solution for the problem at hand. 23:04:32 ack ashok 23:04:46 Ashok: You said that this is NOT a process objection. 23:05:27 Ashok: We had an issue and we closed it. So, are you reopening the issue? 23:06:19 Bob: The process allows for re-opening issues if new information is provided. 23:06:53 Bob: Anyone wants to discuss the technical objections raised by Geoff? 23:07:16 No comments from the WG. 23:07:46 Bob: Do Web service messages use well-known wrappers and actions? 23:08:01 Dug: Yes, many do, including the WS-RA specifications. 23:08:41 Bob: Why is this issue different? Anyone? 23:09:37 Yves: The current specification has Get wrapper and GetResponse wrapper. The specification is silent on what happens when the Get message is not wrappered but the GetResponse is wrappered. 23:10:01 Yves: If the wsa:Action is used to distinguish the message, then this problem should go away. 23:10:56 Geoff: WS-Transfer supported wsa:Action as the only way to dispatch. The issue (6398) resolution has changed that dispatch mechanism. 23:11:49 Yves: When you have two ways of expressing the same thing, there is room for contradiction. That is the real problem. 23:13:02 q+ 23:13:55 ack dug 23:14:12 Yves: I propose using an anonymous wrapper or a single wrapper for all WS-Transfer operations. 23:14:31 BobN has joined #ws-ra 23:14:50 Dug: The right solution is to throw a fault if the wsa:Action and the wrapper does not match. I suggest opening a separate action. 23:14:52 q+ 23:15:05 q+ 23:16:06 Dug: The information that is claimed to be new is not actually new. 23:17:01 Bob: That information was in a snippet of email but not raised or discussed on the floor. Maybe the sentence flew by but never teased out or discussed. 23:18:14 Bob: Is the point of it about a mismatch. That is, between the wsa:Action and the wrapper? Is that the problem? 23:19:35 Geoff: We have another problem. The WS-Transfer specification originally had wsa:Action as the only mechanism. That has been changed by the issue. This is the fundamental split. We need to continue to support wsa:Action as a mechanism to dispatch messages. 23:20:13 Bob: There are two points. One is in terms of dispatch (use of wsa:Action). Two is what happens if the wsa:Action and wrapper do not match. 23:20:35 Bob: Let us talk about dispatch mechanism. 23:21:13 Bob: WS-Addressing specifies wsa:Action as a mechanism to dispatch. 23:21:39 Asir: There have been other mechanisms in the past as well. 23:22:55 Bob: I do beleive we have a technical issue here. It is about dispatch relating to use of wsa:Action. 23:24:20 Geoff: Our objection is NOT about adding a wrapper. 23:26:00 jeffm has joined #ws-ra 23:26:02 q 23:26:08 _q 23:26:08 q- 23:26:12 +q 23:26:30 Bob: What I would like to do at this time is to leave the resolution as is at this time and open two new issues. One issue would be about the wrapper name and wsa:Action and what happens if the wrapper name and wsa:Action are different. The second issue is about should the wrapper be the source of dispatch. 23:27:17 Gil: I would like to object to opening the issues. 23:27:39 Bob: I suggest opening the new issues. 23:27:44 Gil: Have we not formally accepted issues in the past? 23:28:51 Bob: We can either re-open the issue and deal with these two new issues or simply open only the two new issues. 23:29:24 Doug: Yves and Geoff can open separate issues and follow the normal process. 23:29:51 Bob: I want these issues to be opened. 23:30:54 Jeff: Where does that process say that the chair can open new issues at his/her own discretion? 23:31:07 http://www.w3.org/2005/10/Process-20051014/ 23:32:12 Under 3.3.4 is the relevant section. 23:32:17 q+ 23:34:04 Asir: The situation was due to the 6398 resolution and we did not have sufficient information. 23:35:49 Bob: We just ran through a wrappering issue and we agreed to have the wrapper. Here we have a case where the charter says BP compliance. We had two proposals on the table one from Doug Davis and another from Geoff Bullen. 23:36:55 Bob: The chair conducted the vote and the issue was resolved in favor of Doug's proposal. 23:37:58 Dug: There is no new information. I just question the notion of new information being brough forth. 23:38:08 ack wu 23:38:25 Bob: Simply because something was on the mailing list does not constitute new information. 23:38:41 q+ 23:39:21 Wu: We had thought that the issue was about BP compliance. But we never understood that the mismatch between wrapper and wsa:Action is a problem. I agree with Yves. 23:39:59 ack asir 23:40:02 ack jeff 23:40:04 Wu: I support opening the new issue to deal with the mismatch between the wrapper and wsa:Action. 23:40:11 q+ 23:41:11 Jeff: Oracle objects to the way this is being handled. 23:41:24 IBM agrees with Oracle 23:41:32 ack dug 23:41:59 Dug: You said that email does not constitute new information. 23:42:15 Bob: Yes, the information was not discussed. 23:42:29 q+ 23:42:50 Dug: At that time, Geoff did not discuss that. How does that then become new information? 23:43:18 Bob: Wu asked for more time at that time. Wu please clarify. 23:43:51 Wu: We never discussed how the wrapper should be designed. 23:45:07 Bob: I like to open an narrowly scoped issue that deals with the technical component of the prior issue relating to wrappering and discuss it. 23:46:29 Tom: What happens if the message does not obey the WSDL? 23:47:23 Tom: WS-I BP tools could do compliance. I suggest opening new issues just like any other new issues. 23:48:24 Geoff is in the process of opening new issues. 23:48:47 q? 23:48:52 Yves: There are people who use Web services who do not use WSDL. 23:48:55 ack tom 23:50:31 Dug: The WSDL is normative and defines the contract. 23:51:26 q+ 23:51:45 Dug: If the Subscribe message has wrong format, what happens? 23:52:29 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7015 23:53:13 q+ 23:53:30 q+ 23:53:47 ack asir 23:53:53 ack jeffm 23:54:14 Asir: Our objection is on the outcome of the issue resolution. We will defer to you whether you want to reopen or process the technical objections as new issues. 23:54:28 Jeff: All bets are off, if you violate the specification. 23:54:34 ack tom 23:54:45 Tom: I have a confusion about what 'dispatch' means. 23:55:04 Tom: I object to this issue. 23:55:09 q+ 23:55:31 Gil: I need more time to process this issue. 23:55:47 Gil: Can we discuss accepting the issue at the next meeting? 23:56:01 Dug: I need more time too. 23:56:08 Bob: I don't want to rush anyone. 23:56:24 ws addressing core states: "The [destination] and [action] properties indicate the target processing location and the verb or intent of the message respectively. The values of these properties can be used to facilitate the dispatch of messages." that is the only use of the word "dispatch" in the spec 23:56:27 q+ 23:56:36 Dug: The issue says: "Replication of information reduces interoperability". I don't understand that. 23:56:42 ack dug 23:56:51 this is a non normative statement, the concept of dispatch is implmentation dependant 23:56:52 Dug: WS-Addressing replicates information. 23:57:53 Dug: Interoperability problems occur due to ambiguities in the specification. 23:58:21 Dug: I need more information. 23:58:21 ack wu 23:58:53 q+ 23:59:17 Wu: I want to make a constructive suggestion. I think the issue proposal is very clear. I suggest we open issue and discuss it. 23:59:59 Gil: I would like to make sure that the issue is well described. My intent is not to reject this issue. 00:00:45 Not sure why RM comes into play all the time! 00:00:53 its a lovely spec 00:00:57 interesting 00:01:01 Dug: The premise of the new issue is in question or incorrect. Therefore, we should not accept this issue. Therefore, we need to discuss whether we need to open this issue. 00:01:05 I think you wanted to use MC 00:01:10 I thought about it 00:02:01 Bob: The new issue in an unopened/unaccepted state. Comments can be made to amend the issue. 00:02:32 gpilz has left #ws-ra 00:03:20 Bob: IBM confirms that the new dates for the September F2F. I will send a confirmation email to the WG. 00:03:26 rrsagent, generate minutes 00:03:26 I have made the request to generate http://www.w3.org/2009/06/11-ws-ra-minutes.html Bob 00:03:37 Meeting adjourned. 5:03pm PT. 00:04:56 -[Oracle] 00:04:58 -fmaciel 00:05:04 PrasadY has left #ws-ra 00:09:59 -Oracle 00:10:00 WS_WSRA(3 day)11:30AM has ended 00:10:01 Attendees were +0208234aaaa, Paul, Yves, Geoff, Bob, Asir, Tom, Prasad, Wu, Ram, JeffM, Bob_Natale, Vikas, li, +1.408.202.aabb, +1.408.970.aacc, +0125660aadd, +1.408.970.aaee, 00:10:03 ... +1.408.970.aaff, fmaciel, [Oracle]