- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Mon, 13 Jul 2009 16:49:05 -0700
- To: "Chou, Wu (Wu)" <wuchou@avaya.com>
- CC: Bob Freund <bob.freund@hitachisoftware.com>, public-ws-resource-access@w3.org
- Message-ID: <4A5BC7F1.1080109@oracle.com>
Wu,
I apologize if I sound short-tempered, but I am finding this
conversation very frustrating. It seems to me that the concept I'm
trying to communicate is a very simple one, rooted in the basics of XML
extensibility and the SOAP framework, and I can't understand why I am
unable to make myself clear to you.
The mechanics of an extension must be *agreed upon* by the parties that
wish to support that extension. This includes, among other things, the
QNames and XML types used to signal a request for that extension. With
regards to your list of possible ways to indicate a request for "push
with acks", the authors of "push with acks" have to *pick one* and use that.
For example, suppose we *define* that the request to enable "push with
acks" is signaled by the inclusion of the "Acks" element from the
"http://www.freeble.org/evt-ext" namespace as a child of the
/wse:Subscribe/wse:Delivery element. A Subscribe request with this
extension would look like the following:
<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:fre="http://www.freeble.org/evt-ext"*>
<s:Header>
<wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe</wsa:Action>
. . .
</s:Header>
<s:Body>
<wse:Subscribe>
<wse:Delivery>
<wse:NotifyTo>
<wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
</wse:NotifyTo>
*<fre:Acks>*
</wse:Delivery>
</wse:Subscribe>
</s:Body>
</s:Envelope>
An Event Source that supported "push with acks" (as defined by the
specification at "http://www.freeble.com/evt-ext") would *recognize *the
fre:Acks element and *understand* that this meant "I would like to
enable the 'push with acks' extension on the Subscription that I am
requesting" because this is what the extension authors *specified*!
Meanwhile the following request:
<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:dev="http://www.smalldevices.org/evt-ext"*>
<s:Header>
<wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe</wsa:Action>
. . .
</s:Header>
<s:Body>
<wse:Subscribe>
<wse:Delivery>
<wse:NotifyTo>
<wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
</wse:NotifyTo>
*<dev:PushWithAcks>*
</wse:Delivery>
</wse:Subscribe>
</s:Body>
</s:Envelope>
is, from the perspective of our Event Source, *effectively not extended
at all* because our Event Source does not recognize the
{http://www.smalldevices.org/evt-ext, PushWithAcks} QName and thus
*ignores* it.
Except for the fact that unknown extensions are ignored instead of
generating a fault, *this is absolutely no different than using @Mode*.
There is nothing magical about using a URI to signal extensions. As an
Event Source, either you understand/support an extension or you don't.
If you don't have the code to handle a particular extension, the fact
that you know how to parse @Mode doesn't help you one little bit.
- gp
On 7/13/2009 2:55 PM, Chou, Wu (Wu) wrote:
> Gil,
>
> Without a common semantic framework, e.g. WS-Policy, it is unclear how
> the event source should determine the shape and semantics of a QName.
> This may lead to a situation where different event sources designate
> the composition of the same set of QNames with different syntax and
> semantics, thereby creating interoperability issues for the subscribers.
>
> For example, for Push delivery with ack, it can be represented as:
> 1. <Push/><Ack/>
> 2. <Push><Ack/></Push>
> 3. <Ack/><Push/>
> 4. <Ack><Push/></Ack>
> 5. <myDelivery><Push><Ack/></Push></myDelivery>
> 6. ...
>
> It is not clear if they are different or equivalent if without a
> common semantic framework for their processing. This is not an issue
> in the original WS-Eventing, because there is only one way to
> semantically parse Delivery/@Mode <mailto:Delivery/@Mode> .
>
> - Wu Chou.
>
> ------------------------------------------------------------------------
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Tuesday, July 07, 2009 8:00 PM
> *To:* Chou, Wu (Wu)
> *Cc:* Bob Freund; public-ws-resource-access@w3.org
> *Subject:* Re: Issue-6692 - Interim agreement draft
>
> Wu,
>
> Please describe *in detail* the interoperability problems that will
> result if we allow "arbitrary" and "open ended" XML extensions.
>
> - gp
>
> On 7/7/2009 2:52 PM, Chou, Wu (Wu) wrote:
>> Bob,
>>
>> Our understanding is: the consensus at the F2F meeting is to replace
>> the mode uri and use Qnames to define the delivery mechanism. It is a
>> refactor or a replacement of the original simple mode uri for the
>> ease of composition. It is not to allow open ended xml to define the
>> delivery mechanism and lump into other extensions under xs:any.
>>
>> By allowing that, we are making a simple replacement of mode uri
>> arbitrarily complex.
>>
>> Moreover, when a Qname is used to specify a requirement, as it is
>> used here for defining delivery mechanism, it is using the WS-Policy
>> semantics of an assertion. We will show in our proposal that this
>> can be described using non-nested policy assertions, but do
>> not require a full implementation of WS-Policy and still using simple
>> Qname matching, since the list of Qnames used here, as replacement of
>> mode uri, is not nested.
>>
>> An arbitrary open ended xml has no uniquely defined semantic meaning,
>> and therefore, it will introduce interoperability problem unless its
>> semantic interpretation is specified as in Policy.
>>
>> We are seriously concerned the consequence to generalize from a list
>> of non-nested Qnames into an arbitrary open ended xml which has no
>> uniquely defined semantics.
>>
>> - Wu Chou.
>>
>> ------------------------------------------------------------------------
>> *From:* Chou, Wu (Wu)
>> *Sent:* Monday, July 06, 2009 8:09 PM
>> *To:* Bob Freund
>> *Cc:* 'public-ws-resource-access@w3.org'
>> *Subject:* Re: Issue-6692 - Interim agreement draft
>>
>> 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 Monday, 13 July 2009 23:50:02 UTC