RE: issue 6401/6661: combined proposal

Gil,

 

First, I was not asking to undelete that paragraph you're referring to.
Rather, I was trying to tie the common concept of "Event Types" defined
in A.1 to the Notification WSDL (NW) option in A.3, to make the two
options complete and independent. To achieve this, I proposed this
statement for A.3:

 

            The Events and Notifications MAY be described via WSDL...

 

Otherwise, it may appear that "Event Types" is only relevant to the
Event Description option in A.2, and the NW option is thus incomplete
and dependent on A.2. This is of course neither the WG consensus nor
your intention on this issue.

 

However, if you think that NW should not be tied to "Event Types", then
we could merge section A.1 into A.2, to make the two options
self-contained. This approach could work too because people have been
doing events with WSDL without resorting to the concept of "Event Types"
at all. With this refactoring, the appendix A looks like this based on
Doug's version [1]:

 

A 

(no change)

 

A.1 Event Descriptions Option

(previous A.1 + previous A.2)

 

A.2 Notification WSDL Option

(previous A.3 no change)

I'm open to either approach, as long as it satisfies our agreement that
these two options are independent. Thanks.

Li  

[1]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/at
t-0061/ws-eventing-6401-6-dug2.doc

________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Friday, August 28, 2009 3:25 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org
Subject: Re: issue 6401/6661: combined proposal

 

Li,

I think the sentence you are referring to is, in fact, incorrect. It
would have been more accurate to say:

"The portTypes contain operations which may or may not map to the Events
that are transmitted."

There are a number of reasons why it might not be possible to map from
an operation to an Event (or Event Type).

1.) Wrapped Notifications deliberately avoid any linkage between the
Notify element that the Event's it contains.

2.) The /portType/operation/input/@message may refer to a /message who's
'part' element contains a @type (that refers to an XML Schema type) and
not an @element (which refers to a XML Schema GED). Since we defined
Event Types in terms of GED's, what you end up with is
similar-but-not-really an Event Type. You certainly can't construct an
XPath 1.0-based filter when all you know is the schema type.

3.) The /portType/operation/input/@message may refer to a /message with
more than one 'part' element. Unless you understand the details of the
Notification Format that corresponds to this Notification WSDL, it is
hard to determine which part is the 'event part' and which is 'other
stuff'. It is entirely possible for the event information to be split
between two or more parts.

Even in situations in which there is a an unambiguous linkage from
/portType/operation/input/@message --> /message/part/@element --> GED,
we would need to describe this linkage, the constraints on the
Notification WSDL that make it possible, and the Notification Formats
for which it is valid. This would add a great deal of complexity to what
is already a fairly complex subject and it is not clear to me that this
increase in complexity would yield a corresponding increase in either
clarity or functionality.

- gp

On 8/28/2009 11:57 AM, Li, Li (Li) wrote: 

... It worth noting that this was part of the 
proposal that was originally sent in - I didn't change this sentence.
 
Doug:
 
Yes, that sentence was in Gil's proposal to the WG
(http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0
058.html). However, your change
(http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/a
tt-0061/ws-eventing-6401-6-dug2.doc) deleted the following sentences: 
 
Notification WSDLs contain abstract port types and concrete bindings. 
The port types contain operations that correspond to the Events that 
are transmitted. The bindings describe the Notification Formats (e.g. 
Unwrapped or Wrapped) for those Events.
 
Those sentences define what a Notification WSDL may contain: Events and
Notification Format. That's why I added a few words to retain the above
meaning. If we remove them completely, we lost what a Notification WSDL
can do in general. 
 
Thanks,
 
Li