04 Aug 2009


See also: IRC log


[Microsoft], +1.617.324.aaaa, Yves, +1.571.262.aabb, Vikas, +1.908.696.aacc, li, +1.408.970.aadd, +1.703.860.aaee
Bob Freund



scribe daves

<scribe> scribe: daves

There are some issues around 6401 that might be worth addressing earlier than planed

Change order to put 7127 before 6401

<Bob> scribenick: DaveS

Resolved: Agenda approved as revided

resolved: Agenda approved as provided

Action review

All for this meeting are done - Well done.

On the horizon: Yves has two for mid August.

Yves says these are coming along OK.

Asir: To address 6403.

This may be delayed due to Paul's holiday.

Paul back 13 or 14 of August, so this may cause a major delay.

Asir: Can we discuss it here?

WS-Frag to be discussed shortly.

Open RT actions pending on Frag discussion.

Snapshot Review

<scribe> New snapshots are up.

<dug> I think "frog" is reserved for eventing/mode discussions

Bob: are the snapshots ok?

Ram: request 1 week.

resolved: Snapshot review in two weeks.

Frag Spec

Asir: Todos are at the bottom of the spec.

Doug: Suggests a review for general consensis.

Plan for Wednesday.


There may be a need to revise the charter. Bob provided the following revised schedule.

2009-08-04 Bellevue F2F

2009-09-11 Next WGD publication, Frag FPWD, distribution to other

organizations for comment prior to Last Call

2009-09-30 Hursley F2F

2009-10-12 Last Call Announcement (minimum three week review), begin

test preparation

2009-11-02 Tech Plenary Santa Clara (F2F) Last call review complete

six week issue resolution?

2009-12-18 Call for implementations, Publication of Candidate

Recommendation, identification of features "at risk"

ten week test development? (christmas and New Year's weeks discounted

2010-03-19 Publication of Proposed Recommendation, interoperable

implementation criteria met or exceeded (minimum of four weeks)

2010-04-30 Recommendation Published

Bob walked through this schedule highlighting communication points outside the group.

Some minor issues can be postponed until during the last call, e.g. Infoset development.

<dug> can you hear Geoff?

Goeff: When must all issues be closed?

At CR.

<li> can't hear geoff

Ram: What criteria for Last call?

Bob: Minor things that don't impact implementations won't stop last call.

<Yves> yes we can have open issue, and re-qualify them as LC ones

<Yves> non editorial, but not major ones (ie: not ones that would change the overall function of the specs)

This group considers it unfair to do a last call with major issues outsanding.

Bob: Goal - all major issues to be resolved by the end of Hursley F2F.
... NB: Last call takes at least 3 weeks.

NB: Last call is a public review.

<Yves> all documents are for wide review, LC specifically as a call for outside review

<Bob> ank dav

Geoff: We have about 40 plus issues - are these goals realistic?

Bob: Our rate is variable. 6 days aof F2F plus calls.
... Some of the newer one should be faster.

Bob provided a pep talk to work together. For example, after a long discussion we should act rather than delay.

Bob: Some specs could be moved forward separately.

Yves: Work can proceed during a last call.

<Yves> the at-risk features, etc...

Bob: In any case we can start testing development.
... At risk means that they will be removed if interoperable implementations don't transpire.

Jeff: How many specs? And is it just pairwise?

Bob: The goal is full implementations.

<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

Bob: An iplementation MUST implement all required features to qualify for testing.

Asir: Are these specific plan above and beyond the W3C process?

Bob: Yes. We will do what is needed plus sensible extra due dilegence.

Ram: Are all the specs to move in lock step?

Bob: as we said earlier, they may move at different speeds.
... It is a little unfair to use Xmass and New year as review time.

Ram: There is still some concern about unknowns.

E.g. New issues and preparation of interop scenarios.

Asir: We could add an issue acceptance criteria.

Bob: At present we only admit by total concent.

Asir: We could set a deadline for further issues.

Bob hopes people are not sitting on issue at any time.

<Yves> resolving might be "with no action"

Asir: Can we open all issues this week?

Bob: Open all issues you can think of this week.

Asir: When is the next heart beat.

Bob: The last one was June 25. There fore the next one is September.

Asir: For last call there is four weeks.

Bob: the only rule is LC and CR are three weeks apart, we are offering 4.

Asir: More time requested to think about the schedule.

Bob: To update the web site. This schedule is a target not cast in concrete.

New Issues

Issue 7236:

Suggested edits/cleanup of wrapped/unwrapped defintions. http://www.w3.org/Bugs/Public/show_bug.cgi?id=7136


Resolution: 7136 closed as proposed in the bugzilla.

Bob: Proposed that the rest of these be opened.

Resolution: All new issues opened.

Issue 6720

Transfer: Metadata returned by WS-Transfer GET unclear http://www.w3.org/Bugs/Public/show_bug.cgi?id=6720

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0066.html

Doug: There was some unecessary repetition as indicated in the email.

<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).

