13:00:17 <RRSAgent> RRSAgent has joined #ws-ra
13:00:17 <RRSAgent> logging to http://www.w3.org/2009/03/10-ws-ra-irc
13:00:19 <trackbot> RRSAgent, make logs public
13:00:19 <Zakim> Zakim has joined #ws-ra
13:00:21 <trackbot> Zakim, this will be WSRA
13:00:21 <Zakim> ok, trackbot; I see WS_WSRA(F2F)9:00AM scheduled to start now
13:00:22 <trackbot> Meeting: Web Services Resource Access Working Group Teleconference
13:00:22 <trackbot> Date: 10 March 2009
13:01:33 <Zakim> WS_WSRA(F2F)9:00AM has now started
13:01:40 <Zakim> + +1.908.696.aaaa
13:02:47 <Zakim> +[IBM]
13:03:02 <dug> anyone else on the line?
13:03:13 <dug> we dialed in
13:03:55 <Zakim> +Yves
13:06:00 <Katy> Katy has joined #ws-ra
13:11:21 <dug> zakim, who is here?
13:11:21 <Zakim> On the phone I see +1.908.696.aaaa, [IBM], Yves
13:11:22 <Zakim> On IRC I see Katy, Zakim, RRSAgent, li, dug, trackbot, Yves
13:11:38 <dug> who is 908?
13:11:57 <dug> is anyone on the phone?
13:12:01 <dug> yves?
13:12:22 <Yves> I'm on the phone yes
13:12:23 <li> hi dug, 908 is li li
13:12:34 <dug> yves can you hear us on the phone?
13:13:09 <dug> zakim, aaaa is Li
13:13:09 <Zakim> +Li; got it
13:27:50 <Geoff> Geoff has joined #ws-ra
13:29:36 <asir> asir has joined #ws-ra
13:29:52 <Bob> Bob has joined #ws-ra
13:30:42 <Bob> meeting: W3 WS-Resource Access Working Group
13:31:29 <TRutt> TRutt has joined #ws-ra
13:31:56 <Ashok> Ashok has joined #ws-ra
13:36:22 <Bob> scribe: Sreedhara 
13:36:50 <gpilz> gpilz has joined #ws-ra
13:37:10 <Bob> scribe: Tom Rutt
13:37:18 <Bob> scribenick: TRutt
13:39:02 <TRutt> Topic: IRC admin
13:40:14 <TRutt> Bob asked members to watch IRC as it is happening, and if it does not match what they think it should be stating, they should make real time additions/corrections into the irc chat area themselves.
13:43:50 <TRutt> Topic: timing of issue discussions
13:44:38 <TRutt> Bob stated that he would allow a one week postponement of a scheduled vote is any member requests an extra week to consider an issue before the vote.
13:44:47 <asir> q+
13:45:09 <asir> q-
13:46:31 <TRutt> s/is any member/if any member/
13:46:34 <Wu> Wu has joined #ws-ra
13:46:59 <ircleuser> ircleuser has joined #ws-ra
13:48:28 <TRutt> Asir: In our opiniion. Geoff was not given sufficient time to present his full proposal.
13:49:25 <TRutt> Topic: Minutes of prior meetings
13:51:31 <Bob> Minutes of 2009-02-24 http://www.w3.org/2002/ws/ra/9/02/2009-02-24.html
13:51:31 <Vikas> Vikas has joined #ws-ra
13:51:39 <Geoff> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0027.html
13:52:15 <TRutt> Comments made by Geoff relative to editied version of minutes as posted.
13:52:27 <TRutt> s/editied/edited/
13:53:43 <TRutt> Bob: could Geoff express which of his concerns were not reflected in the edited minutes
13:59:34 <li> msg wu hi
14:00:51 <TRutt> Geoff: We believe that the statement "Will more discussion help the decision?" shuld have been stated "Willo more discussion of Geoff's proposal help the decision?"
14:01:46 <TRutt> The group reviewed the minutes and several members stated that the context at that point in the discussion was regarding both contributions.
14:02:34 <TRutt> The minutes were accepted by the working group with Geoff Bullen registering his objection in the email referenced above.
14:02:57 <asir> Not several members .. just two members
14:03:07 <TRutt> Minutes March 3,2009
14:03:09 <asir> stated that the context ...
14:03:14 <Bob> http://www.w3.org/2002/ws/ra/9/03/2009-03-03.html
14:03:31 <gpilz> make that 3 (me)
14:04:28 <Zakim> + +1.408.274.aabb
14:05:06 <TRutt> s/Willo more/Will more/
14:05:18 <dug> 4 - ibm too
14:05:50 <TRutt> No objections to approval of March 3 minutes
14:06:36 <TRutt> Topic: Revised agenda
14:06:37 <TRutt> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0020.html
14:06:54 <Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0020.html
14:09:04 <TRutt> Agreed to add three new issues which have arrived since the preparation of the agenda.
14:10:02 <Geoff> +q
14:12:12 <TRutt> Bob summarized the agenda, and asked if there were any requested changes.
14:12:21 <Katy> q+
14:12:25 <asir> q+
14:12:41 <Bob> ach geo
14:12:45 <Bob> ack geo
14:12:48 <TRutt> Geoff: what about discussions regarding the TAG?  We would like that discussion to be in the first two days.
14:12:52 <Bob> ack kat
14:13:50 <TRutt> Bob: lets spend a fair amount of first day on eventing, then move on if not completed on the second day
14:14:39 <TRutt> Bob: after first day will try to spend some time on each of the issues.
14:16:39 <TRutt> Bob: on the third day we can focus on the general discussion items.
14:17:05 <TRutt> TAG discussion agreed to be after lunch first day
14:17:36 <TRutt> Agenda, as modified was accepted by the group.
14:17:44 <TRutt> Topic: WG Administrivia
14:19:03 <TRutt> adding a f2f at the W3C  Tech Plenary 2-6 November in Santa Clara; Potential WG meeting 11/2,  3, 5, and 6 (Must respond by March 18)
14:19:13 <asir> ack asir
14:19:17 <Vikas> Vikas has joined #ws-ra
14:19:27 <Bob> ack yves
14:20:06 <TRutt> Yves: this gives us an opportunity to meet with the TAG, if we and they want to do so
14:21:17 <TRutt> No objection to having WG meetings at TPAC in November.
14:21:35 <TRutt> Discussion ensued on how may days of meeting are appropriate for the WG.
14:22:21 <TRutt> Agreed that Bob will ask for Two adjacent days for WG meetings at the TPAC in November
14:22:49 <TRutt> Topic: New Issues
14:23:58 <TRutt> Question on action items review.
14:24:37 <TRutt> Bob: I closed all action items which are completed, I suggest all members go thru the open action item list and work to close the ones assigned to themselves.
14:25:21 <fmaciel> fmaciel has joined #ws-ra
14:25:46 <TRutt> -Issue-6648 Eventing: define extensibility model for WS-Eventing http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648   -Pilz
14:26:12 <TRutt> Gill agreed to be the Issue owner.  No objection to opening this new issue
14:26:35 <TRutt> ID 6661
14:26:40 <Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
14:26:59 <TRutt> No objection to opening issue 6661 with Gil as owner.
14:27:08 <TRutt> Id 6666
14:27:27 <TRutt> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6666
14:27:42 <TRutt> No objection to open issue 6666 with Dug as owner.
14:28:15 <Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
14:28:27 <Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6672
14:28:47 <TRutt> No objections to open issue 6672 with Dug as owner
14:28:57 <TRutt> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6673
14:29:11 <TRutt> No objections to open issue 6673 with Dug as owner
14:29:17 <TRutt> id 6674
14:29:25 <TRutt> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6674
14:29:52 <TRutt> There is a general issue on updating references.
14:30:18 <TRutt> Agreed that 6674 is a duplicate of the existing general 'review references' issue
14:30:28 <TRutt> Geoff: that is 6570
14:30:33 <TRutt> id 6675
14:30:40 <TRutt> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6675
14:31:14 <TRutt> No objection to open issue 6675 with Gil as owner
14:31:30 <TRutt> id 6674
14:31:41 <TRutt> Id 6676
14:31:49 <TRutt> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6676
14:32:03 <TRutt> No objection to open 6676 with Gil as owner.
14:33:28 <TRutt> Topic: Issues with proposals
14:33:38 <TRutt> Issue 6424
14:34:38 <Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0026.html
14:34:39 <TRutt> Wu presented his latest email
14:34:58 <gpilz> q+
14:38:14 <TRutt> Gil: I do not understand the addition of the wsa:To header to the subscription request
14:38:27 <Bob> ack gpi
14:38:46 <dug> every time I see 'ack ...' I keep thinking of Bill the cat
14:39:13 <TRutt> Gil: if wsa:To is not present, is the event source given value anonymous?
14:39:16 <TRutt> Wu: yes
14:39:26 <Katy> q+
14:39:34 <TRutt> Gil: None of this is explained in the text
14:40:43 <Bob> ack kat
14:40:51 <asir> q+
14:41:02 <TRutt> Wu: we state "The REQUIRED [event source] property provides the value of the WS-Addressing
14:41:02 <TRutt> wsa:To element.
14:41:06 <dug> perhaps a rewording of that line would help?
14:42:42 <TRutt> Gil: is the event source from the point of view of subsriber of the event source?
14:42:52 <dug> The [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.
14:42:54 <dug> q+
14:43:02 <TRutt> Wu: from the view of a subscription message from subscriber to event source.
14:43:03 <Bob> ack asir
14:43:13 <Yves> http://www.w3.org/TR/soap12-part1/#soapenvelope
14:43:21 <Yves> infoset constructs are not hard to read
14:43:43 <dug> Yves - personally I think infoset hurt wsa and soap specs  :-)
14:43:46 <gpilz> q+
14:44:10 <Yves> dug; infoset allows things like MTOM and use of other encodings of the envelipe
14:44:21 <TRutt> Asir: we could accept Wu's proposal, with understanding that additional issues can be raised to clarify specific text later
14:44:35 <dug> I understand why they were added - but I think they hurt more than they helped.
14:45:02 <Bob> q?
14:45:08 <Bob> ack dug
14:45:28 <dug> The [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.
14:45:44 <asir> I believe that Wu's proposal is a template for global changes
14:45:49 <TRutt> Gil: I like this new wording
14:46:09 <dug> The REQUIRED [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.
14:46:11 <TRutt> Wu: this new wording is acceptable, however we have to be careful on cardinality
14:47:15 <gpilz> The wsa:To element is populated by the REQUIRED [event source] property.
14:48:08 <TRutt> Wu: I prefer "provided" to populated
14:48:14 <gpilz> The value of the wsa:To element is provided by the REQUIRED [event source] property.
14:49:18 <Bob> q?
14:49:29 <Bob> ack gpi
14:49:48 <TRutt> Dug: maybe we should map the ws eventing infoset to the appropriate ws addresssing infoset
14:50:33 <TRutt> Dug: however Event source property would need to get mapped to destination plus reference properties
14:51:09 <dug> The value of the WS-Addressing  [destination] and [ref params] properties is provided by the REQUIRED [event source] property.
14:51:10 <TRutt> Discussion on the event source as an EPR vs an IRI
14:51:19 <dug> s/is/are/
14:52:43 <TRutt> gil: however wsa:To is just a uri, but the event source EPR also can include ref parms
14:52:59 <gpilz> gil: and metadata
14:53:46 <Vikas> Vikas has joined #ws-ra
14:54:18 <Wu> wu
14:54:18 <dug> q?
14:54:22 <Wu> q+
14:54:40 <Bob> ack wu
14:54:47 <gpilz> q+
14:56:21 <DaveS> q+
14:56:45 <TRutt> Gil: could have general discussion on ws addressing addressing properties, but don not have text describin the wsa headers.  Only discuss wse headers in the text
14:57:12 <jeffm> jeffm has joined #ws-ra
14:58:23 <Bob> The values of the WS-Addressing [destination] and [ref params] properties are provided by the REQUIRED [event source] property.
14:58:44 <TRutt> replace from   /s:Envelope/s:Header/wsa:To   The REQUIRED [event source] property provides the value of the WS-Addressing wsa:To element.  
14:58:49 <Bob> q?
14:59:17 <li> +q
14:59:19 <TRutt> Geoff: what about the wsa:Action text in this section
14:59:36 <Bob> ack gil
14:59:36 <dug> Geoff - that might be handled by the new issue I opened the other day 
14:59:40 <TRutt> Bob: lets first discuss the replacement of the wsa:To line
15:00:20 <Bob> ack gp
15:00:25 <TRutt> DaveS: there is no way to reconstrict event source EPR from the headers in the subscribe message
15:00:32 <Bob> ack dave
15:00:42 <gpilz> q+
15:01:03 <asir> q+ to point out symmetry
15:01:22 <Zakim> - +1.408.274.aabb
15:01:24 <Wu> q+
15:01:25 <Bob> ack li
15:01:35 <gpilz> q-
15:01:51 <TRutt> DaveS: leave this text out say "ws addressing shall populate its headers as appropriate from the information in the event source epr"
15:02:22 <Bob> +1 , Li
15:02:37 <TRutt> Li: section 3.3 of ws addressing core text should not be repeated
15:02:44 <Bob> q?
15:02:50 <Bob> ack asir
15:02:52 <Zakim> asir, you wanted to point out symmetry
15:02:52 <TRutt> Li: put reference to ws addressing text
15:03:41 <Bob> ack wu
15:03:48 <dug> The [event source] is used as the target endpoint reference of the Subscribe and is processed per WS-Addressing.
15:04:02 <dug> s/the Subscribe/the Subscribe message/
15:04:23 <DaveS> +1 to dug's text
15:04:54 <TRutt> Wu: I like Bob's text change for wsa:To, but suggest we keep the text on wsa:Action
15:05:08 <asir> Dug - alternate to what? 
15:05:20 <gpilz> q+
15:05:50 <TRutt> Dug: I intend my new text to replace the wsa:To line in the proposal
15:06:22 <Bob> ack gp
15:06:46 <TRutt> Gil: given Action value is a constant for this operation type, why does it need to be mapped to an infoset property?
15:07:18 <TRutt> Wu: infoset properties can be constants, there is no restriction against them having constant value
15:07:59 <dug> its too bad that someone didn't just write an XML->Infoset converter/rules and then we could just keep the spec as XML.
15:08:14 <TRutt> Wu: should the receiver reject the message if the wsa:Action value is incorrect?
15:08:24 <Bob> The [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
15:08:51 <Yves> dug; by "keep the spec as XML" you mean "easily transform the spec to infoset at publication time, and keep the master as XML" ? :)
15:09:06 <TRutt> Wu: add "REQUIRED" after "The"
15:09:07 <Bob> The REQUIRED [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
15:09:29 <Bob> The REQUIRED [event source] property is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
15:10:05 <TRutt> Agreed to replace the text:
15:10:12 <TRutt>   /s:Envelope/s:Header/wsa:To   The REQUIRED [event source] property provides the value of the WS-Addressing wsa:To element.  
15:10:26 <TRutt> with
15:10:34 <gpilz> q+
15:10:36 <TRutt>  The REQUIRED [event source] property is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
15:10:59 <TRutt> No objection to replacement suggested by Bob
15:11:42 <Bob> ack gp
15:13:23 <TRutt> Gil: does the action property have type of wsa:action?  Is there a type for an infoset property?
15:13:54 <gpilz> [action] : IRI (1..1)
15:14:15 <gpilz> [destination] : IRI (1..1)
15:14:24 <gpilz> [source endpoint] : endpoint reference (0..1)
15:14:27 <TRutt> Text under discussion: "[action]: wsa:[action]"
15:14:56 <TRutt> Bob: we need to review this for correct xml infoset syntax at some time.
15:15:23 <dug> Add this after the previous text we just agreed to:  The REQUIRED WS-Eventing [action] property is mapped to the WS-Addressing [action] property.
15:15:59 <dug> hmm, or is the mapping the other way around
15:16:10 <TRutt> Gil: the action is of type "IRI" , however do we need to claim that wse action is always the same value as wsa:action property.  Why do we need two properties? There is only one action header in the message.
15:16:31 <Katy> q+
15:16:44 <Bob> ask kat
15:16:50 <TRutt> wu: in the future wse action property value may not map directly to wsa action value
15:16:52 <dug> ack kat
15:16:59 <li> q+
15:17:19 <dug> should it be  [action]:  http://.../Subscribe
15:17:47 <gpilz> [event source]: endpoint reference (1..1)
15:17:52 <TRutt> Katy: this should be type, not a value
15:18:01 <gpilz> [action]: IRI (1..1)
15:18:21 <Bob> ack li
15:19:06 <gpilz> q+
15:19:34 <dug> [action]: IRI 
15:19:36 <dug> Identifies the semantics of this message - and MUST be http://.../Subscribe
15:19:43 <Bob> ack gp
15:20:03 <TRutt> Bob: question under discussion is what should be the proper syntax for the line "[action]: wsa:[action]"
15:20:26 <TRutt> Gil: an important question is whether wse should have its own action property, distinct from wsa:action property
15:20:46 <TRutt> Gil: I do not believer wse needs its own action property
15:20:53 <TRutt> s/believer/believe/
15:21:01 <Katy> q+
15:21:12 <gpilz> q+
15:21:48 <Wu> q+
15:22:07 <dug> q+
15:22:13 <Bob> ack kat
15:22:27 <TRutt> Li: I believe we should have wse action property, since its infoset needs to be complete on its own.   If ws addressing is used, the wse action maps to the wsa action value.  We are assigning a different contractual meaning to the two infoset properties.
15:23:35 <TRutt> Katy: The fact that we are using the infoset notation requires that we define an action value for eventing.
15:23:53 <DaveS> This should read [action]: IRI (1,1) which defines the type, and any thing about the value shoud go below
15:24:28 <Bob> q?
15:24:55 <Bob> ack gp
15:28:28 <Zakim> +JeffM
15:28:45 <Sree> Sree has joined #ws-ra
15:32:40 <Sreed> Sreed has joined #ws-ra
15:33:44 <Sreed> Test
15:35:23 <Bob> q?
15:35:43 <jeffm> yes, but i am muted
15:36:20 <Bob> Ack wu
15:37:06 <gpilz> q+
15:37:15 <Bob> ack dug
15:37:23 <TRutt> Wu: currently ws eventing is piggybacked on ws addressing.  For completeness of modeling it is appropriate to have a property wse action
15:37:59 <Wu> q+
15:38:35 <TRutt> Dug: the reason we are using action is because we are using ws addressing.  If addressing later addes a user ID propety would we need to add a new wse infoset property for this user ID property?
15:38:42 <TRutt> s/addes/adds/
15:39:11 <TRutt> Dug: was action is not really even necessary for wse
15:40:42 <TRutt> Dug: eventing should define the minimum properties it needs
15:40:58 <DaveS> q+
15:41:22 <TRutt> Wu: but it is in the current version of the spec, wse required the action value
15:41:28 <Bob> ack gp
15:41:37 <TRutt> Dug: yes addressing requires it, but why should the wse infoset require it?
15:42:32 <Bob> ack wu
15:42:44 <li> q+
15:42:46 <asir> q+
15:43:06 <Bob> ack dave
15:43:18 <TRutt> Gil: I would take out wse:action as an infoset property, is is not an abstract property of ws eventing.
15:43:22 <DaveS> Delete [action] section from the red and grey.
15:43:22 <DaveS> In the white text below:
15:43:22 <DaveS>    This property MUST have the value http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe
15:43:57 <Bob> ack li
15:44:47 <Wu> q+
15:45:04 <Vikas> Vikas has joined #ws-ra
15:45:37 <dug> Gil - mex is now fixed (the ns/enum issue)
15:46:12 <Bob> ack asir
15:46:34 <gpilz> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
15:46:44 <TRutt> Li: expressed concerns about being tied too much to ws addressing.  Having a separate property for wse is advantageous in my opinion.
15:46:57 <Bob> ack wu
15:47:05 <gpilz> q+
15:47:16 <TRutt> Asir: I also prefer to just have the ws addressing property for action
15:48:17 <TRutt> Wu: I can accept the proposal from Dave S, to define use of wsa:action in the xml text itself, and remove the wse infoset property for action.
15:48:29 <Bob> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
15:49:16 <TRutt> above sentence replaces   /s:Envelope/s:Header/wsa:Action  This REQUIRED element provides the value of the [action] property. If a SOAP  Action URI is used in the binding for SOAP, the value indicated herein MUST be used  for that URI.  
15:49:36 <Bob> in addition action would be removed from the red on grey text
15:49:37 <TRutt> delete wse:action as its own infoset property
15:49:45 <dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#put
15:49:50 <dug> q+
15:49:58 <Bob> ack gp
15:51:35 <TRutt> replace 
15:51:39 <TRutt>   /s:Envelope/s:Header/wsa:Action  This REQUIRED element provides the value of the [action] property. If a SOAP  Action URI is used in the binding for SOAP, the value indicated herein MUST be used  for that URI.  
15:51:40 <TRutt> with
15:51:53 <TRutt> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
15:52:11 <TRutt> and remove action from wse infoset
15:52:16 <dug> s:Envelope/s:Header/wsa:Action
15:52:18 <dug>     This required element MUST contain the value http://www.w3.org/2009/02/ws-tra/Get. If a SOAP Action URI is also present in the underlying transport, its value MUST convey the same value. 
15:52:23 <dug> q?
15:52:46 <Bob> ack dug
15:54:03 <TRutt> replacement text needs to include first line: /s:Envelope/s:Header/wsa:Action This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
15:54:06 <dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#put
15:55:02 <Wu> q+
15:56:16 <li> q+ 
15:56:24 <Wu> q-
15:56:52 <Bob> ack li
15:57:21 <TRutt>   Replace:  /s:Envelope/s:Header/wsa:Action  This REQUIRED element provides the value of the [action] property. If a SOAP  Action URI is used in the binding for SOAP, the value indicated herein MUST be used  for that URI.  With:  /s:Envelope/s:Header/wsa:Action This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"  
15:58:26 <TRutt> also delete the infoset parameter wse action
16:00:58 <jeffm> i'm just pleased as punch to approve
16:01:16 <TRutt> No objection to proposed change of deletion of infoset property wse action, and replacement of paragraph above
16:01:19 <gpilz> q+
16:01:19 <jeffm> it's swell
16:01:33 <Bob> ack gp
16:02:00 <TRutt> Gil: this looks good for ws eventing, is this proposal just for ws eventiing?  what about the other specs
16:02:15 <dug> q+
16:02:34 <TRutt> Gil: I am happy to apply this to ws eventing, I would like to see a similar set of markup text for the other specs as well.
16:03:06 <TRutt> Bob: the issue we are discussing is limited to the context of ws eventing.
16:03:30 <Geoff> +q
16:03:37 <Bob> ack geoff
16:03:40 <TRutt> Bob: we can later open up new issues, one for each of the other specs, to do similar things
16:04:44 <Bob> ack geo
16:04:50 <dug> ack dug
16:04:59 <dug> lunch!  ;-)  
16:06:14 <TRutt> Bob: We seem to have agreed to apply this the same way to all the specs, however we need to open specific issues for each of the other specs.  The resolution of these new issues will require explicit text for approval by the WG.
16:07:05 <TRutt> Bob: any general resolution would have to be followed by explicit text changes for each spec.
16:07:35 <TRutt> Geoff: is there a general agreement on this direction as a general resolution?
16:08:40 <Zakim> + +1.408.274.aacc
16:08:58 <jeffm> it is too hard to mute/unmute to say no objections
16:09:02 <fmaciel> zakim, aacc is fmaciel
16:09:02 <Zakim> +fmaciel; got it
16:10:27 <TRutt> Discussion on whether we now have a fully enabling proposal to resolve Issue 6424.
16:11:33 <dug> Either way Wu will probably be doing the work  ;-)  
16:14:09 <TRutt>   Bob: will anyone object to having the editors apply similar changes as a proposed resolution to the rest of the eventing spec sections, and also for all the other specs?  
16:14:11 <TRutt>   Bob: will anyone object to having the editors apply similar changes as a proposed resolution to the rest of the eventing spec sections, and also for all the other specs?  
16:14:14 <TRutt> ACTION: 
16:14:45 <TRutt> bob will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs.
16:15:16 <Bob> action: bob will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs.
16:15:37 <TRutt>      Bob: do we agree that the proposal (version 7) from Wu with the two text changes we approved above can resolve issue 6424?  
16:16:08 <TRutt> No objection to close issue 6424.
16:16:17 <Bob> s/close/resolve
16:16:27 <trackbot> Sorry, bad ACTION syntax
16:16:31 <trackbot> Created ACTION-33 - Will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs. [on Bob Natale - due 2009-03-17].
16:16:44 <TRutt> No objection to applhy this pattern to the rest of the ws eventing and the other specs.
16:16:55 <TRutt> s/applhy/apply/
16:17:16 <TRutt> Break for junch
16:17:18 <Zakim> -fmaciel
16:17:18 <jeffm> okie, dokie - enjoy lunch
16:17:30 <TRutt> s/junch/lunch/
16:17:32 <Zakim> -Yves
16:17:37 <li> drop off and see you at 1:00pm
16:17:59 <Zakim> -Li
16:18:13 <Zakim> -JeffM
16:59:55 <Zakim> +Li
17:01:34 <Zakim> +fmaciel
17:06:40 <Bob> We are resuming
17:07:39 <Zakim> +Yves
17:09:02 <Bob> scribe: David Snelling
17:09:18 <Bob> scribenick: DaveS
17:09:58 <DaveS> Topic: TAG Discussion
17:10:45 <Zakim> +JeffM
17:11:27 <Vikas> Vikas has joined #ws-ra
17:15:11 <DaveS> Ashok: The URI is the basis of the WWW. If the URI points to a Document and you do a Get, you get a document. If it point to a thing you get a "representation" of the thing, e.g. a picture of a house. The HTTP link-header form will contain links to metadata about the resource. This might be an approach we could take, e.g. point to the type of data we want about the resource.
17:15:52 <Bob> http://tools.ietf.org/html/draft-nottingham-http-link-header-03
17:17:08 <DaveS> Ashok: Should we consider using this strategy for getting access to metadata about a resource?
17:18:17 <DaveS> Bob: Other actives include SOAP over other protocols. This seems HTTP specific.
17:19:42 <DaveS> This is a generalization of Link_data to Http generally.
17:20:58 <Wu> Wu has joined #ws-ra
17:22:06 <DaveS> Bob: The "Team" comment with respect to transfer still stands as the supported TAG, e.g. why not just use URL's? and related issues.
17:24:06 <DaveS> Bob: There are some processing implications: Caching of representations, proxies, etc. The TAG see these as advantages vs. what impact they have on our work.
17:24:44 <DaveS> Asir: Is this really important to TAG or should we just proceed?
17:25:27 <DaveS> Bob: The last time the WS-A group followed the public comment process.
17:26:05 <DaveS> q+
17:26:38 <DaveS> Ashok: There was some concern that this working group might not start as a result of this issue. A lot of the problem centers on the EPR.
17:27:01 <dug> q+
17:27:09 <Bob> ack dave
17:28:41 <DaveS> DaveS: This issue is very old, back to the initial WS-A discussions.
17:29:13 <Bob> ack dug
17:29:51 <asir> q+
17:29:54 <gpilz> q+
17:29:56 <Bob> q+
17:30:02 <Bob> ack asir
17:30:03 <DaveS> Dug: There isn't much we can do here. The cat is out of the bag sine EPRs.
17:30:57 <DaveS> Asir: Do we need to approach them before?
17:31:41 <DaveS> Bob: We should use this opertunity to plan.
17:31:46 <Bob> ack gpi
17:32:53 <DaveS> Gil: Not all our specs actually require EPRs. E.g Subscription is all about SOAP.
17:33:18 <dug> q+
17:33:59 <Ashok> Ashok has joined #ws-ra
17:34:29 <Ashok> Link Header draft: http://tools.ietf.org/html/draft-nottingham-http-link-header-03
17:34:43 <gpilz> to ammend the minutes: it is easier to defend the use of EPRs in some of our specs than others because some of them (e.g. WS-Eventing, WS-Enumeration) are more SOAP-oriented than others
17:35:08 <asir> q+
17:37:11 <DaveS> Bob: First, the TAG talks about a lot of possible clients. We are much more SOAP only focused. These might XMLP related, rather than just http. We also use "posts" with is not so rest-ful.
17:38:26 <DaveS> Bob: We could provide an "overlay". Define what would happen if a GET was passed to one of our "resources".
17:38:35 <Yves> SOAP 1.2 uses HTTP GET
17:38:49 <Yves> the state of implementation of this is... not widely deployed
17:40:14 <Bob> q?
17:40:19 <DaveS> Bob: This would give us the chance to preempt them or we could just wait. We should decide on this.
17:40:22 <Bob> cak dug
17:40:27 <Bob> ack dug
17:40:32 <Bob> ack bob
17:41:11 <gpilz> q+
17:42:23 <DaveS> Dug: Transfer tries to walk a middle ground between http and SOAP. Options are abandon RPs or make a rest-ful equivalent. Similar problems with Mex. We should decide to prempt or not.
17:43:31 <Ashok> q+
17:43:46 <DaveS> Bob: The TAGs concern is not a SOAP issue.
17:43:49 <Bob> ack asir
17:44:23 <DaveS> Asir: Tx is http over SOAP (over whatever).
17:44:32 <dug> q+
17:44:50 <dug> no transfer is not http over soap - otherwise soap is missing a ton of stuff
17:45:11 <dug> s/soap is/transfer is/
17:46:58 <asir> s/whatever/any soap binding/
17:47:15 <Bob> ack gpi
17:47:26 <DaveS> Asir: Tx is http over SOAP (over any soap binding)
17:49:00 <DaveS> Gil: Enum and Eventing are very focused specs. Only ever talked to by soap clients. people might want to do both with a Tx resource.
17:49:50 <DaveS> Gil: We could describe a way to marshal RPs into ?-parms.
17:50:22 <asir> I think Gil is talking about how to map an EPR to an URI
17:50:25 <DaveS> Bob: we could do this as a WG note.
17:50:27 <Bob> ack yves
17:50:41 <asir> q+
17:52:03 <DaveS> ??: RPs are hard to do in ?-parms. There are also other parts of the message (context ext) that would need to be done. This is too much for this WG. We could define it for RP free EPRs.
17:52:07 <Bob> ack ashok
17:52:16 <Bob> s/??/Yves
17:52:35 <dug> q-
17:53:24 <dug> +1 to Ashok - w/o a clear issue from someone/tag we're just guess at a solution to an unknown problem
17:53:30 <DaveS> Ashok: If no one wants to look at this, we should just wait.
17:53:34 <Bob> ack asir
17:54:36 <DaveS> Asir: The dual use use case is a good one with we might want to address. 
17:54:58 <DaveS> Ashok: We can wait or be proactive.
17:55:11 <DaveS> q+
17:55:26 <Bob> ack dave
17:57:05 <DaveS> Bob: Does anybody want to work on a proposal in advance of a comment from TAG?
17:57:21 <dug> run yves run
17:57:22 <jeffm> i do not believe in the pre-emptive doctrine
17:58:01 <asir> don't know proposal for what :-)
17:59:18 <DaveS> Asir: What about the on going discussin?
17:59:47 <DaveS> Ashok: There is no real outcome from this discussion.
17:59:54 <asir> q+
17:59:54 <jeffm> i have another call to run - bob gets special exemption from attending since he is engaged in a far more important activity
18:00:04 <jeffm> i'll dial back in later if i can
18:00:13 <Bob> ack asir
18:00:14 <Zakim> -JeffM
18:00:22 <dug> Why didn't WSA have to answer the question of "what gets returned from a naked GET to an EPR?" ?
18:00:50 <DaveS> Asir: The WG will process any actual comments from TAG.
18:02:38 <DaveS> Bob: WS-A was never asked the question "what comes back" but a more abstract question was asked answered - accordingly.
18:03:12 <DaveS> Resolution: No one is interested at this time in preparing a premptive proposal.
18:05:43 <dug> 6400 - proposal:  http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html
18:05:54 <DaveS> Topic: Issue 6400 - Eventing-SubscriptionEnd violates WS-I BP
18:08:56 <Ashok> q+
18:10:31 <Bob> ack ashok
18:11:16 <DaveS> Discussion and clarification.
18:12:20 <DaveS> Wu: Do we put this new PortType into the spec? How does it change the spec.
18:12:41 <DaveS> Dug: Simply remove some an add a new porttype.
18:12:56 <li> q+
18:13:02 <DaveS> resolved: Accepted.
18:13:22 <Bob> acl li
18:13:28 <Bob> ack li
18:14:52 <DaveS> ??: Does this imply push only semantics?
18:15:06 <Bob> s/??/Li
18:15:30 <DaveS> Gil: It seems ok.
18:16:14 <DaveS> Bob: Postone overnight for thinking.
18:16:27 <DaveS> Bob: updated bugzilla.
18:17:26 <DaveS> Topic: Issue 6425 - Eventing-Clarify How to Address Event Source
18:17:32 <Bob> Proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/att-0112/00-part
18:18:41 <DaveS> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0024.html
18:20:33 <gpilz> q+
18:20:44 <Bob> ack gpi
18:20:47 <DaveS> Li: Closely related to the discussion this morning about [event source]. 
18:22:02 <dug> q+
18:22:21 <Bob> ack dug
18:22:29 <DaveS> Gil: There seems to be a lot of implicit (indirect) knowledge needed to understand this.
18:23:30 <DaveS> Dug: Is this really about all entities, or just event source, e.g. EndTo, etc.
18:24:07 <Geoff> +q
18:24:14 <DaveS> Gil: They are all EPRs.
18:24:25 <gpilz> wse:NotifyTo, wse:SubscriptionManager, wse:EndTo
18:24:29 <DaveS> Li: We could make it a blanket statement.
18:25:18 <DaveS> Dug: We should do this in all specs. Or borrow text from one of the other specs.
18:26:18 <Bob> ack geo
18:27:16 <asir> Transfer Web Service Resource: A resource is a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core] and can be represented by an XML Infoset. The resource's representation can be retrieved using the Get operation defined in [WS-Transfer]. 
18:27:19 <DaveS> Geoff: Doesn't the infoset work cover this?
18:27:21 <DaveS> Wu: Maybe, but woould prefer to see it stated explicitly.
18:27:40 <Bob> s/woould/would
18:28:11 <asir> And a metadata resource is defined as ...
18:28:12 <asir> When the representation of a resource is mex:Metadata, as defined in Section 4, or any other document format (e.g. [XML Schema: Structures],[XML Schema: Datatypes], [WSDL 1.1], [WS-Policy]) for which a mex:MetadataSection/@Dialect has been defined, then the resource is referred as 'metadata resource'. The representation of a metadata resource MAY be retrieved and/or updated as any other [WS-Transfer] resource. Specifically, the representation of a metadata resource M
18:28:38 <dug> All messages defined by this specification are sent to a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core] and can be represented by an XML Infoset.
18:29:20 <dug> All messages defined by this specification are sent to a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core].
18:30:30 <dug> All messages defined by this specification are sent to a Web service that is addressable by an EPR [WS-Addressing 1.0 Core]
18:31:32 <DaveS> Resoltion: Agreed to the above text.
18:31:36 <asir> where would you put it?
18:32:38 <DaveS> Bob: This resolves 6425, but there is general agreement that this approach should be used in all the specs.
18:33:27 <DaveS> DaveS: Put thsi text in where the first refference to a rsource is described.
18:34:06 <Zakim> -Yves
18:35:25 <DaveS> Topic: Issue 6428 - Eventing: Separate Event Delivery Mode and Format
18:35:40 <dug> Wu -don't you have a newer proposal?
18:35:52 <Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0020.html
18:39:16 <Geoff> we would prefer attributes
18:39:17 <dug> q+
18:40:03 <Bob> ack dug
18:41:18 <DaveS> Dug: The element approach is better for extensibility. 
18:42:27 <Geoff> q+
18:42:35 <Bob> ack geo
18:43:21 <DaveS> Geoff: This seems overly complicated. We would prefer simple solutions.
18:43:32 <DaveS> Geoff: What about policy?
18:43:52 <DaveS> Ashok: Policy should be easier with element approach.
18:44:56 <DaveS> Ashok: Extension is about what we don't know now. So the most open approach is best.
18:45:45 <DaveS> Resolution: Li to do an element oriented proposal, e.g format as an element.
18:46:29 <DaveS> Topic: 6429 - Eventing: Standardize Wrapped Event Sink
18:47:23 <gpilz> q+
18:48:17 <DaveS> Li: Basically add action URI to notify element.
18:48:52 <Bob> action: Li to prepare an element based proposal for issue 6428
18:48:52 <trackbot> Created ACTION-34 - Prepare an element based proposal for issue 6428 [on Li Li - due 2009-03-17].
18:49:41 <dug> q+
18:49:49 <DaveS> Gil: Should the action be a header rather than an attribute in the body?
18:50:11 <Bob> q?
18:50:15 <Bob> ack gp
18:50:20 <Bob> ack dug
18:51:13 <DaveS> Dug: 1) Use a single service for all wrapped messages. Then the application needs this information and the app has the body.
18:52:19 <DaveS> 2) Defining new formats needs includes other information that might be needed for one service to deal with multiple styles.
18:52:55 <Katy> q+
18:53:05 <DaveS> q+
18:53:13 <Bob> ?
18:53:17 <Bob> q?
18:53:21 <Bob> ack katy
18:53:53 <DaveS> Katy: Is there a way a bad action URI could cause a fault?
18:54:11 <DaveS> Ashok: Only if the service didn't recognize the action.
18:54:20 <Bob> ack dave
18:56:26 <DaveS> Dug: Note that to unwrap a wrapped message, use the actionURI as the was:action in an unwrapped message.
18:59:32 <DaveS> Gil: I would like to do a counter proposal.
19:00:05 <DaveS> ACTION: Gill to write a counter proposal to 6429.
19:00:05 <trackbot> Sorry, couldn't find user - Gill
19:00:33 <Bob> s/Gill/Gilbert
19:00:54 <Bob> ACTION: Gilbert to write a counter proposal to 6429.
19:00:54 <trackbot> Created ACTION-35 - Write a counter proposal to 6429. [on Gilbert Pilz - due 2009-03-17].
19:01:20 <DaveS> Break.
19:01:22 <li> q+
19:06:28 <Geoff> Geoff has joined #ws-ra
19:14:41 <DaveS> Discussion of what next.
19:16:11 <DaveS> Topic: Issue 6404 - MEX- define the MEX dialect
19:16:31 <Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0061.html
19:16:33 <Geoff> q+
19:17:01 <Bob> ack li
19:17:30 <Bob> ack geo
19:17:44 <DaveS> Li: Clarify that Gil will develop a counter proposal only to the action URI part of the proposal, not the rest.
19:17:48 <DaveS> Gil: Agreed.
19:18:37 <dug> q+
19:19:26 <gpilz> q+
19:19:55 <Ashok> q+
19:19:57 <DaveS> Geoff: Issues specific to Policy , Policy Attachment, and Schema. Do these make sense?
19:21:05 <DaveS> Gil: It is unclear what policy attachement means. WSDL and Schema are clear. and polocy is not so bad.
19:21:10 <Bob> ack dug
19:21:18 <Bob> ack gpi
19:22:25 <Geoff> q+
19:22:41 <Bob> ack ash
19:22:44 <DaveS> Dug: Grouping is arbitrary. Everything returned is service specific. The proposed definition meats the intent of the spec.
19:23:36 <DaveS> Ashok: If a dialect is not specified, can you return just anything? Im therefore uncomfortable.
19:24:16 <DaveS> Geoff: This is the "Whatever" issue.
19:24:25 <Bob> ack geo
19:24:26 <dug> s/Whatever/Whateva/   :-)
19:26:08 <DaveS> Geoff: The MEX group is what the default would be. But also other stuff could also be sent.
19:26:10 <DaveS> Dug: This is what I proposed.
19:26:16 <Geoff> q+
19:26:29 <Bob> ack geo
19:27:13 <dug> q+
19:28:51 <gpilz> q+
19:28:52 <DaveS> Geoff: No dialect = everything, MEX = those specification.
19:29:03 <dug> s/those/those specified in the MEX/
19:29:15 <dug> Dug proposal: no dialect = mex, mex = everything client can see
19:30:56 <Bob> ack gp
19:31:25 <DaveS> Gil: No dialect = everything leaves open doors to other formats.
19:31:41 <Ashok> q+
19:32:42 <DaveS> Gil: why woould I ask for stuff I didn't understand?
19:33:21 <DaveS> Geoff: I know what I expect from some other context. 
19:33:35 <Bob> ack dug
19:33:51 <Bob> ack ashok
19:34:32 <dug> q+
19:35:06 <DaveS> Ashok: Counter proposal - MEX = policy, schems, WSDL, ALL = everything you know. Prohibit nothiing.
19:35:51 <DaveS> geoff: Would like a default.
19:35:52 <Bob> ack dug
19:36:20 <Zakim> + +1.703.860.aadd
19:36:23 <DaveS> Dug: First resolve what the dialects mean.
19:37:22 <asir> Thanks Dug
19:38:06 <DaveS> Discussion about postponing this discussion pending other issues. All agreed.
19:39:29 <Sumeet> Sumeet has joined #ws-ra
19:39:57 <Zakim> - +1.703.860.aadd
19:40:54 <DaveS> Topic: Issue 6639 - MEX: make actionURIs consistent
19:41:20 <DaveS> Dug: Make it like the other 5 specs.
19:42:28 <DaveS> resolution: Agreed to 6639 as proposed by Dug.
19:43:10 <DaveS> Topic: Issue 6604 - MEX: Define a way to ask for more than one MEX dialect
19:43:49 <DaveS> Dug: Three choice, one dialiect, no dialect, MEX dialect, but no way to say what the client wants.
19:45:19 <Vikas> Vikas has joined #ws-ra
19:46:50 <DaveS> katy: What if the client can't return everything requested.
19:47:31 <DaveS> Dug: This is covered in the spec - empty section
19:48:15 <DaveS> Gil: What about duplicates?
19:48:42 <DaveS> Dug: Up to the service.
19:48:45 <DaveS> q+
19:48:57 <Bob> ack david
19:49:04 <Bob> ack dave
19:49:42 <DaveS> Asir: This is an optimization of multiple requests.
19:50:29 <DaveS> Geoff: If this enough, or do we provide a complete dialect selection language?
19:54:20 <DaveS> Asir: What about the migration path?
19:55:09 <Zakim> +Yves
19:55:21 <DaveS> Ashok: There will be other changes. I don't believe this is required by the charter.
19:55:38 <gpilz> The Web Services Resource Access Working Group will take as its starting point the Member Submission versions of WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-Eventing and  WS-MetadataExchange. In order to avoid disrupting the interoperability of existing implementations,  WS-MetadataExchange, WS-Transfer, WS-Eventing and WS-Enumeration should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submis
19:56:00 <gpilz> "offer a smooth migration path"
19:56:20 <Yves> smoothness is in the eye of the beholder
19:56:36 <gpilz> q+
19:56:58 <Bob> ack gp
20:00:51 <DaveS> Resolution: Agreed to the proposal to 6604 as in comment #1
20:02:20 <DaveS> There was some general discussion around how we address our charter requirement to "offer a smooth migration path". This is a separable issue, but Bob plans to track which issues may need migration actions later.
20:02:42 <marklittle> marklittle has joined #ws-ra
20:03:21 <Zakim> +Mark_Little
20:05:25 <DaveS> Bob: Will someone write a proposal.
20:05:56 <DaveS> ACTION: Geoff to write a draft proposal for management of migration notes.
20:05:57 <trackbot> Created ACTION-36 - Write a draft proposal for management of migration notes. [on Geoff Bullen - due 2009-03-17].
20:07:13 <DaveS> Topic: Issue 6500 - MEX: Wrappers around GetMetadata
20:08:17 <DaveS> Geoff: For consistencey with the resolution 6398.
20:09:25 <dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
20:09:43 <DaveS> ??: Proposed just renaming the Metadata element and moving the any.
20:10:00 <Zakim> +JeffM
20:10:09 <DaveS> s/??/Katy/
20:11:58 <gpilz> <mex:Metadata>
20:12:37 <dug> <mex:GetMetadataResponse>
20:12:39 <dug>   <mex:MetadataSection...> ... </mex:MetadataSection> *
20:12:41 <dug>    xs:any *
20:12:43 <dug> </mex:GetMetadataResponse>
20:13:34 <dug> <mex:GetMetadataResponse ...>
20:13:36 <dug>  <mex:MetadataSection...> ... </mex:MetadataSection> *
20:13:37 <dug>   xs:any *
20:13:39 <dug> </mex:GetMetadataResponse> 
20:16:51 <asir> q+
20:17:08 <Bob> ack asir
20:17:52 <DaveS> Asir: Is there really any change needed.
20:18:23 <DaveS> Gil: But what about xs:any.
20:18:35 <DaveS> Postponed to tomorrow.
20:21:09 <DaveS> Topic: Issue 6676 - WS-MEX 'pollicy attachment' dialect is underspecified
20:21:33 <asir> q+
20:22:11 <DaveS> Ashok: Policy covers the whole space any way.
20:23:03 <gpilz> q+
20:23:10 <Bob> ack asir
20:24:17 <DaveS> Asir: The dialect define the type of the returned element. In policy attachment case, it says it is here. 
20:24:49 <DaveS> Ashok: The spec says policy can be attached to various places.
20:25:20 <DaveS> Ashok: We need an example.
20:25:26 <Katy> q+
20:25:43 <DaveS> Asir: It returns a policy attachement association to external policy.
20:26:43 <DaveS> Postpone while people talk to home.
20:27:04 <DaveS> Topic 6675 - WS-MEX 'pollicy' dialect is underspecified
20:27:14 <DaveS> Topic: 6675 - WS-MEX 'pollicy' dialect is underspecified
20:27:21 <Bob> ack gpil
20:27:32 <Bob> ack katy
20:27:55 <DaveS> Gil: There are many policy types and where they can be attached, it need to be clearer what is meant by the dialect.
20:28:04 <asir> q+
20:28:23 <dug> so, in irc I have two tabs - a #ws-ra one and one for irc.w3.org:6665 - how does irc decide which msgs go to which tab?  some appear to go to both.
20:28:27 <Katy> q+
20:28:53 <Bob> ack asir
20:29:20 <DaveS> Asir: All the dialect says in the format of the message, not about what it means.
20:29:51 <gpilz> q+
20:30:20 <DaveS> Asir: The semantics is included in the metedata elements returned.
20:30:41 <Bob> ack katy
20:31:01 <DaveS> Dug: Clarification: they may only mean something if they are understood including relationships.
20:31:06 <DaveS> Asir: yes.
20:31:06 <Zakim> -JeffM
20:31:24 <Zakim> +JeffM
20:31:44 <DaveS> Gil: Whay just ask for policy?
20:31:54 <DaveS> Dug: Look for updates.
20:32:55 <DaveS> q+
20:33:36 <Bob> ack gpil
20:34:03 <DaveS> Gil: Maybe we just need to spell out just how little information is implied by MEX. e.g. just format and version.
20:35:23 <Bob> ack dave
20:35:59 <DaveS> Dave: If we just specific type etc, why are any of these included in MEX.
20:37:24 <DaveS> Dug: Either we include each URI and define them or do nothing.
20:37:37 <DaveS> Asir: The list is extensible.
20:38:33 <DaveS> Dug: What is in a WSDL respons only the binding is included?
20:39:39 <DaveS> q+
20:39:56 <Bob> ack dave
20:40:52 <DaveS> Dave: Could we just describe a namespace URI?
20:41:15 <DaveS> Gil: It should really point to a schema element.
20:43:12 <DaveS> Complicated multi part example discussed.
20:47:32 <DaveS> Bob: This is probably not the right issue for this discussion.
20:48:54 <DaveS> Bob: Propose close without action 6675.
20:49:26 <DaveS> Action: Gil to raise issue for explanatory text wrt 6675.
20:49:26 <trackbot> Sorry, couldn't find user - Gil
20:49:56 <DaveS> Bob: Propose to close 6676 with no action.
20:50:30 <DaveS> resolution: close 6676 and 6675 with no action
20:50:39 <Bob> Action: Gilbert to raise issue for explanatory text wrt 6675.
20:50:39 <trackbot> Created ACTION-37 - Raise issue for explanatory text wrt 6675. [on Gilbert Pilz - due 2009-03-17].
20:51:45 <DaveS> Bob: Near closing, so lets discuss schedule for tomorrow.
20:51:51 <DaveS> All: agreed.
20:55:51 <li> q+
21:00:31 <li> bob, we'd like to postpone 6430
21:00:36 <Zakim> -Mark_Little
21:00:57 <dug> q?
21:01:08 <DaveS> Bob: Please would all group members please look over the IRC chat now and raise issues now.
21:01:11 <Vikas> Vikas has joined #ws-ra
21:02:43 <DaveS> Li: Postone 6430 until after 6401 and some others relates.
21:03:29 <jeffm> bye
21:03:37 <DaveS> Resessed in 9:00 March 11.
21:03:41 <li> bye
21:03:42 <Yves> bye
21:03:44 <Zakim> -fmaciel
21:03:44 <gpilz> gpilz has left #ws-ra
21:03:46 <Zakim> -Yves
21:03:47 <Zakim> -JeffM
21:03:49 <Zakim> -[IBM]
21:03:52 <fmaciel> fmaciel has left #ws-ra
21:03:55 <Zakim> -Li
21:03:57 <Zakim> WS_WSRA(F2F)9:00AM has ended
21:03:58 <Zakim> Attendees were +1.908.696.aaaa, [IBM], Yves, Li, +1.408.274.aabb, JeffM, +1.408.274.aacc, fmaciel, +1.703.860.aadd, Mark_Little
21:05:00 <Bob> rrsagent, make logs public
21:05:10 <Bob> rrsagent, generate minutes
21:05:10 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-ws-ra-minutes.html Bob
21:40:51 <jeffm> jeffm has joined #ws-ra