ATOM and WS-Policy

You may want to ask, what can such specification as WS-Policy, with its WS- prefix :-), can do with Atom Publication Protocol (APP).

There're several things which I'd like to comment upon.

First thing is that the notion of Policy is by no means specific to the world where big (term borrowed from the RESTful Web Services book) WS-Services live.

Second, WS-Policy Framework and WS-Policy Attachment specifications are actually very neutral. They both use existing policy profiles like WS-SecurityPolicy in the samples but in itself nothing stops people using their own domain-specific policy expressions.

Framework specification is solid, the compromise between the complexity and simplicity has been achieved, one can build primitive and sophisticated policy expressions using a limited set of WS-Policy language operators.

Attachment specification is fairly simple, it defines a number of attachment mechanisms, and then proceeds and recommends how polices can be attached to existing WSDL contracts and UDDI registries.It also defines a mechanism to attach policies to arbitrary XML elements.

I've recently read an APP Feature Discover Draft. It's an interesting read. Here's one paragraph from the Introduction section :

"This document introduces an extension to the Atom Publishing Protocol (Atompub) service document [I-D.ietf-atompub-protocol] format that allows for the documentation and discovery of behaviors, functions or capabilities supported by an Atompub collection. Examples of such capabilities can include the preservation of certain kinds of content, support for draft entries, support for the scheduled publication of entries, use of a particular set of Atom format extensions, and so on."

APP is now considered be suitable for much more than just describing the process for working with feed collections. Typical RESTful service will deal with collections and its members.

Likewise, from the Introduction, it seems obvious to me that the goal which APP Feature Discover Draft is trying to achieve is the one WS-Policy is trying to achieve too except that WS-Policy is not trying to tackle the discovery problem in its current version.

It seems to me that WS-Policy might play the role of a bridge between the two worlds. APP is obviously a solid RESTful protocol. However it may be unrealistic to expect that everyone will use only APP in the future. There're other RESTful protocols around, such as the one dealing with Web3S documents, and there'll be a number of others too. What will unite all of these RESTful protocols is that the majority of them will support XML.

On the other hand, WS-Policy defines an attachment mechanisms which let WS-Policy expressions be attached to arbitrary XML documents. WS-Policy Attachment does not mandate what types of documents policies should be attached to, as opposed to the APP Feature Discover Draft which is linked to APP documents.

Here's an example from APP Feature Discover Draft, but using WS-Policy this time:
<service
xmlns='http://www.w3.org/2007/app'
xmlns:atom='http://www.w3.org/2005/Atom'
xmlns:wsp="http://www.w3.org/ns/ws-policy>
<workspace>
<atom:title>My Workspace</atom:title>
<collection href='...'>
<atom:title>My Atom Collection</atom:title>
<accept>application/atom+xml;type=entry</accept>
<wsp:policyreference uri='http://purl.org/atompub/features/1.0/supportsDraft'/>
</collection>
</workspace>
</service>


Using PolicyReference might not be correct as the policy engine may try to dereference it. I'm not sure one can express the capability with WS-Policy language the same short way as suggested in the APP Feature Discover Draft.
Perhaps something like wsp:PolicyAssertion can be introduced into the language to let policy authors say :

<wsp:policyassertion uri='http://purl.org/atompub/features/1.0/supportsDraft'/>

In meantime a better option might be :
<wsp:policy>
<f:supportsdraft f='http://purl.org/atompub/features'/>
</wsp:policy>

This option may seem more verbose but a Policy operator provides for a grouping of policies and for more sophisticated policy combinations. Once we have more than one feature it can be handy to group them and this is where a Policy operator immediately pays off. Policy expressions can be applied to both service, collection and entry atom elements and to the custom content wrapped inside entries.

Atom clients can then do things like policy intersection by matching their own set of policy requirements with those associated with a given collection, entries, etc.

This analysis can be flawed in that it misses some important details. That said, it's difficult not to notice the obvious similarity between the goals APP Feature Discover Draft and WS-Policy are trying to achieve. It would be good to see a common language for expressing capabilities and requirements.