Re: Issue-6692 - Interim agreement draft

Wu,

If you cannot provide concrete, detailed examples of the 
interoperability issues that will result if we "allow" XML extensions 
may I respectfully request that, in the future, you refrain from 
claiming that such issues exist.

- gp

On 7/7/2009 4:59 PM, Gilbert Pilz wrote:
> 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>
>>
>>