If not GData, why not WSAP-DAV?

About Microsoft's Web Services Application Protocol, Mark Nottingham suggests...

There will undoubtedly be debate on whether it’s necessary to fuse REST and WS-* together in this manner (especially in the face of things like APP and GData)

The WSAP spec says...

The WSAP operations have been designed to be a superset of the methods provided by HTTP/1.1. In particular, WSAP provides support for structured data manipulation and event notification as an integral part of the service model. Because HTTP and WSAP inherently have different protocol characteristics, WSAP is complementary to HTTP and not intended as a replacement. Rather, the close relationship between WSAP and HTTP allows WSAP services to be accessed either as regular HTTP resources or as WSAP services providing additional support for structured data manipulation and event notification.

But I don't see a rationale about why they chose to extend HTTP using SOAP. If they did not want to stay within HTTP/1.1 as did APP/GData then another option would have been to follow WebDAV/CalDAV and extend HTTP/1.1 with the new methods that appear in WSAP as SOAP methods. The WSAP choice introduces two different programming models, HTTP and SOAP. At least the xDAV approach retains one programming model.

The WSAP approach seems arbitrarily complex. There appear to be at least *two* simpler extension mechanisms. Not to mention the question of the explosion of methods being worthwhile.

Is WSAP also an implicit commentary on WS-Event/Notification/whatever being too complex to easily implement? Why would Microsoft invent a new SOAP event/notification mechanism unless it was too difficult to follow the emerging spec I assume they'd otherwise want to promote?