15:54:46 <RRSAgent> RRSAgent has joined #ws-ra
15:54:46 <RRSAgent> logging to http://www.w3.org/2009/08/04-ws-ra-irc
15:54:48 <Zakim> Zakim has joined #ws-ra
15:56:20 <Zakim> WS_WSRA(F2F)11:30AM has now started
15:56:27 <Zakim> +[Microsoft]
15:57:26 <Zakim> + +1.617.324.aaaa
15:57:41 <dug> dug has joined #ws-ra
15:58:34 <Zakim> + +1.571.262.aabb
15:59:02 <Vikas> Vikas has joined #ws-ra
15:59:25 <Tom_Rutt> Tom_Rutt has joined #ws-ra
16:00:04 <Geoff> Geoff has joined #ws-ra
16:00:13 <li> li has joined #ws-ra
16:01:27 <Zakim> + +1.908.696.aacc
16:02:01 <li> zakim, aacc is li
16:02:01 <Zakim> +li; got it
16:03:02 <VikasV> VikasV has joined #ws-ra
16:05:28 <DaveS> DaveS has joined #ws-ra
16:06:34 <Ram> Ram has joined #ws-ra
16:07:14 <DaveS> scribe daves
16:07:29 <VikasV> VikasV has joined #ws-ra
16:10:33 <Bob> chair: Bob Freund
16:10:45 <DaveS> scribe: daves
16:10:48 <asir> asir has joined #ws-ra
16:11:32 <Vikas1> Vikas1 has joined #ws-ra
16:11:56 <Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0011.html
16:13:48 <DaveS> There are some issues around 6401 that might be worth addressing earlier than planed
16:14:51 <DaveS> Change order to put 7127 before 6401
16:15:07 <Bob> scribenick: DaveS
16:15:39 <DaveS> Resolved: Agenda approved as revided
16:16:12 <DaveS> resolved: Agenda approved as provided
16:16:37 <DaveS> Topic: Action review
16:16:49 <DaveS> All for this meeting are done - Well done.
16:17:29 <DaveS> On the horizon: Yves has two for mid August.
16:17:52 <DaveS> Yves says these are coming along OK.
16:18:15 <DaveS> Asir: To address 6403.
16:19:11 <DaveS> This may be delayed due to Paul's holiday.
16:20:28 <DaveS> Paul back 13 or 14 of August, so this may cause a major delay.
16:20:39 <DaveS> Asir: Can we discuss it here?
16:21:00 <Wu> Wu has joined #ws-ra
16:21:26 <DaveS> WS-Frag to be discussed shortly.
16:22:40 <DaveS> Open RT actions pending on Frag discussion.
16:22:58 <DaveS> Topic: Snapshot Review
16:23:07 <DaveS> New snapshots are up.
16:23:53 <dug> I think "frog" is reserved for eventing/mode discussions  
16:23:58 <DaveS> Bob: are the snapshots ok?
16:24:07 <DaveS> Asir: request 1 week.
16:24:40 <DaveS> resolved: Snapshot review in two weeks.
16:24:44 <VikasV> VikasV has joined #ws-ra
16:25:09 <DaveS> Topic: Frag Spec 
16:26:23 <Bob> s/Asir/Ram
16:26:29 <DaveS> Asir: Todos are at the bottom of the spec.
16:27:00 <DaveS> Doug: Suggests a review for general consensis. 
16:27:05 <Sreedhara> Sreedhara has joined #ws-ra
16:27:08 <DaveS> Plan for Wednesday.
16:27:22 <DaveS> Topic: Schedule
16:27:35 <Ashok> Ashok has joined #ws-ra
16:28:35 <DaveS> There may be a need to revise the charter. Bob provided the following revised schedule.
16:28:55 <DaveS> 2009-08-04 Bellevue F2F
16:28:55 <DaveS> 2009-09-11 Next WGD publication, Frag FPWD, distribution to other  
16:28:55 <DaveS> organizations for comment prior to Last Call
16:28:55 <DaveS> 2009-09-30 Hursley F2F
16:28:55 <DaveS> 2009-10-12 Last Call Announcement (minimum three week review), begin  
16:28:56 <DaveS> test preparation
16:28:57 <DaveS> 2009-11-02 Tech Plenary Santa Clara (F2F) Last call review complete
16:29:00 <DaveS> six week issue resolution?
16:29:02 <DaveS> 2009-12-18 Call for implementations, Publication of Candidate  
16:29:04 <DaveS> Recommendation, identification of features "at risk"
16:29:06 <DaveS> ten week test development? (christmas and New Year's weeks discounted
16:29:08 <DaveS> 2010-03-19 Publication of Proposed Recommendation, interoperable  
16:29:10 <DaveS> implementation criteria met or exceeded (minimum of four weeks)
16:29:12 <DaveS> 2010-04-30 Recommendation Published
16:31:14 <DaveS> Bob walked through this schedule highlighting communication points outside the group.
16:32:13 <DaveS> Some minor issues can be postponed until during the last call, e.g. Infoset development.
16:32:16 <Ram> q+
16:32:30 <dug> can you hear Geoff?
16:32:47 <DaveS> Goeff: When must all issues be closed?
16:32:49 <Bob> ack ram
16:32:50 <DaveS> At CR.
16:32:56 <li> can't hear geoff
16:33:06 <DaveS> Ram: What criteria for Last call?
16:33:39 <DaveS> Bob: Minor things that don't impact implementations won't stop last call.
16:34:16 <Yves> yes we can have open issue, and re-qualify them as LC ones
16:35:13 <Yves> non editorial, but not major ones (ie: not ones that would change the overall function of the specs)
16:35:31 <DaveS> This group considers it unfair to do a last call with major issues outsanding.
16:35:48 <jeffm> jeffm has joined #ws-ra
16:36:39 <DaveS> Bob: Goal - all major issues to be resolved by the end of Hursley F2F.
16:37:14 <DaveS> Bob: NB: Last call takes at least 3 weeks.
16:37:27 <DaveS> q+
16:37:52 <Geoff> q+
16:37:57 <DaveS> NB: Last call is a public review.
16:37:59 <Yves> all documents are for wide review, LC specifically as a call for outside review
16:38:11 <Bob> ank dav
16:38:17 <Bob> ack dav
16:38:24 <Bob> ack geo
16:38:38 <DaveS> Geoff: We have about 40 plus issues - are these goals realistic?
16:39:33 <DaveS> Bob: Our rate is variable. 6 days aof F2F plus calls.
16:39:35 <gpilz> gpilz has joined #ws-ra
16:40:05 <DaveS> Bob: Some of the newer one should be faster.
16:40:48 <vvarma> vvarma has joined #ws-ra
16:41:35 <DaveS> Bob provided a pep talk to work together. For example, after a long discussion we should act rather than delay.
16:42:37 <DaveS> Bob: Some specs could be moved forward separately.
16:43:05 <Bob> ack yve
16:43:28 <DaveS> Yves: Work can proceed during a last call.
16:43:59 <Yves> the at-risk features, etc...
16:43:59 <DaveS> Bob: In any case we can start testing development.
16:46:17 <DaveS> Bob: At risk means that they will be removed if interoperable implementations don't transpire.
16:46:58 <DaveS> Jeff: How many specs? And is it just pairwise?
16:47:24 <DaveS> Bob: The goal is full implementations. 
16:47:47 <Yves> I would note that pair-wise is the default in both IETF and W3C, nothing forbid us to put the bar higher than that, as long as it is stated explicitely in the SOTDs
16:48:25 <DaveS> Bob: An iplementation MUST implement all required features to qualify for testing.
16:49:04 <DaveS> Asir: Are these specific plan above and beyond the W3C process?
16:49:31 <DaveS> Bob: Yes. We will do what is needed plus sensible extra due dilegence.
16:51:02 <Ram> q+
16:51:15 <Bob> ack ram
16:51:34 <DaveS> Ram: Are all the specs to move in lock step?
16:51:49 <asir> q+
16:51:50 <DaveS> Bob: as we said earlier, they may move at different speeds.
16:52:09 <Bob> ack asir
16:52:29 <gpilz> gpilz has joined #ws-ra
16:53:25 <DaveS> Bob: It is a little unfair to use Xmass and New year as review time.
16:56:16 <DaveS> Ram: There is still some concern about unknowns.
16:57:03 <DaveS> E.g. New issues and preparation of interop scenarios.
16:57:12 <asir> q+
16:58:12 <Bob> ack asir
16:58:44 <DaveS> Asir: We could add an issue acceptance criteria.
16:59:27 <DaveS> Bob: At present we only admit by total concent.
17:00:12 <DaveS> Asir: We could set a deadline for further issues.
17:00:34 <DaveS> Bob hopes people are not sitting on issue at any time.
17:01:26 <Yves> resolving might be "with no action"
17:01:39 <Ram> q+
17:02:52 <DaveS> Asir: Can we open all issues this week?
17:03:07 <DaveS> Bob: Open all issues you can think of this week.
17:04:07 <DaveS> Asir: When is the next heart beat.
17:04:31 <DaveS> Bob: The last one was June 25. There fore the next one is September.
17:04:41 <Bob> ack ram
17:06:18 <DaveS> Asir: For last call there is four weeks.
17:07:00 <DaveS> Bob: the only rule is CL and CR are three weeks apart, we are offering 4.
17:07:11 <DaveS> s/CL/LC/
17:08:02 <DaveS> Asir: More time requested to think about the schedule.
17:08:35 <DaveS> Bob: To update the web site. This schedule is a target not cast in concrete.
17:09:05 <DaveS> Topic: New Issues
17:09:27 <DaveS> Issue 7236:
17:09:56 <DaveS> Suggested edits/cleanup of wrapped/unwrapped defintions. http://www.w3.org/Bugs/Public/show_bug.cgi?id=7136
17:10:17 <DaveS> Opened
17:10:57 <DaveS> Resolution: 7136 closed as proposed in the bugzilla.
17:11:31 <DaveS> Bob: Proposed that the rest of these be opened.
17:11:45 <DaveS> Resolution: All new issues opened.
17:12:05 <DaveS> Topic: Issue 6720
17:12:35 <DaveS> Transfer: Metadata returned by WS-Transfer GET unclear http://www.w3.org/Bugs/Public/show_bug.cgi?id=6720 
17:12:40 <dug> q+
17:12:57 <Bob> ack dug
17:13:27 <dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0066.html
17:15:03 <DaveS> Doug: There was some unecessary repetition as indicated in the email.
17:15:08 <dug> When the dialect value is used in conjunction with mex:MetadataReference or mex:Location, the dialect value provides the ability to include metadata by reference (an endpoint reference or a URL).
17:15:21 <asir> q+
17:15:27 <dug> As a result, the metadata returned by the Get request to a metadata resource's endpoint MUST be limited to a particular metadata type (@Dialect) and identifier (@Identifier). 
17:16:51 <dug> q+
17:17:41 <DaveS> Ashok: The mex dialect is there specifically. The information is repeated because people have asked for it.
17:18:49 <DaveS> Dooug: Will live with the repetition. 
17:19:01 <DaveS> s/Dooug/doug/
17:19:17 <Bob> ack dud
17:19:27 <Bob> ack dug
17:19:48 <DaveS> Asir:
17:20:30 <dug> q+
17:20:48 <DaveS> Asir: the number of dialects should be at the discression of the service. 
17:20:54 <Bob> ack asir
17:21:12 <Bob> ack dug
17:21:16 <DaveS> Therefore MUST is too strong.
17:21:50 <DaveS> Doug: The EPR points to a single metadata resource root element.
17:22:08 <DaveS> q+
17:22:45 <dug> q+
17:22:55 <DaveS> Asir: Is there some confusion here? 
17:23:35 <DaveS> Doug was talking about the mex dialect.
17:24:20 <DaveS> <getresponse>
17:24:44 <DaveS> <   schema | Definition | 
17:26:50 <DaveS> Doug: For a given Metedata-EPR an TX get should always return the same thing.
17:27:19 <DaveS> In the context of the spec something is confusing.
17:28:16 <DaveS> Asir and Doug: Suggest just droping the sentence "As a result, the metadata returned by the Get request to a metadata resource's endpoint MUST be limited to a particular metadata type (@Dialect) and identifier (@Identifier). "
17:29:56 <DaveS> Resolutiion: 6719 and 6720 approved with the deletion of the above sentence from 6720.
17:30:44 <DaveS> 15 minute break.
17:31:47 <Zakim> -Vikas
17:49:52 <DaveS> Restarting:
17:50:15 <DaveS> Topic: Issue 7127
17:50:51 <DaveS> Eventing: Can event information contained in notification  
17:50:54 <DaveS> be bound to soap:headers http://www.w3.org/Bugs/Public/show_bug.cgi?id=7127
17:52:07 <Wu> q+
17:52:15 <dug> q-
17:52:26 <DaveS> q-
17:52:29 <gpilz> q+
17:53:59 <DaveS> Tom: Clarify the the application level content is called "event infomration".
17:55:05 <DaveS> Tom's proposal is that this event information MUST all be in the body and not the header.
17:55:21 <Bob> ack wu
17:56:35 <DaveS> Wu: There needs to be clarity as to what goes in the body and the header. Likewise multi part is not of interest.
17:56:59 <Bob> ack gp
17:57:29 <DaveS> Gil: This presuposes a clear separation between application and infrastructure information.
17:59:34 <Tom_Rutt> q+
17:59:47 <DaveS> Gil: Basically we can't really decide this in the spec well enogh. What we need is a way to make the messages that the sink expects clear.
17:59:52 <Bob> ack tom
18:00:26 <dug> q+
18:01:47 <DaveS> Tom: This may be more complicated than I thought.
18:02:36 <DaveS> Gil: The default is very simple, e.g it is in the body as the child. thene there is extensibility.
18:02:42 <Bob> ack dug
18:03:39 <DaveS> Doug: Basically as a subscriber you get to chose the format of the delivered messages. Thi spec should not restrict it.
18:03:50 <Tom_Rutt> q+
18:04:10 <gpilz> gpilz has joined #ws-ra
18:04:13 <Bob> ack tom
18:04:28 <DaveS> Tom: Delay resoultion until we can close with no action.
18:05:32 <DaveS> Topic: 6401
18:06:23 <DaveS> Wu: Reviewed his proposal
18:07:20 <dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0012.html
18:07:51 <gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/att-0012/NotificationWSDL_for_6401-6661_v4_submit.htm
18:08:14 <Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/att-0012/NotificationWSDL_for_6401-6661_v4_submit.htm
18:18:11 <Zakim> +Vikas
18:20:46 <Geoff> q+
18:20:57 <Tom_Rutt> q+
18:20:58 <Bob> ack geo
18:21:30 <DaveS> Geoff: Is it necessary to have two wsdl (event source and notifications).
18:22:01 <DaveS> Wu: Yes.
18:22:04 <Bob> ack tom
18:22:22 <dug> q+
18:22:49 <DaveS> Tom: The Event source wsdl never generates code. only the notification-wsdl is used to generate code.
18:23:24 <Bob> ack dug
18:23:47 <DaveS> The Notification WSDL service element must be created dynamically after the subscribe.
18:23:50 <gpilz> q+
18:24:11 <DaveS> Dug: Why do we need abstract and concrete wsdl.
18:24:39 <DaveS> Wu: The abstract is only needed for raw type.
18:26:04 <DaveS> Dug: It looks like there is a lot of implicit knowlege in this approach.
18:26:34 <DaveS> Doug: How do I know which policy assertion to understand?
18:30:49 <DaveS> Wu: There are two bits of information conveyed: 1) the structure of the event content and 2) what kind of port you need to expose to receive them.
18:31:57 <li> q+
18:35:46 <DaveS> q+
18:37:31 <dug> Li - I don't know the events - that's part of the problem
18:37:37 <dug> I want to ask the source for the list of events
18:39:24 <gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0046.html
18:39:28 <Bob> ack gp
18:40:04 <dug> q+
18:40:11 <DaveS> Dave: The sequence is this: 1) Source advertises event types and delivery formats. 2) Subscriber chooses one of each. 3) he source generates events accordingly, and 4) the sink receives them as expected based on the subscribe sent.
18:40:22 <Bob> ack dave
18:42:05 <DaveS> Geoff; There may be another step in which the subscriber sets up to recieve them.
18:42:54 <Bob> ack li
18:42:58 <Bob> ack dug
18:43:19 <Wu> q+
18:45:38 <dug> Li -please write this down in a note
18:46:06 <dug> you're still listing off things that are assumed known to each side and I'd like to see the complete list so I can think about it
18:46:51 <dug> q+
18:47:00 <DaveS> Wu: What is the easiest way to move the existing outbound wsdl to a new format?
18:47:15 <DaveS> Tat is all that is happening here.
18:47:33 <DaveS> s/Tat/Wu" That/
18:48:12 <Bob> ack dug
18:48:17 <Bob> ack wu
18:48:46 <Geoff> q+
18:49:07 <DaveS> Doug: Understand that the approach was to turn around what was in the submission. But I'm not sure it works.
18:49:39 <DaveS> Doug: I have an EPR to a source and I want Basebal scores. What steps do I take?
18:50:35 <gpilz> q+
18:50:36 <li> i know epr to event source, and event type base ball score
18:52:11 <Bob> ack geo
18:52:12 <dug> Li - not event type baseball score - each event is associated with a topic and one topic might be "baseball score"
18:52:42 <dug> q+ Jeff
18:52:49 <DaveS> Geoff: The submission appendex 1 does sem to work, so turning it around should work.
18:53:12 <DaveS> s/sem/seem/
18:53:37 <gpilz> you don't want to
18:53:42 <Yves> :)
18:53:52 <Bob> ack jeff
18:54:37 <DaveS> Lunch Break for 1 hour.
18:54:54 <Zakim> -Vikas
18:54:58 <Zakim> -li
18:55:28 <Zakim> -Yves
19:26:05 <fmaciel> fmaciel has joined #ws-ra
19:32:27 <Zakim> + +1.408.970.aadd
19:38:34 <Zakim> - +1.408.970.aadd
20:00:40 <vvarma> vvarma has joined #ws-ra
20:02:25 <Zakim> +[Microsoft.a]
20:03:07 <Zakim> +li
20:03:10 <Zakim> +Yves
20:03:55 <li> echo
20:04:28 <li> howling
20:04:57 <li> feedback loop somewhere
20:05:59 <Zakim> -[Microsoft]
20:06:23 <li> output (speaker) feeds back to input (mic)
20:07:10 <Tom_Rutt> scribenik: Tom_Rutt
20:07:19 <gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0046.html
20:07:24 <DaveS> DaveS has joined #ws-ra
20:07:50 <Tom_Rutt> Gil presented his latest proposal
20:08:02 <Zakim> +Vikas
20:09:57 <Sreed> Sreed has joined #ws-ra
20:10:16 <Tom_Rutt> "Notification Type" is now "Event Type", "NotificationDescriptions" is 
20:10:18 <Tom_Rutt> now "EventDescriptions", etc. I believe that this rewording and the 
20:10:19 <Tom_Rutt> terminology changes that motivated it help to clarify the following points:
20:10:34 <Geoff> Geoff has joined #ws-ra
20:12:39 <Tom_Rutt> Gil wrote an xslt to map from event description xml to the wsdl for sending to event sinc
20:13:34 <Tom_Rutt> compare and contrast two proposals:
20:13:52 <Wu> q+
20:15:02 <Tom_Rutt> wu proposal links two wsdls in a new way which is a new invention
20:15:07 <Bob> ack gp
20:15:32 <Tom_Rutt> linking a port with policy in one wsdl to a binding in another is a new concept, which would require new tooling
20:16:08 <Tom_Rutt> My proposal is complete, thus it may seem complicated, however it is fully specified.  wu and li proposal is not completely specified
20:18:25 <Tom_Rutt> Notification wsdl is not workable.  It does not disallow rpc/lit.  If you do not constrain nofification wsdl, you have to state what happens if someone does these extra things
20:19:41 <Tom_Rutt> Their proposal uses policy, but does not say what to do if there are alternatives in the policy expressions.
20:19:42 <DaveS> q+
20:20:00 <Tom_Rutt> Both proposals require new tooling
20:20:40 <Tom_Rutt> wu: I would like a complete review of gil's proposal
20:22:14 <Tom_Rutt> Gil: you use ws-mex to retrieve the event description xml schema for a set of event types
20:23:41 <Bob> q?
20:27:03 <Tom_Rutt> this data from the ws-mex retrieval allows the tooling to construct filter expressions for the event type
20:27:39 <li> q+
20:28:35 <Bob> ack wu
20:29:44 <Tom_Rutt> tooling can take the event description can then can generate appropriate event sync wsdl (with an option of either wrapped or unwrapped perhaps)
20:32:06 <Wu> EventDesrcitption is a simplified version of wsdl and anything expressible by EventDescription should be expressible by wsdl.
20:33:13 <Tom_Rutt> asir: so you use mex on the event source endpoint to get the event descriptions for that endpoint
20:33:18 <Tom_Rutt> gil: yes
20:33:29 <Bob> ack dave
20:36:06 <Tom_Rutt> Dave: so for wrapped event format, the event description gives me everything to generate my Java stuff from the schemas
20:36:20 <Tom_Rutt> Gil: yes for wrapped
20:38:27 <Tom_Rutt> Dave : the harder part is how to define the unwrapped case
20:38:30 <Tom_Rutt> q+
20:38:49 <Wu> q+
20:39:17 <Bob> ack li
20:40:32 <Tom_Rutt> q-
20:41:38 <Tom_Rutt> gil: for unwrapped notifications my proposal only allows generation of doc/lit sync wsdl
20:42:18 <Wu> EventDescription only for doc literal and no support for rpc literal
20:42:20 <Tom_Rutt> gil: the only things the generation process needs to know is whether the user wants soap 1.1 or soap 1.2
20:45:44 <Tom_Rutt> li: how can a separate subsrciber and the sync wsdl generater be implemented separately
20:46:16 <Tom_Rutt> Gil: the only thing which is under control of the generator is soap version in use
20:49:10 <Tom_Rutt> Gil: wsdl is for defining what goes on wire, not an abstract event type.  the event type is a single ged and the filter runs over the data in that ged
20:49:12 <asir> q+ to ask a question of clarification
20:51:48 <Tom_Rutt> Li: I have problems abandoning use of wsdl just because it has some problems. We are trying to get bp compliance, and I do not understand why this requires a new dialect rather than restricting wsdl  
20:52:12 <Wu> We should not abandon wsdl, instead we should follow BP to restrain the flexibility
20:53:05 <dug> q+
20:53:42 <Tom_Rutt> Gil: I have no problem for using wsdl to describe services, however it is not proper to define the abstract content of event type
20:54:15 <Bob> ack wu
20:54:31 <Ram> Ram has joined #ws-ra
20:54:36 <Ram> q+
20:59:12 <Bob> ack asir
20:59:12 <Zakim> asir, you wanted to ask a question of clarification
20:59:34 <Wu> q+
21:00:46 <DaveS> q+
21:01:35 <Tom_Rutt> the wu li proposal starts from the abstract wsdl on the wire spec, and then works backwards to get the content to define filters.  My approach starts from the data, and then generates the wsdl from that
21:03:48 <Zakim> -Vikas
21:05:46 <li> q+
21:06:34 <Wu> Can support RPC literal binding in addition to the support of Doc literal biniding in NotificationWSDL approach should be a plus.
21:06:42 <Tom_Rutt> asir: the biggest difference is the way the two approaches link the event sync wsdl bindings to the event types which the source can emit
21:07:14 <Tom_Rutt> wu: support for rpc/lit is a big plus for our approach
21:07:24 <Tom_Rutt> ?
21:07:37 <Tom_Rutt> q+
21:08:27 <Bob> ack dug
21:08:58 <Tom_Rutt> dug: i like the format stuff in this spec.  the fact that format is done after filtering, and has what is serialized on the wire.  gil's proposal defines what is filtered before what is formatted on the wire
21:09:20 <Tom_Rutt> dug: wsdl ties you into soap, and this is a key point
21:10:17 <Tom_Rutt> dug: the format uri is the link for what goes on the wire, i think one could define a format uri allowing an event description to be mapped onto an rpc/lit wsdl binding
21:12:23 <Zakim> + +1.703.860.aaee
21:12:34 <gpilz> For any Subscription Format it is necessary to understand how a given Event Type will appear on the wire as a Notification for subscriptions created with that format. The following sections define how Event Types bind to Notifications for the two types of format defined within this specification; Raw and Wrapped. Specifications or profiles that define additional Subscription Formats SHOULD define how Event Types bind to the Notifications for those formats. 
21:12:50 <Bob> zakim, aaee is Vikas
21:12:50 <Zakim> +Vikas; got it
21:14:38 <Bob> q?
21:14:42 <Bob> ack ram
21:17:23 <Bob> ack wu
21:18:38 <asir> q+
21:18:48 <Ram> q+
21:21:58 <Tom_Rutt> Wu: our proposal can be modified to allow use of mex query on a source endpoint to determine which event sync wsdl bindings it can invoke onto
21:23:35 <Wu> Wu: we can accomodate an approach in NotificationWSDL to allow use of mex query on the event source port to retrieve notificatin WSDL, as an alternative to policy links.
21:26:41 <Bob> ack dave
21:27:21 <Tom_Rutt> Dave S: need to look at problems one at a time.  we have two different ways to describe data values which can be subscribed to
21:29:12 <dug> q+
21:32:29 <Wu> q+
21:32:33 <Bob> ack li
21:33:43 <Tom_Rutt> Li: gil's mapping requires paramters, like whether wrapped, unwrapped, or soap version, are requried to be tied down in the generation process
21:34:15 <Tom_Rutt> s/are requried//
21:36:09 <Zakim> -Vikas
21:36:22 <Bob> ack asir
21:40:45 <Bob> ack tom
21:40:54 <Tom_Rutt> Tom: the avaya proposal directly supports the use of either rpc/lit or doc/lit wsdl descriptions (because they are using wsdl message definitions for their abstract event definitions).  Gil’s proposal does not currently support use of rpc/lit wsdl, even though it is bp compliant.
21:41:06 <Tom_Rutt> Tom: I see that there might be difficulty in mapping an arbitrary ged used an event description to rpc/lit wsdl description (e.g., how to map attributes in the global element to parts in the wsdl rpc/lit request message definition).   I believe we need to tie down how important support for rpc/lit wsdl is for ws-eventing.  One use case might be relay of a corba notification (which only have...
21:41:07 <Tom_Rutt> ...a standardized mapped to rpc/lit)
21:42:32 <gpilz> q+
21:46:49 <Tom_Rutt> gil: my point of view is someone is starting from scratch.  for them rpc/lit is not important, and doc/lit is the simplest way to specify event information
21:46:58 <Bob> ack gp
21:47:26 <Tom_Rutt> gil: insisting on an event sync requiring rpc/lit does not seem to me to be required
21:47:58 <Tom_Rutt> gil: rpc/lit causes problems in the use of wrapped notification
21:49:50 <Bob> ack ram
21:50:03 <Tom_Rutt> tom: there is not way to do a schema for the child of soap body for rpc/lit, however bp describes the content in english.  How important is there to be a schema for the contents of an rpc/lit body?
21:51:59 <Tom_Rutt> ram: why cannot we define a new notion of eventing metadata
21:52:06 <jeffm> +q
21:52:58 <Bob> ack jeff
21:54:19 <li> did we break the record?
21:55:02 <dug> we're working on it
21:56:01 <Tom_Rutt> ram: we could do a white paper to discuss various approaches, rather than tying the spec down to a single approach
21:56:27 <Bob> ack dug
21:58:21 <Tom_Rutt> dug: I am not sure that tom is correct, I think you can map doc/lit get to a rpc/lit wsdl usign a special format URI.
21:58:51 <Tom_Rutt> tom: I see some difficulties in the mapping, lets take this point off line
22:08:19 <li> Retrieve the notification WSDL by following the policy assertions with binding parameter
22:26:02 <gpilz> q?
22:30:01 <li> music?
22:30:52 <Ashok> Ashok has joined #ws-ra
22:32:15 <Bob> ack wu
22:32:17 <DaveS> q+
22:32:57 <Tom_Rutt> wu: if some new binding is coming up, who is responsible to manage generation code with gils approach
22:33:17 <Tom_Rutt> wu: if new binding comes up, you have to modify the generation process
22:33:26 <gpilz> For any Subscription Format it is necessary to understand how a given Event Type will appear on the wire as a Notification for subscriptions created with that format. The following sections define how Event Types bind to Notifications for the two types of format defined within this specification; Raw and Wrapped. Specifications or profiles that define additional Subscription Formats SHOULD define how Event Types bind to the Notifications for those formats. 
22:37:56 <Tom_Rutt> Gil: You get an epr.  You do a ws-mex query using event descriptions dialect to get all of the event descriptions for event which can be emitted by that endpoint 
22:38:23 <Tom_Rutt> s/event which/event types which/
22:38:48 <Bob> rrsagent, this meeting spans midnight
22:39:06 <Tom_Rutt> that event description element has the schema, and an event type defintion for each event type
22:39:17 <Tom_Rutt> s/defintion/definition
22:39:36 <Tom_Rutt> It includes the name of event type, ged that defines it, and the action URI
22:39:55 <Bob> rrsagent, pointer?
22:39:55 <RRSAgent> See http://www.w3.org/2009/08/04-ws-ra-irc#T22-39-55
22:41:49 <Tom_Rutt> every event type in the event type description becomes a separate message
22:42:17 <Tom_Rutt> the message has a single part, named event, the element of the part is the ged referenced in the event description
22:42:46 <Tom_Rutt> in the event description/in the event type/
22:43:01 <Tom_Rutt> operation is name of event with suffix "OP"
22:43:19 <Tom_Rutt> message is name of event with "MSD" suffix
22:43:25 <Tom_Rutt> s/MSD/MSG/
22:44:32 <Tom_Rutt> there is a single parameter (soap version) with two values soap11 and soap12)
22:45:39 <Tom_Rutt> you do not need the service because that comes from the notifyTo
22:46:57 <Tom_Rutt> gil: if I understand I am filtering, but do not want to filter all the events coming from the source, I only have to generate wsdl for the event types I can filter
22:51:13 <Tom_Rutt> example 1.6 in wu proposal shows a port which supports both wrapped and unwrapped
22:51:40 <Tom_Rutt> s/exampe 2.6/wu: example 2.6/
22:52:34 <Tom_Rutt> gil: if I have a filter that I know will only generate a few of the many possible event types, I only need to generate the notification wsdl for the subset of event types I will actually receive
22:53:09 <li> but you have to process ND
22:53:36 <asir> q+
22:55:00 <Wu> Event source post the notfication wsdl and it is up to event subscriber to implement an event sink that matches his subscription.
22:55:16 <dug> q+
22:56:49 <Bob> ack dave
22:59:14 <Tom_Rutt> Dave: four points:
22:59:16 <Tom_Rutt> 1) there is a need to Advertise the event content.  I feel that gil’s event type could satisfy everyone.
22:59:18 <Tom_Rutt> 2) given the event type description, we can describe a mex dialect to allow query of this information.
22:59:19 <Tom_Rutt> 3) we know what wrapped notifications would look like, since the contents of the wrapper are fully described by the event description.   However the wu approach does not use the wrapped notification wsdl.
22:59:34 <Wu> If the subscriber knows what event he will get, he only needs to implement a sink wsdl that matches its subscription.
23:00:57 <Tom_Rutt> Dave: I propose we Strike 6.3.1 and appendix f from gill’s proposal as a starting point for agreement  Wu proposal tries to do too many things at once.
23:01:52 <Tom_Rutt> Dave: we can agree on a binding for doc/lit wsdl, leave other bindings for later specification
23:02:00 <Bob> q?
23:02:10 <asir> q-
23:04:20 <Tom_Rutt> wu: starting from wsdl definition allows policy to be attached in the abstract definition.  this is not possible with gil's event description 
23:04:58 <Bob> ack dug
23:06:53 <Tom_Rutt> Dug: I have an amendment to gil’s proposal which might satisfy wu’s concern
23:07:40 <dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0014.html
23:08:39 <Geoff> q+
23:08:43 <Tom_Rutt> I'd like to propose that we solve this by doing both.  So, my proposal is 
23:08:45 <Tom_Rutt> this:
23:08:46 <Tom_Rutt> 1 - an event source SHOULD expose EventDescriptions retrievable thru:
23:08:48 <Tom_Rutt>     mex.getMetadata(dialect=".../EventDescriptions"); 
23:08:50 <Tom_Rutt> 2 - an event source SHOULD expose the expected event sink WSDL for a 
23:08:51 <Tom_Rutt> particular FormatURI retrievable thru:
23:08:53 <Tom_Rutt>     mex.getMetadata(dialect=".../NotificationWSDL", id=FormatURI);
23:09:12 <Bob> ack geoff
23:10:28 <Wu> q+
23:12:48 <Tom_Rutt> Dave: wu proposal allows attachment of policy to the abstract wsdl port type definition which will be automatically carried over to the notification wsdl
23:13:27 <Tom_Rutt> gil: but the current proposal from wu does not say this
23:14:29 <Tom_Rutt> gil: within wu's set of wsdls it is not possible to write an xpath for filtering all the possible event types defined that way
23:14:49 <Tom_Rutt> gil: one example is multi-part wsdl
23:17:15 <Bob> q?
23:18:28 <DaveS> q+
23:20:32 <li> q+
23:23:45 <DaveS> q-
23:24:33 <Bob> ack wu
23:25:34 <Tom_Rutt> wu: with dug approach, 2) allows the event source to attache policy to the notification wsdl.
23:25:43 <Tom_Rutt> s/attache/attach/
23:26:09 <DaveS> q+
23:28:11 <Tom_Rutt> gill: attaching an outbound policy at a port type, referencing an abstract wsdl port type, you have a specific contract at the abstract level.
23:28:34 <Tom_Rutt> gil: many ws specs do not attach policy at the port type level, because it is supposed to be abstract
23:31:35 <Bob> ack li
23:31:40 <Bob> ack dave
23:33:29 <Tom_Rutt> Dave: the dug proposal has an abstract event description which allows a filter spec, however I think 1) should be MUST expose rather than SHOULD expose
23:33:46 <Wu> q+
23:35:32 <li> q+
23:36:41 <Tom_Rutt> Dave: I see 1) in dug proposal as metadata about event to use for filtering
23:37:32 <Tom_Rutt> wu: the event description is private data type
23:37:47 <Tom_Rutt> gil: is mex metadata a private data type?
23:37:58 <li> q-
23:38:09 <Tom_Rutt> dave s: I do not agree the event description is private, you need to know it to write a filter
23:39:32 <li> q+
23:40:13 <Bob> ack li
23:43:50 <gpilz> q+
23:50:01 <Ashok> Bob:  contrasts the 2 proposals
23:50:44 <gpilz> gpilz has joined #ws-ra
23:51:03 <Ashok> ... outlines area of disagreement
23:51:35 <Ashok> Asir:  Non-metadata usecases must be supported
23:52:18 <Ashok> ... shd be able to get metadata using other mechanisms such as HTTP GET
23:54:05 <gpilz> q+
23:57:58 <Yves> it is not _mandatory_ to have a miem type, but history show that it is more than useful in the long term
23:58:16 <Ashok> Asir:  We need a new mime type 
23:59:36 <Ashok> Bob:  Let us take this up as a separate question
00:01:55 <dug> O-D+D
00:06:48 <Tom_Rutt> bob- can we use oracle propo0sal - take away 6.3.1 and appendix f as the starting point
00:07:28 <Tom_Rutt> s/propo0sal/proposal/
00:10:07 <Tom_Rutt> dave: can we start with event types?
00:10:21 <Tom_Rutt> wu: start with notification wsdl
00:11:34 <Tom_Rutt> support non metadata use cases
00:11:39 <Tom_Rutt> other retrieval mechanism
00:11:45 <Tom_Rutt> mime type issue for event descriptions
00:12:10 <Tom_Rutt> event description and notification are both supported, with either one as the start
00:12:53 <Tom_Rutt> s/notification are both/notification wsdl are both/
00:13:21 <Tom_Rutt> how to do unwrapped tbd
00:14:13 <Tom_Rutt> another issue is use of policy in notification wsdl
00:14:26 <li> q+
00:15:22 <gpilz> q-
00:16:17 <dug> Oracle's proposal - 6.3.1 - F ; non-metadata usecases
00:17:36 <Tom_Rutt> another question is where to pubish the new proposal
00:19:18 <Tom_Rutt> asir: it is a combination of ideas (start with either wsdl or event description) but uses gil's proposal format as a scafolding for the final documentation
00:19:21 <asir> This is a combo proposal
00:19:24 <dug> what time is it there?
00:19:48 <li> new solution should be in appendix A
00:23:56 <Bob> rrsagent, generate minutes
00:23:56 <RRSAgent> I have made the request to generate http://www.w3.org/2009/08/04-ws-ra-minutes.html Bob
00:23:57 <Zakim> -Yves
00:24:04 <Zakim> -li
00:24:11 <Bob> recessed until tomorrow
00:24:15 <Zakim> -[Microsoft.a]
00:24:15 <Bob> rrsagent, generate minutes
00:24:15 <RRSAgent> I have made the request to generate http://www.w3.org/2009/08/04-ws-ra-minutes.html Bob
00:24:16 <Zakim> WS_WSRA(F2F)11:30AM has ended
00:24:18 <Zakim> Attendees were [Microsoft], +1.617.324.aaaa, Yves, +1.571.262.aabb, Vikas, +1.908.696.aacc, li, +1.408.970.aadd, +1.703.860.aaee
00:24:59 <Bob> rrsagent, make logs public
00:25:02 <gpilz> gpilz has left #ws-ra
00:25:04 <Bob> rrsagent, generate minutes
00:25:04 <RRSAgent> I have made the request to generate http://www.w3.org/2009/08/04-ws-ra-minutes.html Bob