issue 6401 - an outline of a proposal

In thinking about the two proposals for 6401 I've come to the following 
conclusions:

- we need some kind of Notification Data in order to allow for filtering 
to be done independent of the format URI used.  This is needed to align 
with what's in the spec:
When the Delivery Format feature is engaged the formatting of the outgoing 
events occurs after any filtering. This ensures that regardless of what 
type of formatting might occur, the same Filter dialect/expression can be 
used to subset the event stream. 
Otherwise the filter expression would change as the FormatURI changes.

- we need some kind of Notification Data in order to allow extra data to 
be associated with events regardless of whether that data is transmitted 
over the wire.  For example, topics might need to be associated with 
events even though a Subscriber chooses a FormatURI that doesn't serialize 
them on the wire.  Wu's proposal only allows for filtering of data that 
appears in WSDL/on-the-wire.  Although, its not clear to me how you can 
filter over info that appears as a soap header when the filtering is done 
before serialization (see above) - its a catch-22 situation.

- we need some kind of mechanism by which a client (the sink) can ask the 
source for the WSDL that sinks need to support.  While Gil's proposal says 
that a mechanism needs to be defined so that sinks can generate the 
appropriate WSDL, there are clearly some people who really really want the 
source to provide it to the sink.

- we need a clear mechanism by which the sink can know exactly which WSDL 
file to use based on the FormatURI used.  Wu's proposal ( 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0012.html 
) shows the problem. Which of those policy refs go with which FormatURI?
In thinking about this problem I came to the realization that there is a 
1-1 relationship between the FormatURI and the sink's WSDL - so let's take 
advantage of this.

I'd like to propose that we solve this by doing both.  So, my proposal is 
this:
1 - an event source SHOULD expose EventDescriptions retrievable thru:
    mex.getMetadata(dialect=".../EventDescriptions"); 
2 - an event source SHOULD expose the expected event sink WSDL for a 
particular FormatURI retrievable thru:
    mex.getMetadata(dialect=".../NotificationWSDL", id=FormatURI);

This allows for examination of the eventing information in a form that 
isn't FormatURI specific, or even specific to which bits of data appear on 
the wire.  But, it still supports the case of having the source provide 
the WSDL that the sink is meant to implement.  Both are optional and 
neither is favored over the other.

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.