<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).

Ashok: The mex dialect is there specifically. The information is repeated because people have asked for it.

doug: Will live with the repetition.

Asir: ... the number of dialects should be at the discression of the service.

Therefore MUST is too strong.

Doug: The EPR points to a single metadata resource root element.

Asir: Is there some confusion here?

Doug was talking about the mex dialect.


< schema | Definition |

Doug: For a given Metedata-EPR an TX get should always return the same thing.

In the context of the spec something is confusing.

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). "

Resolutiion: 6719 and 6720 approved with the deletion of the above sentence from 6720.

15 minute break.


Issue 7127

Eventing: Can event information contained in notification

be bound to soap:headers http://www.w3.org/Bugs/Public/show_bug.cgi?id=7127

Tom: Clarify the the application level content is called "event infomration".

Tom's proposal is that this event information MUST all be in the body and not the header.

Wu: There needs to be clarity as to what goes in the body and the header. Likewise multi part is not of interest.

Gil: This presuposes a clear separation between application and infrastructure information.
... 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.

Tom: This may be more complicated than I thought.

Gil: The default is very simple, e.g it is in the body as the child. thene there is extensibility.

Doug: Basically as a subscriber you get to chose the format of the delivered messages. Thi spec should not restrict it.

Tom: Delay resoultion until we can close with no action.


Wu: Reviewed his proposal

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0012.html

<gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/att-0012/NotificationWSDL_for_6401-6661_v4_submit.htm

<Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/att-0012/NotificationWSDL_for_6401-6661_v4_submit.htm

Geoff: Is it necessary to have two wsdl (event source and notifications).

Wu: Yes.

Tom: The Event source wsdl never generates code. only the notification-wsdl is used to generate code.

The Notification WSDL service element must be created dynamically after the subscribe.

Dug: Why do we need abstract and concrete wsdl.

Wu: The abstract is only needed for raw type.

Dug: It looks like there is a lot of implicit knowlege in this approach.

Doug: How do I know which policy assertion to understand?

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.

<dug> Li - I don't know the events - that's part of the problem

<dug> I want to ask the source for the list of events

<gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0046.html

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.

Geoff; There may be another step in which the subscriber sets up to recieve them.

<dug> Li -please write this down in a note

<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

Wu: What is the easiest way to move the existing outbound wsdl to a new format?

Wu" That is all that is happening here.

Doug: Understand that the approach was to turn around what was in the submission. But I'm not sure it works.
... I have an EPR to a source and I want Basebal scores. What steps do I take?

<li> i know epr to event source, and event type base ball score

<dug> Li - not event type baseball score - each event is associated with a topic and one topic might be "baseball score"

Geoff: The submission appendex 1 does seem to work, so turning it around should work.

<gpilz> you don't want to

<Yves> :)

Lunch Break for 1 hour.

<li> echo

<li> howling

<li> feedback loop somewhere

<li> output (speaker) feeds back to input (mic)

<Tom_Rutt> scribenik: Tom_Rutt

<gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0046.html

<Tom_Rutt> Gil presented his latest proposal

<Tom_Rutt> "Notification Type" is now "Event Type", "NotificationDescriptions" is

<Tom_Rutt> now "EventDescriptions", etc. I believe that this rewording and the

<Tom_Rutt> terminology changes that motivated it help to clarify the following points:

<Tom_Rutt> Gil wrote an xslt to map from event description xml to the wsdl for sending to event sinc

<Tom_Rutt> compare and contrast two proposals:

<Tom_Rutt> wu proposal links two wsdls in a new way which is a new invention

<Tom_Rutt> linking a port with policy in one wsdl to a binding in another is a new concept, which would require new tooling

