W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > July 2009

RE: Issue-6692 - Interim agreement draft

From: Doug Davis <dug@us.ibm.com>
Date: Fri, 24 Jul 2009 09:19:34 -0400
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
Message-ID: <OFF4FD849D.92CAF755-ON852575FD.004928AA-852575FD.004936DF@us.ibm.com>
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
> 
> 
Received on Friday, 24 July 2009 13:20:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:08 GMT