Re: [ws-dd] Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924

Li,

W/regards to "tools getting confused by inlined Notification WSDLs" I 
would note the following:

1.) As proposed by MOAP, Notification WSDLs appear as children of a 
parameter of a policy assertion. Evenly only moderately robust tools are 
likely to ignore information nested within policy assertions that they 
don't (by definition, since we're just inventing this stuff) 
"understand" (i.e. know how to process), if only out of laziness.

2.) Any WSDL tool that breaks because there is a nested 
<wsdl:definition> does not conform to WSDL-1.1 (as amended by BP) 
because WSDL-1.1 (as amended by BP) does not forbid the use of 
wsdl:definition as a decedent of an extension element (such as 
wsp:Policy/wse:EventSource/wse:FormatName). In other words, the tool is 
imposing constraints on the information model of the description that 
are not there in the base specs.

3.) Even if you were using a tool that was broken in this respect, it's 
not that big of deal to modify a local copy of the WSDL to use a 
reference to the Notification WSDL instead of inlining it. i.e. the 
workaround is fairly painless

- gp

On 1/26/2010 8:33 AM, Li, Li (Li) wrote:
> As described by Antoine, two approaches can provide the linkage between
> the port types of event source wsdl and notification wsdl. Regardless
> the approach taken, we think the following issues have to be addressed.
>
> 1) one-way or two-way links
> We think one-way link is sufficient since two-way links are more
> difficult to maintain.
>
> 2) direction of the links
> Both i) source ->  notification and ii) notification ->  source links can
> represent m-n relations. We think direction i) is more inline with the
> model in appendix A where the subscriber knows the event source first.
>
> 3) no event source port type
> It is possible that the event source wsdl has no port type because i) it
> has no operations other than ws-e; and ii) ws-e is implicit. In this
> case, the event source wsdl has no port types.
> If this happens, we may use a dummy empty port type in the event source
> wsdl. For example, a wsdl extension approach may look like:
>
> <portType name="xyz" eventTypes="list of URL" />
>
> The advantage of this approach is that the links exist only between port
> types and we avoid the complexity arising from cross-linking ports and
> port types as proposed in [2].
>
> 4) problem with wsdl import
> To import notification wsdl into event source wsdl (or vice visa) could
> be problematic for code generation by some tools. If the tools cannot
> distinguish regular operations from those representing event types, as
> they both are inbound, they may generate incorrect and unnecessary code.
> Typically, an event source implementation should generate server side
> code from the event source wsdl and client side code from the
> notification wsdl. If the two wsdl are merged through import, only one
> type of code will be generated.
>
> To address this issue, we should not import the wsdl files. Instead, the
> attributes or the policy assertions should indicate the URL of the wsdl.
>
> One way to achieve this using policy is proposed in [2][3]. An example
> to use plain URL to locate the port type in a wsdl is:
>
> eventType="http://wwww.example.com/myservice.wsdl#port-type-name"
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8198
> [2]
> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/at
> t-0012/NotificationWSDL_for_6401-6661_v4_submit.htm
> [3]
> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/00
> 12.html
>
>
> Li
>
>
>