netzooid

Bill de hÓra writes:

Here’s the thing; almost any mU use-case I can think of involves a point-to-point communication between two parties where the sender is directly addressing the recipient or a relatively small set of recipients. It doesn’t make sense in a pseudo-broadcast environment, which seems to be most RSS served up today. That includes aggregators.

It’s the difference between “I’m sending this document and you must understand these data” and “I’m putting this document on the web and everyone must understand these data”. I doubt the latter is viable.

APP interestingly already has something along the lines of mustUnderstand:

<collection
href="http://example.org/blog/pic">
<atom:title>Pictures</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>


Or from the spec:

A value of “application/atom+xml;type=entry” MAY appear in any app:accept list of media-ranges and indicates that Atom Entry Documents can be POSTed to the Collection. If no app:accept element is present, clients SHOULD treat this as equivalent to an app:accept element with the content “application/atom+xml;type=entry”.

In other words, the sender knows that it can only send one of the listed accepted content types. Which seems to imply that the sender must understand one of those media types - i.e. an atom entry. Which doesn’t seem that far from saying that a client can only send an encrypted atom entry. Or that a client can also send Atom entry drafts

I think there’s probably a valid use case for describing things that a client must do in order to send things to the server. This seems slightly different than Bill’s assertion that mU is only useful inside the message being sent from the sender, which also seems valid.

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.

Atom (or Atom/RSS) Specific Standards

• Atom
• Atom Publishing Protocol
• Features
• GData
• GeoRSS
• Simple Sharing Extensions
• Media RSS

Non Atom Specific Standards:

• HTTP
• OpenSearch
• XML Encryption
• XML Signature
• WSSE Authorization (I’ll avoid claiming WS-Security as well)

I know there are a few more being developed as well. Let me know what I missed and I’ll update the page. By the way, I do mean this in jest - for the moment :-). We’ll see how many more specs we can add to the list.

A few weeks ago I put together some support for Abdera users who are using Spring. This allows you to build AtomPub services pretty easily using Spring. Here’s a quick example of what a typical Spring config will look like:

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:a="http://abdera.apache.org"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    http://abdera.apache.org http://abdera.apache.org/schemas/abdera-spring.xsd">

<bean id="provider" class="org.example.MyProvider"/>

<a:serviceContext>

<a:provider>
  <ref bean="provider"/>
</a:provider>

<a:targetResolver>
  <a:regexTargetResolver>
    <a:collection>/atom/feed(\?[^#]*)?</a:collection>
    <a:entry>/atom/feed/([^/#?]+)(\?[^#]*)?</a:entry>
    <a:service>/atom(\?[^#]*)?</a:service>
  </a:regexTargetResolver>
</a:targetResolver>

</a:serviceContext>

</beans>

In Abdera, services are backed by a Provider. This is the place where your application specific logic goes for creating, editing or deleting resources. In the above example we’ve declared our MyProvider class as a bean.

This bean then gets wired into the Abdera ServiceContext. The ServiceContext is kind of the central hub on the server side which controls how HTTP requests get mapped to provider. Of primary importance in this mapping is Target Resolver. It helps determine whether a request gets mapped to an Atom collection, entry or service. The above example uses a RegexTargetResolver to do this. “/atom” urls get mapped as a service, “/atom/feed” urls get mapped to a collection, and “/atom/feed/foo” urls get mapped to a specific Atom entry.

This should be included in the upcoming 0.3.0 release which is being voted on. For more info, I’ve been writing some documentation here. Enjoy, and let me know if you’ve found it useful!