- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 30 Jun 2009 08:43:46 -0400 (EDT)
- To: Doug Davis <dug@us.ibm.com>
- cc: public-ws-resource-access@w3.org
- Message-ID: <alpine.DEB.1.10.0906300842400.5911@wnl.j3.bet>
On Tue, 30 Jun 2009, Doug Davis wrote: [resent with a compressed version of the attachment] > Geoff, > I think this write-up goes beyond what we agreed to at the f2f. I seem > to recall that we agreed to remove the "mode" attribute but keep the > "Delivery" element as a wrapper for extensions related to the conveyance > of Notifications. In particular, here are some of things that I noticed > that seemed to go beyond that: > - introduction of a "delivery pattern" concept > - the notion of a "Push pattern" - since we didn't agree to a new > "delivery pattern" concept, we didn't agree to a "Push pattern" > - the EndTo element appears to have moved in your proposal - just in the > pseudo schema > - Most of the text you put under "Delivery" is redundant with the > extensibility model we already have described in section 3.2. > - Also, text like "Two extension elements are equivalent if and only if > they have the same root QName." is not something we discussed and is not > correct. Only the spec that defines the extension could make this claim > since its possible that attributes or children elements need to be > examined to determine equivalence. I'm having horrible flashback to "EPR > comparison" discussions :-) > > I've attached a new version that I think limits itself to just what we > agreed to. From a coding perspective its the same thing as what you have > - it just doesn't introduce concepts that we didn't agree to and as a > result I think its easier to digest. > > btw - something I think the group should think about are examples. Given > we have 3 extensibility points (Subscribe, Delivery, NotifyTo) we should > probably show at least one example of what kind of extension would go into > each and how it will look. Without this guidance I suspect a lot of > confusion and interop issues. > > > > thanks > -Doug > ______________________________________________________ > STSM | Standards Architect | IBM Software Group > (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com > The more I'm around some people, the more I like my dog. > > > > Geoff Bullen <Geoff.Bullen@microsoft.com> > Sent by: public-ws-resource-access-request@w3.org > 06/25/2009 06:56 PM > > To > "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> > cc > > Subject > Decisions to-date for Issue 6692 > > > > > > > Hi all, > This email is in response to my action item 70 to write up our ?decisions > to-date? as far as Issue 6692 is concerned. > We made good progress at the recent F2F, which is captured in the attached > doc. > I also received some great feedback last week, which is incorporated as > well. > > Major decisions made: > · Retaining the delivery element > · Getting rid of the mode attribute and replacing it with a series > of composable options > · The initial suggestion was to use qnames to represent those > options > > There still seems to be a few discussion points remaining. These include: > · Using qnames or potentially using policy statements inside of the > delivery element > · Should subscription response return indications about the > subscription? > · What should various faults return? > > --Geoff > [attachment "WS-Eventing-6692-8.docx" deleted by Doug Davis/Raleigh/IBM] > -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Attachments
- APPLICATION/octet-stream attachment: wseventing-DeliveryElement.html.bz2
Received on Tuesday, 30 June 2009 12:43:59 UTC