Re: Issue 6429: proposal 2 from Gilbert Pilz on 2009-05-18 (public-ws-resource-access@w3.org from May 2009)

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Mon, 18 May 2009 13:45:57 -0700
To: "Li, Li (Li)" <lli5@avaya.com>
CC: Doug Davis <dug@us.ibm.com>, public-ws-resource-access@w3.org, "Chou, Wu (Wu)" <wuchou@avaya.com>
Message-ID: <4A11C905.90907@oracle.com>
Li,

It seems to me that if we were to stick to a model in which there was a 
one-to-one correspondence between a Subscription Endpoint and a 
Notification WSDL (i.e. "if I send a Subscribe to this URI I will get 
the messages defined in that WSDL and no other") then you don't need to 
worry about setting the Format parameter to wrapped. If an Event Source 
links to the "standard Notification WSDL for Wrapped" (the one that 
includes the definition of GenericSinkPortType), the Event Sink will 
simply know/expect that the messages will be wrapped as part of the 
usual processing of Notification WSDLs. In other words, support for 
"wrapped" will cease to be a special case and will simply fold into the 
normal processing of Notification WSDLs.

- gp

On 5/18/2009 8:05 AM, Li, Li (Li) wrote:
>
> Hi Doug,
>
>  
>
> For question 1, I think the reason was that wsa:Action is required 
> only if wsa is used via the wsam:Addressing policy assertion. 
> Therefore, we made it optional.
>
>  
>
> For question 2 and 3 plus <way off topic>, I agree that a better place 
> to answer them is 6401 thread which just opened up. The statement in 
> 6429 about sending WSDL in EPR or MEX is prior to the 6401 solution 
> based on Gil's idea. I therefore deleted those statements to make 6429 
> to focus on just defining a static WSDL interface, while leaving the 
> interface binding and discovery to 6401 discussions. The new version 
> with change marks is attached.
>
>  
>
> I think 6401 offers a better solution for these cases and here is how 
> it might work:
>
>  
>
> 1) Support event source WSDL has an event source port p1 that supports 
> the wse:Subscribe, and p1 has a policy assertion (proposed by 6401), 
> linking it to a binding b1 of port type "GenericSinkPortType", in the 
> notification WSDL.
>
>  
>
> 2) the subscriber has to find port p1 to subscribe somehow.  From 
> there it can find the binding b1 and the port type of the wrap interface.
>
>  
>
> 3) the event sink engages the proper module that implements the wrap 
> interface.
>
>  
>
> 4) the subscriber sends a Subscribe message with the format parameter 
> set to select the wrap delivery format.
>
>  
>
> 5) the notifications are delivered accordingly.
>
>  
>
> Please let me know if this makes sense to you.
>
>  
>
> Thanks,
>
>  
>
> Li
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Monday, May 18, 2009 8:48 AM
> *To:* Li, Li (Li)
> *Cc:* gilbert.pilz@oracle.com; public-ws-resource-access@w3.org; Chou, 
> Wu (Wu)
> *Subject:* Re: Issue 6429: proposal 2
>
>  
>
>
> Hi Li,
>   three questions/comments:
> 1 - any reason why the actionURI on each event is optional?  Since 
> wsa:Action is required (in the raw case) I would have thought that the 
> "actionURI" on each event in the wrapped case would be require too. 
>  That would provide a natural 1-1 mapping between wrapped and unwrapped.
> 2 - this probably isn't specific to issue (I think it might be related 
> to the advertising of notifications issue too), but in the Appendix 
> you talk about how the source can get this WSDL from the NotifyTo EPR 
> or by using MEX against the Sink.  How does the Source know which 
> wsdl/port to look at?  Is the "GenericSinkPortType" name a 
> static/well-defined name that the Source will know to look for?  Is 
> this WSDL static or are runtimes expected to analyze it in real-time? 
> I'm just trying to get my head around how all of this fits together 
> and which pieces are supposed to be programmatically used by the 
> runtime (or tooling) and which are meant to be for informational 
> purposes - and in practice those things will just be implied or 
> hard-coded.
> 3 - related to the previous one... what if there is no NotifyTo EPR?
>
> <way off topic>
> Sometimes I wonder if as part of the SubscribeResponse the Source 
> should include the WSDL of what the Sink is expected to support. 
>  Between all of the various options (extensions) available (format, 
> wrapped, raw, batching...) it seems like the actual WSDL that both 
> sides will use won't be known until all options of a particular 
> Subscribe are analyzed - and its only at that point that the shape 
> (wsdl) of the messages can be determined.  Sure someone could write a 
> WSDL that contains all possible variants but then it is really of any 
> use?  And are we just creating a combinatorial explosion of WSDL's if 
> we even try.  Of course, the other option is to just have "implied 
> semantics/wsdl".
> </way off topic>
>
> 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.
>
> *"Li, Li (Li)" <lli5@avaya.com>*
>
> 05/15/2009 03:59 PM
>
> 	
>
> To
>
> 	
>
> <public-ws-resource-access@w3.org>
>
> cc
>
> 	
>
> "Chou, Wu (Wu)" <wuchou@avaya.com>, Doug Davis/Raleigh/IBM@IBMUS, 
> <gilbert.pilz@oracle.com>
>
> Subject
>
> 	
>
> Re: Issue 6429: proposal 2
>
>  
>
>  
>
> 	
>
>  
>
>
>
>
> Reload the complete proposal that fixed a small typo in the WSDL.
>
> Gil proposed an alternative way to represent the current actionURI, but
> this disagreement was resolved and Gil accepted the current proposal.
> Please see the attached email for correspondent.
>
> Thanks,
>
> Li Li
>
> [attachment "wse_6429.doc" deleted by Doug Davis/Raleigh/IBM]
>
>
>
> ----- Message from "Gilbert Pilz" <gilbert.pilz@oracle.com> on Thu, 14 
> May 2009 16:40:44 -0400 -----
>
> *To:*
>
> 	
>
> "Li, Li (Li)" <lli5@avaya.com>
>
> *cc:*
>
> 	
>
> "Doug Davis" <dug@us.ibm.com>, "Chou, Wu (Wu)" <wuchou@avaya.com>
>
> *Subject:*
>
> 	
>
> Re: FW: Agenda 2009-05-12 WS-RA distributed meting
>
>  
>
>
> Yes, I can live with the current proposal.
>
> - gp
>
> On 5/12/2009 9:57 AM, Li, Li (Li) wrote:
> Doug, Gil:
>
> I am assigned the following AI:
> -Issue-6429 Eventing: Standardize Wrapped Event Sink
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6429
>  -Li (Action-42)
>
> which is pending on the decision on where to put the notification action
> verb. The current proposal puts it inside the SOAP body whereas Gil's
> proposal puts it in the SOAP header.
>
> We are ok with the current proposal which was based on Doug's
> suggestion. Gil, can you live with the current proposal? If not, can you
> and Doug work out some compromise so we can close this AI?
>
> Thanks,
> Li
>
> -----Original Message-----
> From: member-ws-resource-access-request@w3.org 
> <mailto:member-ws-resource-access-request@w3.org>
> [mailto:member-ws-resource-access-request@w3.org] On Behalf Of Bob
> Freund
> Sent: Tuesday, May 12, 2009 8:40 AM
> To: member-ws-resource-access@w3.org 
> <mailto:member-ws-resource-access@w3.org>
> Subject: Agenda 2009-05-12 WS-RA distributed meting
>
> Distributed meeting
>
> Time: 15:30-17:00 EDT
>
> Dial-in and IRC according to usual practice[5]
>
> Topic: Opening
> Roll
> Selection of scribe, see scribe list[1]
> Approval of this Agenda
> Approval of minutes from the 2009-0-05 distributed meeting[2]
>
> Note that "*" preceding an issue is chair's suggestion of priority  
> discussion
> "#" ought to be quickly closable (But the chair is often surprised)
> Items marked "X" in the chair's opinion need seasoning
>
> Topic: WG Administrivia
> -Reminder to record your frf attendance[4] BEFORE 23:59 Boston time on  
> 5/26
> -Introduction, new WG Member Paul Nolan
>
> Topic: May Snapshot
> -folks ready with review of incorporated issues?
>
> Topic: Task Team Progress
> -Team 6401
> -Activity to consolidate Mode Proposals (Geoff, Gil, Who?) Do we have  
> one list that folks think is "the list"?
>
> Topic: Action Items where are we?
> http://www.w3.org/2002/ws/ra/tracker/actions/open
>
> Topic: New Issues
> -none-
>
> Topic: Issues with proposals
> Common:
> -none-
>
> Enumeration:
> #-Issue-6860 wsen:EnumerationEnd/wsen:EnumerationContext is unusable  
> and unnecessary http://www.w3.org/Bugs/Public/show_bug.cgi?id=6860 -Pilz
>
> Eventing:
>
> X-Issue-6692 WS-Eventing: Remove Mode from the specification
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>  -Snelling
> #-Issue-6696 Eventing: When to check the EPRs
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6696
>  -Davis
> *-Issue-6724 Eventing: define resource representation
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6724
>  -Davis
> #-Issue-6850 Eventing: remove unneeded text in conformance section
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6850
>  -Davis
>
> Transfer:
> #-Issue-6594 Transfer: Add extensibility points for WS-Transfer  
> wrappers http://www.w3.org/Bugs/Public/show_bug.cgi?id=6594 -Davis -
> Bullen (Action-57)
> #-Issue-6672 Transfer: Non deterministic behavior of PutResponse
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6672
>  -Davis -Bullen (Action-57)
> #-Issue-6673 Transfer: Non deterministic behavior of Create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6673
>  -Davis -Bullen (Action-57)
>
> *-Issue-6712 Transfer: Create is ambiguous
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712
>  -Davis (Action-59)
> #-Issue-6849 Transfer: remove WSA comment in conformance section
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6849
>  -Davis
>
> Resource-Transfer:
> -Issue-6699 RT: ability to assign metadata during create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6699
>  -Davis
>
> MEX:
> -Issue-6500 MEX: Wrappers around GetMetadata
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
>  -Bullen (6398)
>
> ===
>
> Topic: Issues for general discussion
> All:
> #*-Issue-6694 All: Which specifications have implicit operations?
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6694
>  -Davis
>
> Resource-Transfer:
> -Issue-6422 RT - Introduces An Ad Hoc Boxcarring Mechanism
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6422
>  -Bullen
> -Issue-6575 RT - Fragment Put should allow computed values
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6575
>  -Bullen
> -Issue-6634 RT - Document algorithm for modify
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6634
>  -Bullen
> -Issue-6635 RT - Outer resource with individually addressable inner  
> resources http://www.w3.org/Bugs/Public/show_bug.cgi?id=6635 -Bullen
> -Issue-6636 RT - Add example of resource after the create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6636
>  -Bullen
>
> Eventing:
> -Issue-6435 WS-Eventing needs state table to fully describe protocol
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6435
>  -Pilz
> -Issue-6642 WS-Eventing does not describe how to advertise policy for  
> Subscription Managerhttp://www.w3.org/Bugs/Public/show_bug.cgi?id=6642  
> -Pilz
>
> MEX:
> -Issue-6406 WS-MEX - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6406
>  -Davis
> -Issue-6463 MEX-Attaching Policy to WS-Mex GetMetadata
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6463
>  -Warr
> #*-Issue-6674 MEX should reference latest W3C REC versions of WS-
> Policy and WS-PolilcyAttachment
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6674
>  -Pilz
> -Issue-6679 MEX's stance towards metadata scope and semantics needs  
> clarification http://www.w3.org/Bugs/Public/show_bug.cgi?id=6679 -Pilz
> -Issue-6680 MEX Section 3.2 has inconsistent properties
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6680
>  -Pilz
>
> Enumeration:
> -Issue-6436 WS-Enumeration needs state table to fully describe  
> protocol http://www.w3.org/Bugs/Public/show_bug.cgi?id=6436 -Pilz
>
> AOB
> Adjourn
>
> ===
> N.B.
> Issues needing owners
> -Issue-6701 Enumeration: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6701
> -Issue-6702 MEX: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6702
> -Issue-6703 RT: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6703
> -Issue-6704 Transfer: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6704
>
> Needing Proposals prior to Discussion:
> Transfer:
> X-Issue-6413 Transfer- Move Fragment support from RT to Transfer
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413
>  -Davis -Warr
> -Issue-6533 Transfer: Safeness of operations
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6533
>  -Lafon (Action-45)
> -Issue-6551 RT - Message processing time exceeded
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6551
>  -Bullen (Action-13)
> -Issue-6632 RT - Define fault for cases where the GetResult is too  
> large http://www.w3.org/Bugs/Public/show_bug.cgi?id=6632 -Bullen  
> (Action-32)
> -Issue-6633 RT - Namespaces in updates
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6633
>  -Bullen (Action-32)
> -Issue-6691 WS-T/RT - Reconcile faults
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6691
>  -Warr (Action-51)
>
> Enumeration
> -Issue-6403 Enumeration - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403
>  -Davis (Action-60) -Bullen
>
> Resource-Transfer:
> -Issue-6407 WS-RT - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6407
>  -Davis (Action-25)
> -Issue-6549 RT - Create focused on resource fragments
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6549
>  -Bullen
> -Issue-6550 RT - Support for XSLT and XQuery in PUT
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6550
>  -Bullen (Action-11)
> -Issue-6552 RT - Lifecycle metadata for Create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6552
>  -Bullen (Action-12)
> -Issue-6576 RT - No Fault Defined for Mi6432smatch between  
> ResourceTransfer header and message body
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6576
>  -Bullen (Action-28)
> -Issue-6578 RT - SideEffects applies to other faults
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6578
>  -Bullen (Action-29)
> -Issue-6579 RT - Bad fragment values with Create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6579
>  -Bullen (Action-30)
> -Issue-6603 RT - Inconsistencies in CreateResponse message
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6603
>  -Bullen (Action-20)
>
> Eventing:
> -Issue-6401 WS-Eventing Notifications violates WS-I BP
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401
>  -Davis (Action-61) (Task Team Li Pilz)
> -Issue-6402 WS-Eventing - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6402
>  -Davis (Action-24)
> -Issue-6421 Eventing-Extension point in reply message of Unsubscribe
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6421
>  -Bullen (Action-27)
> -Issue-6429 Eventing: Standardize Wrapped Event Sink
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6429
>  -Li (Action-42)
> -Issue-6700 Eventing: Complete Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6700
>  -Wu
>
> MEX:
> -Issue-6411 WS-MEX: no way to create metadata
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6411
>  -Davis (Action-26)
>
> ===
>
> Blocked with dependancy on (issue):
>
> Eventing:
> X-Issue-6430 Eventing-Remove Attribute wse:EventSource
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6430
>  -Li (6401)
> X-Issue-6661 WS-Eventing Appendix I is incomplete and incorrect
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
>  -Pilz (6401)
> X-Issue-6432 WS-Eventing Push delivery mode does not work when the  
> subscriber is not
> addressablehttp://www.w3.org/Bugs/Public/show_bug.cgi?id=6432
>  -Pilz -Davis (6692)
> X-Issue-6803 RT: Is this functionality required?
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6803
>  -Bullen (6413)
>
> ===
>
> [1] http://www.w3.org/2002/ws/ra/chair-tools/scribelist.html
> [2] http://www.w3.org/2002/ws/ra/9/05/2009-05-05.html
> [3] http://www.w3.org/2002/ws/ra/wiki/Main_Page
> [4] http://www.w3.org/2002/09/wbs/43088/200906F2FReg/
> [5] http://www.w3.org/2002/ws/ra/admin.html
>  [attachment "smime.p7s" deleted by Doug Davis/Raleigh/IBM]
>
Received on Monday, 18 May 2009 20:46:57 UTC