<Tom_Rutt> My proposal is complete, thus it may seem complicated, however it is fully specified. wu and li proposal is not completely specified

<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

<Tom_Rutt> Their proposal uses policy, but does not say what to do if there are alternatives in the policy expressions.

<Tom_Rutt> Both proposals require new tooling

<Tom_Rutt> wu: I would like a complete review of gil's proposal

<Tom_Rutt> Gil: you use ws-mex to retrieve the event description xml schema for a set of event types

<Tom_Rutt> this data from the ws-mex retrieval allows the tooling to construct filter expressions for the event type

<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)

<Wu> EventDesrcitption is a simplified version of wsdl and anything expressible by EventDescription should be expressible by wsdl.

<Tom_Rutt> asir: so you use mex on the event source endpoint to get the event descriptions for that endpoint

<Tom_Rutt> gil: yes

<Tom_Rutt> Dave: so for wrapped event format, the event description gives me everything to generate my Java stuff from the schemas

<Tom_Rutt> Gil: yes for wrapped

<Tom_Rutt> Dave : the harder part is how to define the unwrapped case

<Tom_Rutt> gil: for unwrapped notifications my proposal only allows generation of doc/lit sync wsdl

<Wu> EventDescription only for doc literal and no support for rpc literal

<Tom_Rutt> gil: the only things the generation process needs to know is whether the user wants soap 1.1 or soap 1.2

<Tom_Rutt> li: how can a separate subsrciber and the sync wsdl generater be implemented separately

<Tom_Rutt> Gil: the only thing which is under control of the generator is soap version in use

<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

<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

<Wu> We should not abandon wsdl, instead we should follow BP to restrain the flexibility

<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

<Zakim> asir, you wanted to ask a question of clarification

<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

<Wu> Can support RPC literal binding in addition to the support of Doc literal biniding in NotificationWSDL approach should be a plus.

<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

<Tom_Rutt> wu: support for rpc/lit is a big plus for our approach

<Tom_Rutt> ?

<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

<Tom_Rutt> dug: wsdl ties you into soap, and this is a key point

<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

<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.

<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

<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.

<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

<Tom_Rutt> Li: gil's mapping requires paramters, like whether wrapped, unwrapped, or soap version, to be tied down in the generation process

<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.

<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...

<Tom_Rutt> ...a standardized mapped to rpc/lit)

<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

<Tom_Rutt> gil: insisting on an event sync requiring rpc/lit does not seem to me to be required

<Tom_Rutt> gil: rpc/lit causes problems in the use of wrapped notification

<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?

<Tom_Rutt> ram: why cannot we define a new notion of eventing metadata

<jeffm> +q

<li> did we break the record?

<dug> we're working on it

<Tom_Rutt> ram: we could do a white paper to discuss various approaches, rather than tying the spec down to a single approach

<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.

<Tom_Rutt> tom: I see some difficulties in the mapping, lets take this point off line

<li> Retrieve the notification WSDL by following the policy assertions with binding parameter

<li> music?

<Tom_Rutt> wu: if some new binding is coming up, who is responsible to manage generation code with gils approach

<Tom_Rutt> wu: if new binding comes up, you have to modify the generation process

<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.

<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 types which can be emitted by that endpoint

<Tom_Rutt> that event description element has the schema, and an event type definition for each event type

<Tom_Rutt> It includes the name of event type, ged that defines it, and the action URI

<Tom_Rutt> every event type in the event type description becomes a separate message

<Tom_Rutt> the message has a single part, named event, the element of the part is the ged referenced in the event description

<Tom_Rutt> in the event description/in the event type/

<Tom_Rutt> operation is name of event with suffix "OP"

<Tom_Rutt> message is name of event with "MSG" suffix

<Tom_Rutt> there is a single parameter (soap version) with two values soap11 and soap12)

<Tom_Rutt> you do not need the service because that comes from the notifyTo

<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

<Tom_Rutt> example 1.6 in wu proposal shows a port which supports both wrapped and unwrapped

<Tom_Rutt> s/exampe 2.6/wu: example 2.6/

<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

<li> but you have to process ND

<Wu> Event source post the notfication wsdl and it is up to event subscriber to implement an event sink that matches his subscription.

<Tom_Rutt> Dave: four points:

