I'm having a look at the WS-Notification (WS-BaseNotification 1.3 OASIS Standard). I usually find reading some of these specs laborious (and little rewarding), but I'm trying to put some good will towards Web Services (in the WS-* specifications sense). However, shortly after beginning, I found a few caveats that would probably make it difficult for all compliant implementations to interoperate.

Here is an excerpt of the introduction to Section 3 (the NotificationConsumer interface):

WS-BaseNotification allows a NotificationConsumer to receive a Notification in one of two forms:
1. The NotificationConsumer MAY simply receive the “raw” Notification (i.e. the application-specific content).
2. The NotificationConsumer MAY receive the Notification data as a Notify message as described below.
[...]
When a Subscriber sends a Subscribe request message, it indicates which form of Notification is required (the raw Notification, or the Notify Message). The NotificationProducer MUST observe this component of the Subscription and use the form that has been requested, if it is able. If it does not support the form requested, it MUST fault.

At a first glance, a NotificationConsumer (i.e. the recipient of the notification) can be compliant with the WS-Notification standard so long as it can receive the message, whether-or-not it complies with the format described in the following pages. There are subsequent mentions of the raw format, but its use seems to imply the use of SOAP (in a context that uses MAYs and SHOULDs).

Later on, in Section 4.2 (NotificationProducer/Subscribe):

The NotificationProducer should specify via WSDL, policy assertions, meta-data or by some other means, the information it expects to be present in a ConsumerReference. If a ConsumerReference does not contain sufficient information, the NotificationProducer MAY choose to fault or it MAY choose to use out of band mechanisms to obtain the required information.

In addition, WS-Notification relies on WSRF (which more or less re-invents HTTP-based resources, but that's another story). The WSRF specification defines a set of accessors to get and set resource properties, but leaves the door open regarding how these should behave, especially when setting multiple properties in one request. Fair enough, HTTP leaves this responsibility to the applications that use it too. Interestingly, though, WS-Notification doesn't say much either about what should happen when using SetResourceProperties.

To sum this up, I think the core concepts of NotificationConsumer, NotificationProducer, etc. are sound, but the two excerpts produced above make me doubt it can actually achieve some sort of interoperability. It almost sounds like "do what you want so long as you use SOAP and WS-Addressing". I'm yet to be convinced that these two add any value for achieving the goals of Web Services (SOAP for security, maybe?).