- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Tue, 07 Jul 2009 14:54:55 -0700
- To: "Chou, Wu (Wu)" <wuchou@avaya.com>
- CC: Bob Freund <bob.freund@hitachisoftware.com>, public-ws-resource-access@w3.org
- Message-ID: <4A53C42F.9010109@oracle.com>
Wu,
You are making this much more complicated than it has to be. Remember
the default behavior is to *ignore extensions that you don't
understand*. If an Event Source does not understand/recognize a
particular extension element, it doesn't matter what the semantics of
the extension are, the Event Source simply ignores that element. If the
Event Source *does* understand an extension element, then it stands to
reason that is must know the semantics specified by that extension. This
is about as "light weight and computationally efficient" as it gets.
With regards to using Policy inside the Delivery element, are you
talking about requiring the use of WS-Policy expressions? In other words:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://www.w3.org/2009/02/ws-evt"
xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/2/wsman.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy "
xmlns:foo="http://www.extensions.r.us/foo">
<s:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe</wsa:Action>
. . .
</s:Header>
<s:Body>
<wse:Subscribe wsman:NotifyAcks="1">
<wse:Delivery>
<wse:NotifyTo>
<wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
</wse:NotifyTo>
* <wsp:Policy>
<foo:UseSomeExtension/>
</wsp:Policy>*
</wse:Delivery>
</wse:Subscribe>
</s:Body>
</s:Envelope>
If so, I fail to see how this would be any better than simply using the
bare extension element like so:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://www.w3.org/2009/02/ws-evt"
xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/2/wsman.xsd"
xmlns:foo="http://www.extensions.r.us/foo">
<s:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe</wsa:Action>
. . .
</s:Header>
<s:Body>
<wse:Subscribe wsman:NotifyAcks="1">
<wse:Delivery>
<wse:NotifyTo>
<wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
</wse:NotifyTo>
* <foo:UseSomeExtension/>
<*/wse:Delivery>
</wse:Subscribe>
</s:Body>
</s:Envelope>
Is it your intention that the Event Source should perform policy
intersection and matching operations on any extensions to the Subscribe
request?
- gp
On 7/6/2009 5:09 PM, Chou, Wu (Wu) wrote:
>
> Bob,
>
> Glad to see some good progress being made. We would like to add a
> further work issue to your list:
>
> 4) Using Policy inside the delivery element to describe delivery
> extensions.
>
> Rationale: If any xml under xs:any is allowed as extension elements to
> change the default Push delivery, how to uniquely determine the
> semantics and behavior represented by these extension elements in a
> light weight and computational efficient way will become an acute issue.
>
> In addition, event source needs a way to advertise the allowed
> delivery extensions/combinations. And if an event subscription is
> accepted, the event subscriber should know exactly what delivery
> mechanism is used by the event source to send event notification.
>
> After some study and comparison, we would like to propose using Policy
> inside the delivery element to address this issue. We will submit a
> detailed proposal for the WG to discuss. This proposal will cut across
> the current TBD topics 1-3 and as a result may need to be handled
> before the others.
>
> Many thanks,
>
> - Wu Chou.
>
> Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA |
> 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
> 908-696-5198 / 908-696-5401 | wuchou@avaya.com
> <blocked::mailto:wuchou@avaya.com>
> From: Bob Freund <bob.freund@hitachisoftware.com
> <mailto:bob.freund@hitachisoftware.com?Subject=Re%3A%20Issue-6692%20-%20Interim%20agreement%20draft&In-Reply-To=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E&References=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E>>
>
> Date: Mon, 6 Jul 2009 13:43:03 -0400
> Message-Id: <FDF27172-5127-4D9C-B7BC-B2CAC4D83697@hitachisoftware.com>
> To: public-ws-resource-access@w3.org
> <mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Issue-6692%20-%20Interim%20agreement%20draft&In-Reply-To=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E&References=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E>
>
>
> 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
>
> * application/msword attachment: wseventing-6692-9-1.doc
> <http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0002/wseventing-6692-9-1.doc>
>
>
> * application/pkcs7-signature attachment: smime.p7s
> <http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0002/smime.p7s>
>
>
Received on Tuesday, 7 July 2009 21:55:47 UTC