netzooid

Sergey has some rather interesting thoughts on integrating WS-Policy with AtomPub:

“…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.”

These are good points. I, as I think Sergey as well, would like to see only minimal profilieration of Atom specific specifications. If there is an opportunity for something to be used in the wider category of RESTful services, I think we should embrace it.

Sergey goes ahead and makes two proposals about how WS-Policy could be used in replacement of Atom Features. The first idea is to simply use a policyreference element to state that a feature must be supported:

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

I think Sergey is thinking here that the URI may not necesarily resolve and it would just be globally understood. Seems a bit hackish to me as the idea behind policy attachments is that they’re resolved. This is why I think his second idea of just creating new policy elements is cleaner:

<wsp:Policy>
<feature:supportsdraft feature='http://purl.org/atompub/features'/>
</wsp:Policy>

This could be inlined inside a APP service/workspace quite easily. Or it could be referenced inside a service/workspace from a policy attachment.

Why WS-Policy though? As Sergey mentions, WS-Policy is not tied to SOAP or message oriented services even. It works well with RESTful services. I think if we could avoid a new specification which duplicates WS-Policy, it’d be better for everyone (however I’m no expert in these areas, so take what I say here with a grain of salt).

We could potentially develop a rich set of policy expressions for HTTP which work with all types of RESTful services. Some hypothetical policy expressions:

• Express which mime types are understood as part of an Atom entry’s content (i.e. my service understands application/vnd.acme.customer+xml as acceptable <content>)
• SSL/XML-Enc/XML-Sig security enforcement
• Express the relationship between mime types and their descriptions (i.e. application/vnd.acme.customer+xml is related to the schema customer.xsd)

This last case is a rather interesting/important one. This could work in either features or policy, but I think it is one of the missing pieces in APP. How do I figure out how to interact with an APP service if it is expecting a special type of xml document in the content? You need to specify that a service consumer needs to understands a particular mimeType with the specified description to interact with it.  i.e. each entry represents a customer and it has a business specific <customer> xml element in it which must be understood.

In features I suppose it might look like this:

<f:feature ref'http://purl.org/description'>
<UnderstandsDescription mimeType="application/vnd.acme.customer+xml" type="http://.../xmlSchema" href="http://foo/customer.xsd"/>
</f:feature/>

Or in WS-Policy

<wsp:Policy>
<UnderstandsDescription mimeType="application/vnd.acme.customer+xml" type="http://.../xmlSchema" href="http://foo/customer.xsd"/>
</wsp:Policy>

You could even express that the consumer must understand at least ONE of the specified content types to be able to interact with the service.

Interesting posssibilities, and it would be great to hear from the APP/Feature spec folks what they think on the issue.

This entry was posted on Tuesday, September 25th, 2007 at 12:34 pm and is filed under AtomPub.