Big switch in direction from Microsoft, it would appear they are now planning to use AtomPub instead of Web3S for Windows Live service APIs they’ll formally be announcing at Mix’08. As usual, Dare has all the details.
I lean towards agreeing with Joe. I like the idea behind APML in that I can see the need for a standard format for publishing attention information. However I don’t think it is credible to attempt to specify how to safely distribute and share attention data (which has privacy and trust issues written all over it) using a simple annotated schema document and a php-based example parser implementation. Problems
- The core APML XML schema is woefully underspecified. The semantic meaning of the various elements/attributes is really not clearly specified at all. To illustrate what I mean, compare and contrast the Atom Syndication Format specification with the APML specification.
- There is no protocol specification how to access/update APML documents. Again, referring to a specification like the Atom Publishing Protocol highlights the need for such a specification.
- At this stage, I think anyone producing specifications that essentially contain lists of data for consumption by arbitrary web based clients should seriously consider extending the Atom (or RSS) syndication formats rather than rolling their own schema. They should also consider adapting AtomPub for publishing this type of content (e.g. as Google did for OpenSocial APIs)
- The APML specification seems to have been developed in a sandbox. I know it is listed alongside OpenID, microformats and others at (what is now the buzz site of this week) DataPortability.org but it does not build on or integrate with any of these specifications (worth noting that Chris Saad is behind both efforts). There are no requirements, recommendations or guidelines on how to use APML within the context of existing and pending web infrastructure. Sure I could build an APML service and then stick it behind an OAuth login system but then I may end up with a service that nobody can use with their client libraries.
That last point actually brings me to something else I’ve been meaning to blog about – DataPortability.org. First off, I think this website is a commendable effort at raising the profile of the specifications it is linking to. However, and this is a big however, I have seen this happen before many, many times in enterprise-software-land (I’m looking at you CORBA and J2EE vendors!). Consortium of big vendors would get together to discuss reference designs or ‘profiles’ for combining various specifications into an “industry recommended solution” that is then vaguely referenced by each company’s website to claim ‘compliance’.
However, in the absence of free and open reference implementations for these solutions (and I mean an integrated reference implementation here) true compliance and interoperability will never really be achieved. There is simply no carrot there for the vendors to work hard to achieve this and there is no stick large enough for the community to beat them with to play fairer. So I’m afraid that for now I’m not drinking the kool-aid regarding Google and Facebook joining DataPortability.org Sorry, but given both Facebook and Google’s recent track records I can only assume that this is mostly a PR exercise.
- The People Data API exposes people (viewer, owner, friends) via Atom feed documents and Atom entry documents. However, there is no AtomPub support for this feed so people cannot be created/updated/deleted via API. I suspect this will cause some debate as it means some fairly critical data remains locked into the underlying OpenSocial containers
- The Activities Data API exposes activities (news feeds etc) as a Atom feeds. The Activities data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.
- The Persistence Data API exposes name/value pair data (e.g. configuration params) as a Atom feeds. The persistence data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.
I’m off for a curry but more later today. Here’s a teaser though – authentication is a concern….