<Tom_Rutt> 1) there is a need to Advertise the event content. I feel that gil’s event type could satisfy everyone.

<Tom_Rutt> 2) given the event type description, we can describe a mex dialect to allow query of this information.

<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.

<Wu> If the subscriber knows what event he will get, he only needs to implement a sink wsdl that matches its subscription.

<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.

<Tom_Rutt> Dave: we can agree on a binding for doc/lit wsdl, leave other bindings for later specification

<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

<Tom_Rutt> Dug: I have an amendment to gil’s proposal which might satisfy wu’s concern

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0014.html

<Tom_Rutt> I'd like to propose that we solve this by doing both. So, my proposal is

<Tom_Rutt> this:

<Tom_Rutt> 1 - an event source SHOULD expose EventDescriptions retrievable thru:

<Tom_Rutt> mex.getMetadata(dialect=".../EventDescriptions");

<Tom_Rutt> 2 - an event source SHOULD expose the expected event sink WSDL for a

<Tom_Rutt> particular FormatURI retrievable thru:

<Tom_Rutt> mex.getMetadata(dialect=".../NotificationWSDL", id=FormatURI);

<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

<Tom_Rutt> gil: but the current proposal from wu does not say this

<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

<Tom_Rutt> gil: one example is multi-part wsdl

<Tom_Rutt> wu: with dug approach, 2) allows the event source to attach policy to the notification wsdl.

<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.

<Tom_Rutt> gil: many ws specs do not attach policy at the port type level, because it is supposed to be abstract

<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

<Tom_Rutt> Dave: I see 1) in dug proposal as metadata about event to use for filtering

<Tom_Rutt> wu: the event description is private data type

<Tom_Rutt> gil: is mex metadata a private data type?

<Tom_Rutt> dave s: I do not agree the event description is private, you need to know it to write a filter

<Ashok> Bob: contrasts the 2 proposals

<Ashok> ... outlines area of disagreement

<Ashok> Asir: Non-metadata usecases must be supported

<Ashok> ... shd be able to get metadata using other mechanisms such as HTTP GET

<Yves> it is not _mandatory_ to have a miem type, but history show that it is more than useful in the long term

<Ashok> Asir: We need a new mime type

<Ashok> Bob: Let us take this up as a separate question

<dug> O-D+D

<Tom_Rutt> bob- can we use oracle proposal - take away 6.3.1 and appendix f as the starting point

<Tom_Rutt> dave: can we start with event types?

<Tom_Rutt> wu: start with notification wsdl

<Tom_Rutt> support non metadata use cases

<Tom_Rutt> other retrieval mechanism

<Tom_Rutt> mime type issue for event descriptions

<Tom_Rutt> event description and notification wsdl are both supported, with either one as the start

<Tom_Rutt> how to do unwrapped tbd

<Tom_Rutt> another issue is use of policy in notification wsdl

<dug> Oracle's proposal - 6.3.1 - F ; non-metadata usecases

<Tom_Rutt> another question is where to pubish the new proposal

<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

<asir> This is a combo proposal

<dug> what time is it there?

<li> new solution should be in appendix A

<Bob> recessed until tomorrow

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/08/05 00:25:10 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Asir/Ram/
Succeeded: s/CL/LC/
Succeeded: s/Dooug/doug/
Succeeded: s/Tat/Wu" That/
Succeeded: s/sem/seem/
Succeeded: s/are requried//
Succeeded: s/event which/event types which/
Succeeded: s/defintion/definition/
Succeeded: s/MSD/MSG/
FAILED: s/exampe 2.6/wu: example 2.6/
Succeeded: s/attache/attach/
Succeeded: s/propo0sal/proposal/
Succeeded: s/notification are both/notification wsdl are both/
Found Scribe: daves
Inferring ScribeNick: DaveS
Found ScribeNick: DaveS
Default Present: [Microsoft], +1.617.324.aaaa, Yves, +1.571.262.aabb, Vikas, +1.908.696.aacc, li, +1.408.970.aadd, +1.703.860.aaee
Present: [Microsoft] +1.617.324.aaaa Yves +1.571.262.aabb Vikas +1.908.696.aacc li +1.408.970.aadd +1.703.860.aaee

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0011.html
Got date from IRC log name: 04 Aug 2009
Guessing minutes URL: http://www.w3.org/2009/08/04-ws-ra-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]