See also: IRC log
<DaveS> scribe: David Snelling
<DaveS> scribenick: daves
There are some issues around 6401 that might be worth addressing earlier than planed
Change order to put 7127 before 6401
RESOLUTION: Agenda approved as provided
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.
<scribe> New snapshots are up.
Bob: are the snapshots ok?
Ram: request 1 week.
RESOLUTION: Snapshot review in two weeks.
Ram: Todos are at the bottom of the spec.
Doug: Suggests a review for general consensus.
Bob: Plan for Thursday if time permits.
There may be a need to revise the charter if the schedule dictates. 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.
Goeff: When must all issues be closed?
At CR.
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 per the W3C process
document.
NB: Last call is a public review.
<Yves> all documents are for wide review, LC specifically as a call for outside review
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 test
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: IMO an implementation 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 a new 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 issues 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 a minimum of three weeks apart, we are offering 4.
Asir: More time requested to think about the schedule.
<scribe> ACTION: Bob To update the web site. This schedule is a target not cast in concrete. [recorded in http://www.w3.org/2009/08/04-ws-ra-minutes.html#action01]
Suggested edits/cleanup of wrapped/unwrapped defintions. http://www.w3.org/Bugs/Public/show_bug.cgi?id=7136
Opened
RESOLUTION: Issue-7136 closed as proposed in the bugzilla.
Bob: Proposed that the rest of these be opened.
RESOLUTION: All new issues opened.
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.
<getresponse>
< 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). "
RESOLUTION: 6719 and 6720 resolved as proposed with the deletion of the above sentence from 6720.
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 resolution until we can close with no action.
Wu: Reviewed his proposal
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?
... 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> :)
<Tom_Rutt> scribe: Tom Rutt
<Tom_Rutt> scribenick: Tom_Rutt
Gil presented his latest proposal
<gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0046.html
"Notification Type" is now "Event Type", "NotificationDescriptions" is
now "EventDescriptions", etc. I believe that this rewording and the
terminology changes that motivated it help to clarify the following points:
Gil wrote an xslt to map from event description xml to the wsdl for sending to event sinc
compare and contrast two proposals:
wu proposal links two wsdls in a new way which is a new invention
linking a port with policy in one wsdl to a binding in another is a new concept, which would require new tooling
My proposal is complete, thus it may seem complicated, however it is fully specified. wu and li proposal is not completely specified
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
Their proposal uses policy, but does not say what to do if there are alternatives in the policy expressions.
Both proposals require new tooling
wu: I would like a complete review of gil's proposal
Gil: you use ws-mex to retrieve the event description xml schema for a set of event types
this data from the ws-mex retrieval allows the tooling to construct filter expressions for the event type
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.
asir: so you use mex on the event source endpoint to get the event descriptions for that endpoint
gil: yes
Dave: so for wrapped event format, the event description gives me everything to generate my Java stuff from the schemas
Gil: yes for wrapped
Dave: the harder part is how to define the unwrapped case
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
gil: the only things the generation process needs to know is whether the user wants soap 1.1 or soap 1.2
li: how can a separate subsrciber and the sync wsdl generater be implemented separately
Gil: the only thing which is under
control of the generator is soap version in use
... 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
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
Gil: I have no problem for using wsdl to describe services, however it is not proper to define the abstract content of event type
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.
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
wu: support for rpc/lit is a big plus for our approach
?
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
... wsdl ties you into soap, and this is a key point
... 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.
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.
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
Li: gil's mapping requires paramters, like whether wrapped, unwrapped, or soap version, to be tied down in the generation process
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.
... 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...
... a standardized mapped to rpc/lit)
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
... insisting on an event sync requiring rpc/lit does not seem to
me to be required
... rpc/lit causes problems in the use of wrapped notification
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?
ram: why cannot we define a new
notion of eventing metadata
... we could do a white paper to discuss various approaches, rather
than tying the spec down to a single approach
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: 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
wu: if some new binding is coming up,
who is responsible to manage generation code with gils approach
... 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.
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
that event description element has the schema, and an event type definition for each event type
It includes the name of event type, ged that defines it, and the action URI
every event type in the event type description becomes a separate message
the message has a single part, named event, the element of the part is the ged referenced in the event description
in the event description/in the event type/
operation is name of event with suffix "OP"
message is name of event with "MSG" suffix
there is a single parameter (soap version) with two values soap11 and soap12)
you do not need the service because that comes from the notifyTo
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
example 1.6 in wu proposal shows a port which supports both wrapped and unwrapped
s/exampe 2.6/wu: example 2.6/
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.
Dave: four points:
1) there is a need to Advertise the event content. I feel that gil's event type could satisfy everyone.
2) given the event type description, we can describe a mex dialect to allow query of this information.
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.
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.
... we can agree on a binding for doc/lit wsdl, leave other
bindings for later specification
wu: starting from wsdl definition allows policy to be attached in the abstract definition. this is not possible with gil's event description
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
I'd like to propose that we solve this by doing both. So, my proposal is
this:
1 - an event source SHOULD expose EventDescriptions retrievable thru:
mex.getMetadata(dialect=".../EventDescriptions");
2 - an event source SHOULD expose the expected event sink WSDL for a
particular FormatURI retrievable thru:
mex.getMetadata(dialect=".../NotificationWSDL", id=FormatURI);
Dave: wu proposal allows attachment of policy to the abstract wsdl port type definition which will be automatically carried over to the notification wsdl
gil: but the current proposal from wu
does not say this
... within wu's set of wsdls it is not possible to write an xpath
for filtering all the possible event types defined that way
... one example is multi-part wsdl
wu: with dug approach, 2) allows the event source to attach policy to the notification wsdl.
gill: attaching an outbound policy at a port type, referencing an abstract wsdl port type, you have a specific contract at the abstract level.
gil: many ws specs do not attach policy at the port type level, because it is supposed to be abstract
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
... I see 1) in dug proposal as metadata about event to use for
filtering
wu: the event description is private data type
gil: is mex metadata a private data type?
Dave: 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
bob- can we use oracle proposal - take away 6.3.1 and appendix f as the starting point
dave: can we start with event types?
wu: start with notification wsdl
support non metadata use cases
other retrieval mechanism
mime type issue for event descriptions
event description and notification wsdl are both supported, with either one as the start
how to do unwrapped tbd
another issue is use of policy in notification wsdl
<dug> Oracle's proposal - 6.3.1 - F ; non-metadata usecases
another question is where to pubish the new proposal
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