16:01:10 RRSAgent has joined #ws-ra 16:01:10 logging to http://www.w3.org/2010/05/12-ws-ra-irc 16:01:12 RRSAgent, make logs public 16:01:12 Zakim has joined #ws-ra 16:01:14 Zakim, this will be WSRA 16:01:14 ok, trackbot, I see WS_WSRA()11:00AM already started 16:01:15 Meeting: Web Services Resource Access Working Group Teleconference 16:01:15 Date: 12 May 2010 16:01:31 rrsagent, this meeting spans midnight 16:01:54 scribenick: Tom_Rutt 16:03:06 agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0028.html 16:03:57 Vikas has joined #ws-ra 16:04:09 Topic: Agenda 16:04:10 agenda accepted 16:04:26 + +1.571.262.aaaa 16:04:29 -[Microsoft] 16:04:30 +[Microsoft] 16:04:35 Wu has joined #ws-ra 16:04:41 - +1.571.262.aaaa 16:05:06 + +1.571.262.aabb 16:05:53 Topic: New issues 16:05:54 All three new issues were accepted unanamously 16:06:12 Zakim, aabb is Vikas 16:06:12 +Vikas; got it 16:06:14 +asoldano 16:07:09 Topic: Issue 9712 16:07:10 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9712 16:08:03 No objection to accept proposal 16:08:05 Resolution: close 9712 by resolving as proposed 16:08:36 Topic: Issue 9713 16:08:37 -Issue-9713 GetStatusOperationSupported and UnsubscribeOperationSupported parameters not needed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9713 -Pilz 16:10:23 Gil: they must be supported by all subscription managers. There is no optionality. 16:10:41 Wu: when did we decide to make these madatory? 16:11:14 Ram: the definitions of the operations state they must be supported. 16:11:48 Zakim, who is here? 16:11:48 On the phone I see [Microsoft], Vikas, asoldano (muted) 16:11:50 On IRC I see Wu, Vikas, Zakim, RRSAgent, Bob, asoldano, Tom_Rutt, Ram, Yves, trackbot 16:12:04 Ram: we decided to do this two face to face meetings ago, in Santa Clara 16:12:52 No objections to accepting resolution.. 16:12:54 Resolution: Issue 9713 resolve by accepting proposal 16:12:56 +Yves 16:13:17 Topic: Issue 9717 16:13:19 -Issue-9717 Frag: Add pre-defined dialect for Xpath 2.0 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9717 -Freund 16:13:23 Dug has joined #ws-ra 16:13:26 q+ 16:13:45 ack dug 16:14:06 Dug: Is this only for Frag. We define Xpath 1.0 in eventing as well. 16:14:19 Bob: It is intended for all three specs. 16:14:24 gpilz has joined #ws-ra 16:15:12 Dug: should the new section be written just like the 1.0 section of these documents. 16:15:31 No objection to applying to eventing, enum, and frag 16:15:39 -Vikas 16:15:51 Resolution: Issue 9717 resolved as proposed 16:17:44 Topic: Issue 9700 16:18:09 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700 16:19:20 Dug: he is looking for info in get metadata response as to what supported types are 16:19:31 Wu has joined #ws-ra 16:19:35 Dug: He does not want to rely on policy 16:20:17 q+ 16:20:45 Gil: I do not understand why a get client who asked for a type, would be interested in other types. 16:21:26 ack ram 16:21:49 Dug: If the client can deal with other types, they can use an "all" in the get metadata. He did not seem happy with this suggestion 16:22:41 Ram: It seems that a fault, with the additional information, would satisfy him 16:23:21 Dug: a fault is not appropriate, since there might be multiple metadata types in a single request, to fault all of them is not useful 16:23:30 q+ 16:23:47 Dug: I think relying on interrogating policy is the best approach. 16:24:11 ack gp 16:24:21 Dug: I would not like to tweek the protocol, when policy can meet the need 16:24:42 Ashok has joined #ws-ra 16:25:27 Gil: I agree with Dug. Policy is the way to do this. If this a problem that people want to profile out, why not just remove the content attribute? 16:25:48 Dug: we need to give the client a way to select which types it wants 16:26:15 q+ 16:26:24 Dug: I cannot accept removing the attribute. Let them rely on policy 16:26:34 ack ram 16:27:12 Dug: for each dialect you support, you can list the type and format you support. In section 12 16:31:25 Gil: content attribute is optional, they can just say conformant profile clients cannot send the optional attribute. However, the server must be able to accept the attribute. 16:32:32 we don't like using the mics 16:32:35 Bob: I am hearing that the mechanisms are available, and their profile can require that clients not send the content attribute. 16:32:37 we're shy 16:32:42 No objection to close with no action 16:32:45 gil :) 16:32:56 Resolution: Issue 9700 closed with no action 16:33:36 Action: Ram will write the response to the originator of issue 9700 16:33:36 Created ACTION-157 - Will write the response to the originator of issue 9700 [on Ram Jeyaraman - due 2010-05-19]. 16:35:15 Topic: Issue 9709 16:35:17 http://www.w3.org/Bugs/Public/attachment.cgi?id=876 16:35:17 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9709 16:37:03 Dug: I modified the text around the getWSDLResponse/xs:any to allow references as well as the wsdl itself 16:37:03
  • li has joined #ws-ra 16:37:54 added text description 16:37:56 [Body]/mex:GetWSDLResponse/xs:any 16:37:58 When the GetWSDLResponse element contains any child elements, the first element MUST either be the WSDL metadata document, or a reference to the WSDL metadata document, of the endpoint. Any extension elements MUST appear after the WSDL document/reference. The absence of any child elements indicates that the endpoint does not have any WSDL document, or additional metadata, associated with it. 16:38:20 How can a small device gain something by retrieving the same data using a new request/response insted of having the data inline. the mex env is not that big 16:39:47 Dug: the use case is that the endpoint does not have the entire copy of the wsdl, however they have a pointer to where the wsdl can be obtained 16:39:49 +li 16:40:33 His third sentence seems to imply he is concerned about the server's requirements, not the client's 16:41:50 returning a reference might help caching as well 16:42:03 Dug: we could suggest that the first choice is the raw data itself, only sendting the location or reference is the data is not available 16:43:00 Gil: If we are concerned about the client requirements, we may need an attribute on the request, like the content attribute 16:44:21 Gil: Antoine's concern is for the server. The client can do get metadata. Leave it to the service to decide. The client would use whatever means it is presented with in the response. 16:45:08 q+ 16:45:45 ack ram 16:46:29 Tom: what if the server wants to decide not to send the data for a short period, say due to network load. I think a mandate as to the preferred way to respond is untestable anyway 16:46:42 Dug: I can live with it being totally up to the server 16:49:16 Bob: is accepting the proposal acceptable to everyone? 16:49:35 No objections raised 16:49:50 Resolution: Issue 9709 resolved as proposed 16:50:14 Action: Dug to write the response to the reviewer Antoine 16:50:14 Created ACTION-158 - Write the response to the reviewer Antoine [on Doug Davis - due 2010-05-19]. 16:51:09 Topic: Issue 9610 16:51:39 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610 16:53:07 Dug: why call it a pseudo event? 16:53:30 Bob: also correct the spelling 16:54:45 Gil: I would think that a reasonable implementation would try to poke the event source before it returns the success response to the verify, otherwise a fault could be sent. 16:54:54 Tom: did you define a specific fault? 16:55:11 gil: in soap 12 speak it would be a receiver fault. 16:56:26 Tom: could we add a note on the intent of the success reponse 16:57:55 Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted. 16:58:51 This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request. 16:59:34
  • q+ 17:00:50 Dug: what fault would you send? 17:01:28 Gil: a receiver fault indicating an internal error would suffice 17:02:11 Dug: what is the difference between this fault, and the sequenceEnd with an EndTo present 17:02:35 ack li 17:02:53 Gil you can get this fault to the verify, but still consider the subscription as being active. It could be a short term error condition 17:04:15 Li: would would be the infoset for the verification event. There is no parts for the message. 17:04:49 Gil: an empty soap:Body is ok, since the information is in the WSA:Action value 17:05:12 Gil I do not understand the relevance of InfoSet in this matter 17:05:50 -asoldano 17:06:40 q+ 17:07:19 Wu: the verification event could contain information about the subscription 17:07:20
  • q? 17:07:47 Gil: the verify event is the same as any other event which can be sent from the event source, other than the fact that is is never filtered 17:08:31 Wu: carry in the verify event which particular verify request invocation is being responded to 17:09:06 q+ 17:09:24 Tom: he seems to be asking that the verify event report carry the message id for the verify request that stimulated it 17:09:33 Dug: why would we need that 17:10:32 Wu: It could give information on the delay between the request and the event emission. It would also allow detection of verify requests which never resulted in a verify event. More diagnostic information is available 17:11:55 Dug: Wu's proposal requires more complexity in the communication between the subscription Manager and the event source. Also it implies a complicated set of analysis by the event sync 17:12:00 ack d 17:12:04 ack g 17:12:09 Wu: I would prefer that we have time to think about this further 17:13:29 Gil: This extension to correlate verify event with the verify request is going beyond the requirements behind this issue. Timing aspects of the path verification are not required for the use case. 17:14:28 Gil: I do not see the relevance of the infoset problem. 17:14:36 q+ 17:14:55 ack d 17:15:00 q+ 17:15:06 q+ 17:15:35 Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted. This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request. 17:17:02 Dug: I can live with the implementation note. However, I would like to see more information on the types of fault that may be returned. When would that fault not be bad enough to kill the subscription? 17:17:36 Tom: there might be a temporary condition causing the lack of communication between the sub manager and its event source. 17:17:43 q+ 17:18:06 ack w 17:18:32 q+ 17:18:36 Gil: The client receiving this fault without a subscription end would tell the client it can try the verify again at a later time, with the potential of success 17:19:25 ack r 17:20:11 Wu: we would like time to consider extension to the simple proposal, which may make it more useful for other use cases 17:22:08 q+ 17:22:23 ack g 17:22:24 ws-man v1.1 says this about the heartbeat event: "The heartbeat event itself is simply an event message with no body and is identified by its wsa:Action URI as follows: . . ." 17:22:36 Ram: we could modify the get status semantics to require that the sub manager only return a success if it knows the event source is alive. That would cover this requirment 17:23:13 ack wu 17:23:37 q 17:23:46 q+ 17:23:51 q+ gp 17:23:57 q- gp 17:24:04 Tom: Ram's suggestion covers have of the requirement for heartbeat, It would not also verify the communication path between an event source and its event sync, in the case where the event source is at a different sending port than the port used by the subscription manager get status response 17:24:22 s/covers have/covers half/ 17:24:41 q+ 17:25:19 q- 17:26:00 ack gp 17:26:04 q+ 17:26:22 Gil: it is not possible for the event source to verify its link to the event sink. 17:26:36 do we need to check everything, from the path between the sub manager to event generator, to the even generator and receiver? 17:27:02 Bob: to turn this into a network diagnostic would require a lot of additional mechanisms to be in place. 17:27:21 Dug: there may be proxies between the event source and the event sink 17:27:28 q- 17:28:11 q+ 17:29:04 Bob: it is difficult to think of all the possible failure modes in this kind of a "ping" mechanism. We need to restrict our discussion to finding a proposal to meet the needs that issue originator brought forward, with sufficient widespread use to make it part of the base eventing spec. 17:29:15 q+ 17:29:58 Bob: they are asking for a heartbeat mechanism to figure that both the event source is alive, and also that the communication channel between source and sink is functioning. 17:30:27 ack g 17:30:55 ack w 17:31:01 Gil: I would hate to see this issue hold up our specs. If we cannot agree to a simple solution that meets there needs, I would prefer to close with not action 17:32:26 Wu: how about modifying the get status operation to have the get status response be returned from the event source to the event sync 17:33:05 Gil: That would cause more problems than it solves. The get status requester may not be the same as the event sink 17:33:30 q+ 17:34:38 get status through the event sink is a bad solution, even delivery and status checking are two different things 17:35:03 Gil: perhaps the verify feature could be triggered by an extra parameter to the get status. 17:35:20 ack ram 17:36:21 Dug: I think that it makes sense to have the information on the get status response to be returned in the verify response. Why do we need two operation types, if an option on get status could add the triggering of verify event 17:37:45 zakim, who is here? 17:37:45 On the phone I see [Microsoft], Yves, li 17:37:47 On IRC I see li, Ashok, Wu, gpilz, Dug, Vikas, Zakim, RRSAgent, Bob, Tom_Rutt, Ram, Yves, trackbot 17:38:13 ack r 17:40:10 Bob: who in in favor of changing the proposal to adding an optional verify element to get status to also do the verify event trigger. 17:40:46 Several indicate that if we do anything for the verify, we should merge it as a feature of get status. 17:41:35 Only Fujitsu and Oracle indicated that this new verify feature be added to get status. 17:42:05 Wu: I could accept such an addition if if did more than the simple proposal. 17:42:53 Bob: can we have a decision by Thursday morning? 17:42:54 Agreed that we will schedule decision for Thursday morning of F2F. 17:51:37 +Vikas 18:01:26 Topic: Issue 9675 18:01:28 http://www.w3.org/Bugs/Public/attachment.cgi?id=875 18:01:28 -Issue-9675 Eventing: Clarify attachment of NotificationWSDLs to the EventSource policy assertion http://www.w3.org/Bugs/Public/show_bug.cgi?id=9675 -Mensch 18:02:13 -Yves 18:02:24 -Vikas 18:02:38 +Vikas 18:02:50 q+ 18:04:23 Dug: I did what we agreed to yesterday. 18:04:41 -Vikas 18:04:48 Gil: I would like to remove the word "only" in the second line of the explanation for the example. 18:06:51 Dug: I can live with removing the word "only", it is true but I agree not necessary 18:07:16 No objection to accepting amended proposal 18:08:03 Resolution: Resolve Issue 9675 with proposal as amended by striking word "only" 18:08:25 Topic: Issue 9701 18:08:27 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9701 18:09:21 q+ 18:10:28 dug: there is no requirement for event source to understand anything other than NotifyTo element. He wants a fault when the event source cannot accept an extension 18:11:50 Bob: we had this discussion at past F2F regarding the usual soap extension model. 18:12:07 +Vikas 18:12:27 Bob: why do we need a fault, why not just eliminate the sub manager epr from the response? 18:13:59 Dug: we are really trying to say that there must be some delivery mechanism present. However the wording puts it in xml speak. He would rather have a fault, rather than just creating the subscription after ignoring extensions 18:14:56 ack gp 18:15:29 Gil: they want new fault, "I recognize there is something extra in the request, but I do not know what to do with it" 18:17:18 Dug: define "no delivery mechanism fault" when there are not children elements, or not elements which are understood by the event source 18:17:41 s/not elements/no elements/ 18:18:05 Gil: but I might understand, but do not want to support the mechanism. 18:18:29 Bob: Fault when no delivery mechanism has been established. 18:18:47 NoDeliveryMechanismEstablished 18:18:52 Agreed to have Dug write a full proposal which reflects the discussion above. 18:19:43 Resolution: Resolve Issue 9701 by adding new Fault "NoDeliveryMechanismEstablished" with appropriate explanatory text 18:20:42 Action: Dug to write response to issue 9701 reviewer explaining our solution to his issue 18:20:42 Created ACTION-159 - Write response to issue 9701 reviewer explaining our solution to his issue [on Doug Davis - due 2010-05-19]. 18:21:16 Topic: Issue 9702 18:21:18 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702 18:21:50 Gil: Antoine seems to assume you can profile out features that the base spec states you MUST support 18:22:47 Dug: you have to understand these attributes, while you do not have to support all the values 18:24:26 Gil: this is a sender optional feature, thus the service must be capable of handling it when present. They could profile as "conforming clients in this profile MUST NOT include this in the request message 18:26:27 Gil: they seem to be worried about clients which do not conform to the profile. The only way to give him what he wants is to change the definition of this feature being both client and server optional 18:27:04 Gil: you would have to add a policy parameter for this, and also add a fault to indicate the server does not support it. 18:31:35 Dug: what if the server supports the syntax, however it never can satisfy any value in the expires. It can send the existing fault all the time 18:38:20 Gil: we could make the entire expiry mechanism to be server optional. The policy and fault would be indicating non-support of entire expiry mechanism. The other alternative resolution is close No Action 18:41:00 Dug: another alternative is only allow a duration for expiry. Get rid of min and max 18:41:55 and exact 18:44:58 q+ 18:47:06 Bob: for servers that do not support ranges of time, they will simply respond to the max value 18:47:48 Gil: the server can just pick the max and give it to the subsription 18:48:48 Dug: they want to have the server to be able to pick the expiry time, irregardless of what the client requests 18:50:14 ack ram 18:50:33 Dug: the spec requires that the server check that min is smaller than the max, otherwise fault the request 18:52:05 Dug: how about "no expires element -> server choice" , "Exact time, if present must be honored to create subscription" 18:53:36 Dug: also have expires be server optional 18:54:55 Gil: I would like to get rid of date/time, and rely on duration only 18:56:05 Expires is server optional, add a fault for when its not, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault 18:56:38 s/its not/its not supported/ 19:02:40 No object to the above a directional resolution 19:02:59 Agree to finalize decision on Thursday morning 19:03:48 s/above a directional/above as a directional/ 19:34:59 -li 19:39:19 -Vikas 20:08:50 Reconvene at 1:08 PM 20:11:45 Topic: Issue 9700 Response 20:15:22 Dug: if the content attribute is not present, the default is any format. However, they cannot profile out the server behaviour when the content attribute is present but not supported. 20:16:28 Dug: when the content attribute is present, the server must support it or not accept the request. 20:17:12 Topic: Issue 9703 20:17:13 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9703 20:17:15 Review event descriptions and their attachment mechanisms 20:17:19 +Yves 20:18:04 http://www.w3.org/Bugs/Public/attachment.cgi?id=878 20:21:22 Dug: one thing Antoine is concerned about is the potential duplication when the same event type is associated with more than one wsp:Policy assertion type 20:23:17 Dug: he wants an element in the wsdl descriptions doc which has list of event types. This element is referred to in the wsp:Policy. 20:24:18 Dug: he is adding the wse:Notification element to policy eventSource which has an attribute pointing at that element in the descriptions doc. 20:25:00 Dug: He wants to be able to have everything in a single document, and also have reuse of the definitions in that single document. 20:26:47 Dug: rather than adding this notifications element to the policy assertion, have the mex:Location to have a relative URL so it can point to EVDs that are embedded within the same doc. 20:27:56
  • li has joined #ws-ra 20:28:20 Dug: this would be a change to the mex spec to allow relative url, and also to the event spec to allow multiple event description elements within the event source assertion. 20:28:46 +li 20:30:40 Dug: I have some concerns about the relative URL. we would have to use the wsu:Id attribute 20:31:34 Gil BP does not allow wsdl description extensions to be required. 20:32:15 Dug: I like this relative URL better than using a QName pointer mechanism 20:34:28 Dug: my proposal would still put the event description in the wsdl, but changes the way it is pointed at. 20:35:23 Dug: for the Notification WSDL , his QName points to a port type 20:38:45 Dug: my proposal again allows mex:Location to be relative. the mex:Location would have a Type attribute. 20:40:12 Dug: notion of relative URI for mex:Location is a change which can be justified on its own right. The change is allowing more than one event description to appear, and a reference for the wsdl element. 20:41:53 Dug: our event source assertion needs to describe what happens when there are multiple instances appearing inside it. 20:43:13 Gil: I would like some time to think about this one. 20:43:30 Agreed to defer decision until Thursday at this F2F 20:44:09 Topic: Issue 9671 resolution incorporation into spec 20:44:11 http://www.w3.org/2002/ws/ra/edcopies/wsmex.html 20:44:35 http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0024.html 20:45:10 Wu has joined #ws-ra 20:47:20 In addition to the edits in Katy's 20:47:22 proposal, the following additional things were changed: 20:47:24 - Updated xsd 20:47:25 - Updated wsdl 20:47:27 - Added Content to DeleteMetadata request (more below) 20:47:29 - Added the Fault boilerplate text to the new "Faults" section 20:47:30 - Added the boilerplate text to the Notational Conventions section about 20:47:32 "generate" 20:47:33 - Added a ref to the WSA SOAP Binding spec - due to the new faults section 20:47:35 - Added ... to GetMetadataResponse pseudo-schema 20:47:36 Dug: 20:49:37 Dug: I want everyone to be aware of the changes I made, and to ensure that I did not make any mistakes during editing 20:50:08 http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0024.html 20:50:14 I've included two word docs - one is a diff of the final mex spec against 20:50:16 the mex spec prior to these edits, and one is a diff of the mex spec 20:50:17 against Katy's proposal. This will allow people to see the edits from two 20:50:19 different perspectives. FYI - some of the diffs in the *-katy-diff.doc 20:50:21 are due to the other issues we resolved today not being part of Katy's 20:50:22 version - so you can ignore those change bars. 20:50:24 http://www.w3.org/2002/ws/ra/10/05/wsmex-9671-diff.doc 20:50:25 http://www.w3.org/2002/ws/ra/10/05/wsmex-9671-katy-diff.doc 20:52:37 Topic: Issue 8284 References to wsdl 1.1 corrected version of schems 20:53:36 Gil: We have a proposal on the table of the BP group on this topic, and are working hard to partitioning the section on wsdl into two sections: Changes to Wsdl spec vs Profiling of WSDL requirements. 20:54:43 Bob: open issues include 8284, Heartbeat/verify, Expiration time not supported, Event descriptions attachment mechanisms 20:55:03 All but 8824 are scheduled for decision Thursday of this F2F 20:55:26 Topic: At Risk Determination and Testing 20:55:57 Bob: our charter requires for each feature in spec, in order to exit CR we need to have two independent implementations that implement those features 20:55:59 -Yves 20:56:51 Bob: we need to get an Idea of which parts of the spec companies are not planning to implement 21:10:00 -[Microsoft] 21:16:00 Company, Enum, Event, EVD, Trans, Frag, SA, Mex 21:16:01 IBM, ?, I, I, I, I, I, I 21:16:03 MS, I, I, ?, I, I, ? I 21:16:04 ORCL, ?, I, I, ?, ?, I, ? 21:16:06 Avaya, X, I, X, X, X, X, X 21:16:07 Fujitsu, I, I, ?, ?, ?, ?, ? 21:16:09 Hitachi, I, I, ?, I, I, ?, ? 21:16:34 Bob: we need to poll CA, SAG, and Red Hat 21:19:49 Key: ? Thinking, X Won't, I Intend date TBD 21:27:49 Bob: I propose to all to look at SoapUI as a tool to employ for testing 21:29:53 Bob: we need to get the people from each company who will be doing the test implementations together 21:30:41 Bob: we will be testing the spec in a behavioral sense. Not a man in the middle network sniffing based approach (such as done in WS-I) 21:34:39 Bob: for each of these specs we have to determine on a feature by feature basis which features will be implemented by at least two implementations 21:36:17 s/\? I/\?, I/ 21:37:39 Bob: we need to convert all the Intentions into a specific date . What is the Date that we have Dates ready by? 21:41:15 Dates for the Date 21:41:17 IBM 7/ Begin 21:41:18 MS 9/Begin 21:41:20 ORCL 7/ Begin 21:41:21 Avaya 9/ B 21:41:23 Fujitsu 9 / B 21:41:46 Hitachi 9/ B 21:46:01 ACTION: Gill to catalogue eventing with an eye to which features might be at risk 21:46:01 Sorry, couldn't find user - Gill 21:47:17 ACTION: Gil to catalogue eventing with an eye to which features might be at risk 21:47:17 Sorry, couldn't find user - Gil 21:48:01 ACTION: gpilz to catalogue eventing with an eye to which features might be at risk 21:48:01 Created ACTION-160 - Catalogue eventing with an eye to which features might be at risk [on Gilbert Pilz - due 2010-05-19]. 21:56:14 Bob: Features in the CR marked at risk, will not be included in the Final Rec, if they have not met the implementation bar. Features that have not been marked at Risk in CR, will prevent the spec from reaching Rec status until those features reach the implementation bar 22:01:13 Bob: how can we distribute out the specs to people to define the test scenarios and methods to test each feature in the feature catalogue 22:02:04 Dug: can the scenario doc be the same template for each ws-ra spec? 22:02:29 Gil: can we agree to basic principles for each scenario. 22:03:07 Gil: E.G. any person who is not a member of the WG should be able to understand the contents of each test scenario 22:03:49 ACTION: Dug to create a template for test scenario Doc to use for all of the WS-RA specs 22:03:49 Created ACTION-161 - Create a template for test scenario Doc to use for all of the WS-RA specs [on Doug Davis - due 2010-05-19]. 22:03:50 -li 22:03:52 WS_WSRA()11:00AM has ended 22:03:54 Attendees were [Microsoft], +1.571.262.aaaa, +1.571.262.aabb, Vikas, asoldano, Yves, li 22:35:29 Zakim has left #ws-ra 22:37:27 Gil: Mex needs a primer. 22:37:29 Bob: Katy has volunteered to write the primer on MEX 22:39:24 Topic: Next F2F 22:42:00 Feature Catalog volunteers: 22:42:02 Gil: Eventing, EVD 22:42:39 Katy - MEX 22:42:54 Ram - Transfer 22:43:29 Dug - Frag, SA 22:44:11 Dave S - possibly for Enum 22:49:43 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9607 22:50:52 Topic: review Responses to reviewers 22:51:16 Wu has joined #ws-ra 22:51:29 Please indicate your agreement or disagreement to this resolution by a reply to this email 22:51:58 Agreed we need to add above sentence to each response 22:52:40 Agreed to send response on 9607 to Gil with the added sentence 22:53:28 Topic: Response to Issue 9608 reviewer 22:53:30 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9608 22:55:03 agreed to add the additional para to Tom's suggestion: "the WG 22:55:05 believes that the number of potential items in the enumeration, while 22:55:07 interesting, isn't nearly as valuable as the total size of the 22:55:09 enumeration (total byte count of the data, not just the # of items). 22:55:10 This would allow for better pre-allocation of resources than simply 22:55:12 knowing the number of items. However, since calculating the total 22:55:13 size of the entire enumerated data set could be very expensive, the 22:55:15 cost of doing this at Enumerate() time didn't seem to be worth the 22:55:16 additional cost." as well as the boilerplate last sentence 22:56:09 Also make the bug number correct in the response (9608) 22:57:00 Topic Response to issue 9609 22:57:26 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9609 22:57:28 Agreed to send proposal from Gil on response 22:57:56 Topic Response to issue 9611 22:57:57 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9611 22:59:41 Wu has joined #ws-ra 23:00:44 Dug: I an not happy with the first paragraph, since there is nothing in the spec which states you can put multiple event reports in a wrapped format (even if they have the same action value) 23:01:33 q+ 23:01:47 Wu: however we can do this today, without violating the ws eventing spec 23:03:11 Gil: I would not accept this unless we had a paragraph in the spec regarding whether the order is significant (e.g., switch open/ switch close / switch open). It would be dangerous to imply you can do this unless you have text stating the assumptions on ordering in time 23:04:03 Dug: we also have to be concerned about the faulting of specific event reports in the batch. We have not thought about this in the spec, so I do not like us implying this as a possibility in our response 23:04:52 Bob: how about removing the second sentence of first para 23:06:05 Also, remove "Beyond that, the group feels:" as the second para intro 23:06:19 Add the boilerplate last sentence 23:12:30 Wu: why cannot we add text to the spec regarding using wrapped to do some form of batching? 23:13:16 Bob: that would have to be raised as a new issue, it is not available at this time to put in a response to the ws-management group 23:14:58 Topic: Response to Reviewer of Issue 9612 23:15:00 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9612 23:16:59 agreed to send with additional boiler plate last sentence 23:18:07 Wu has joined #ws-ra 23:18:26 Topic: Response to Reviewer of Issue 9613 23:18:28 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613 23:18:47 Agreed to send as is with addition of final boiler plate sentence 23:19:39 Proposed response: The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support 23:19:41 Topic: Response to Reviewer of Issue 9700 23:19:43 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700 23:20:47 Ram: I posted my proposed response just above 23:23:34 The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support a particular conten 23:23:42 Dug: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server otion 23:23:49 of Content attribute allowing a service to return any content type. 23:26:10 The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. 23:26:21 This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. 23:26:30 Hence, there is no need for a fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type. 23:27:07 [1] “When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".” 23:29:26 The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a... 23:29:27 ...fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type by a client. [1] “When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any". 23:34:07 Add first para: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server option 23:36:08 Further, if the client wants a particular content type or format, it can request that by specifying that in the GetMetadata request. 23:47:43 public-ws-resource-access-comments@w3.org 23:49:12 Topic: Response to reviewer of Issue 9558 23:49:14 Bob responded to Fred on this 23:52:38 recessed until tomorrow at 9:00 23:52:48 rrsagent, generate minutes 23:52:48 I have made the request to generate http://www.w3.org/2010/05/12-ws-ra-minutes.html Bob 23:55:19 http://www.w3.org/TR/ws-policy/#Policy_References 23:57:07 gpilz has left #ws-ra