RE: Decisions to-date for Issue 6692

We are NOT able to figure out the diff between Geoff's and Doug's written proposals. May we request you to post a diff?

Regards,

Asir S Vedamuthu
Microsoft Corporation

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, June 30, 2009 5:50 AM
To: Yves Lafon
Cc: public-ws-resource-access@w3.org
Subject: Re: Decisions to-date for Issue 6692


Yves - thanks and sorry I keep forgetting about the size limit.
I uploaded the file here: http://www.w3.org/2002/ws/ra/9/06/wseventing-DeliveryElement.html

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.

Yves Lafon <ylafon@w3.org>

06/30/2009 08:43 AM

To

Doug Davis/Raleigh/IBM@IBMUS

cc

public-ws-resource-access@w3.org

Subject

Re: Decisions to-date for Issue 6692







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[attachment "wseventing-DeliveryElement.html.bz2" deleted by Doug Davis/Raleigh/IBM]