	The DataPortability Project	Log In \| Sign Up
	DP-REC-001 - Feed Subscription

Browse Space

Added by Paul Jones , last edited by Paul Jones on May 02, 2008 (view change)

Overview

This specification recommends the use of OPML for the transport of feed subscription lists. Documented at http://www.opml.org/spec2, it provides a simple mechanism for exporting a user's subscription from one application, and importing them into another application. Widely supported in feed readers, there are no alternatives that have anywhere near the implementation.

Technology Purpose

More in-depth information on the technology, including:

What problem it solves
Origins (who developed it, etc)

Selection Rationale

Why this technology was selected over others in the same field, including:

Brief details of other technologies.
Why this technology is better.

Details of Adoption

Forming a vital component of the final approval process, this section should detail implementations that have adopted the technology, and therefore are showing that the technology has real-world applications and acceptance.

Action Group Backing

Members of the action groups that back this technology should be listed here, as a formal tracking of support for the recommendation.

Comments (Hide Comments)

Why limit ourselves to one of many file formats? opml may be adequate, but why not just list what you want (functional requirements, uses, constraints) out of a list of feeds, and leave opml as the first format identified to do that job?

Posted by Phil Wolff at Apr 19, 2008 12:17

The concern that I always believe we need to bear in mind is that everytime a format is prescribed, then the intent is that it should be implemented. Having X different feed subscription formats means that a fully compliant implementation would need to support all of them. Personally, I believe that only in cases where there are a few solidly entrenched formats (such as perhaps RSS and Atom) should more than one format be accepted.

OPML, realistically, has very strong support in all feed readers right now, and generally constitutes the first class format for moving subscriptions around in most applications.

Posted by Paul Jones at Apr 19, 2008 17:20

Paul, you didn't really respond to my concern.

We're defining a software stack. We should defining minimal functional requirements and list protocols that meet or excede those requirements. Picking just one protocol, to the exclusion of others, is contrary to the DataPortability.org. mission.

Multiple protocols offer excellent service discovery, for example. XRDS, XRDS-Simple, WSDL and UDDI. We should list those that perform the service and describe them (strengths, weaknesses, communities that use them).

Mixing and matching should show up in blueprints, architectural and design patterns that combine these protocols. Some blueprints could be a better fit for lightweight social services. Some will offer more depth in security for health care and financial industries, perhaps. And still others will use protocols that comply with military and government regulation.

The important thing is that DP.org support the stack architecture, and not lock in protocols that may not fit many markets or adapt to changing times. The stack architecture is flexible and adaptive, encouraging innovation within and between stacks.

So let's not "endorse" protocols but "acknowledge" or "recognise" them as fit to and sufficient for a particular purpose.

Posted by Phil Wolff at May 02, 2008 06:51

Are there pairings of opml with oAuth? In other words, does opml alone do the job? Is there a bigger pattern of asking for a list and getting an answer? Or discovery of a list, and then consumption?

Posted by Phil Wolff at Apr 19, 2008 12:22

My intent with a lot of these recommendations is that each part of the problem is solved in a bite sized chunk. This recommendation is purely intending to indicate that the DataPortability Project is "recommending OPML for use". DP specific usage recommendations (such as the usage of OAuth) should be covered in a DataPortability Technical Implementation document.

I've created the document reference for a data security document, and I intend to draft it quite soon. My aim is to document a standard proposal (using OAuth) for the security of all documents covered (be they feed subscriptions, attention data, or even the service catalogue).

Posted by Paul Jones at Apr 19, 2008 17:23

Are there lifecycle concerns?

Is a list of feeds a perishable item, with a best-if-used by date?
Should a list contain information about its source, so it can be renewed?
Should a list contain pointers to alternative sources, should its original source no longer be available or responsive?

Posted by Phil Wolff at Apr 19, 2008 12:24

To be honest, I'm not really sure with answers to these. I think their answers will definitely best go in an implementation spec that "layers" the DP specific semantics on top.

Posted by Paul Jones at Apr 19, 2008 17:24