RE: Issue-6692 - Interim agreement draft

For good hygiene, I logged this as: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7136

 

 

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Martin Chapman
Sent: 24 July 2009 14:44
To: 'Doug Davis'; public-ws-resource-access@w3.org
Cc: 'Bob Freund'; 'Geoff Bullen'; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: Issue-6692 - Interim agreement draft

 

I hope its editorial, but if you want me to raise an issue just shout.

 

Martin.

 

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: 24 July 2009 14:27
To: public-ws-resource-access@w3.org
Cc: 'Bob Freund'; 'Geoff Bullen'; Martin Chapman; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: Issue-6692 - Interim agreement draft

 


Martin - I should clarify - while the text you're editing is marked as "changed" - its actually only tagged that way because it was
moved.  The proposal didn't change the text that was in the spec - that's why I was thinking of it as a new issue.  But if people
are ok with treating this as a minor editorial change we can merge it into this issue too - I'm ok either way. 

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. 


Doug Davis/Raleigh/IBM@IBMUS 
Sent by: public-ws-resource-access-request@w3.org 

07/24/2009 09:19 AM 


To

"Martin Chapman" <martin.chapman@oracle.com> 


cc

"'Bob Freund'" <bob.freund@hitachisoftware.com>, "'Geoff Bullen'" <Geoff.Bullen@microsoft.com>, public-ws-resource-access@w3.org,
public-ws-resource-access-request@w3.org 


Subject

RE: Issue-6692 - Interim agreement draft

 

		





Martin, 
 there seems like ok edits to me - wanna open a new issue since its not directly related to 6692? 

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. 


"Martin Chapman" <martin.chapman@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org 

07/24/2009 07:23 AM 

 


To

"'Geoff Bullen'" <Geoff.Bullen@microsoft.com>, "'Bob Freund'" <bob.freund@hitachisoftware.com>, <public-ws-resource-access@w3.org> 


cc

	

Subject

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