RE: Issue-6692 - Interim agreement draft

I think the definition in 2.3 of wrapped and unwrapped is still a bit imprecise and self-referencing, but I think the fix is simple.
I would suggest adding the words "defined by this specification" at the end of the second sentence, giving:

"Use of wrapped format indicates that notification messages should be contained in a wrapper element defined by this specification."

Without such a qualification this would lead to ambiguity as one person's wrapper is another person's unwrapped!

And just being pedantic I would also suggest changing:

"Use of unwrapped format indicates that notification messages are not wrapped."

To

"Use of unwrapped format indicates that notification messages are not contained in a wrapper element."

I also think the second paragraph is confusing, as formatting is always engaged, it's just a question of what sort!

So how about changing:
"When the Delivery Format feature is engaged the formatting of the going events occurs after any filtering."
To:
"Filtering occurs prior to any formatting of notification messages." 

The sum total of these suggestions would give:

2.3 Notification Formats

This specification specifies two delivery formats: wrapped and unwrapped. Use of wrapped format indicates that notification messages
should be contained in a wrapper element defined by this specification. Use of unwrapped format indicates that notification messages
are not contained in a wrapper element. 

Filtering occurs prior to any formatting of notification messages. This ensures that regardless of what type of formatting might
occur, the same Filter dialect/expression can be used to subset the event stream.

-----
Martin.


> -----Original Message-----
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On
> Behalf Of Geoff Bullen
> Sent: 23 July 2009 22:47
> To: Bob Freund; public-ws-resource-access@w3.org
> Subject: RE: Issue-6692 - Interim agreement draft
> 
> Attached is a joint proposal from IBM and Microsoft for Issue 6692 and, we hope, allows this issue to
> finally be resolved. It does cover the resolution of point 3) below.
> 
> Points 1) and 2), as agreed by the WG, should be dealt with as separate issues.
> Avaya's issue on using policy assertions instead of qnames should also be raised as a separate issue.
> 
> Thanks,
> Geoff
> 
> -----Original Message-----
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On
> Behalf Of Bob Freund
> Sent: Monday, July 06, 2009 10:43 AM
> To: public-ws-resource-access@w3.org
> Subject: Issue-6692 - Interim agreement draft
> 
> The following is a draft that incorporates the current state of agreement on Issue-6692.
> Note that within the document there are several areas marked "TBD"
> which represent further aspects that are yet to be thrashed out.
> This version has been reviewed by both Microsoft and IBM and both are agreeable as to it use as the
> reference for further issue negotiation.
> The summary of further work needed is :
> 1) Fault behavior relating to delivery extensions as the original fault definition related to @mode
> 2) extension negotiation behavior if any since the original @mode fault optional detail element was
> thought to provide some negotiation mechanism albeit unreliable
> 3) Use of the word "Push" rather than simply the one default method of notification delivery.  Nothing
> particularly distinguishes "Push" from normal asynchronous delivery and its use in th text is
> infrequent
> 
> I would be interested in discussing this on the next call as well as the opinion of folks as to the
> potential division of this issue into three additional issues as represented by the points above.
> thanks
> -bob
> 
>

Received on Friday, 24 July 2009 11:24:26 UTC