Each format: RSS 1.0, RSS 2.0, Atom, Info Bite , etc. requires a certain set of elements and attributes. Why are certain elements required? Which should be required?

Some elements are required so that client and aggregator software can depend on being able to do certain things with feeds. For example, an Atom feed is required to contain a title and an "alternate" link. Because of these requirements, client software can be certain that it can render a feed title as a link for every Atom feed. RSS 2.0 likewise requires a channel title and link. This works out well, because a client that works with both formats can handle both the same way. Makes sense so far.

But not all of the requirements are the same. For example, Atom feeds must have an author element, but RSS 2.0 feeds don't require it. And Atom author elements must have a child element containing a name. RSS author elements, by contrast, must contain an email address. Clearly, the people who created the two formats did not agree completely on the importance of particular pieces of data.

Info Bite List takes a different approach from both RSS and Atom by requiring next to nothing. In fact, the only absolute requirements are that every file contain a channel and every channel have a title. Why so few requirements? Because people are coming up with so many ways to use feeds, and will surely come up with more. Requirements made based on current feed usage may not make sense for future uses.

Info Bite List more than the others, but every format to some degree, runs the risk of being difficult to process because of the flexibility they give publishers. How can we deal with this issue without over-tightening requirements, thereby limiting the usefulness of the formats? The best answer I've heard of to date is profiles. A profile is a set of requirements and recommendations added on top of those in the main specification. Different profiles can be built for different purposes. For example, Info Bite List could have a profile name "Atom 0.3" which requires all of the elements that a feed needs to be convertible directly to a valid Atom 0.3 feed. It could have another profile named "RSS 2.0" requiring the feed to be structured in a way that would make it easily convertible to RSS 2.0. Other profiles might be named "blog", defining a standard for blog-based feeds. Another might be "comic" defining a standard for comic strips.

How are profiles useful? A few ways:

1) They provide guidelines to those just getting into feed publishing to help them build feeds that work as expected in client software.

2) They provide baselines for what some software may require to be able to process a feed, or to be able to process it as expected by the user. For example, if a feed conforms to the RSS 2.0 specification but not the RSS 2.0 Blog profile (I just made up the name--I don't know that such a thing exists), then publishers of client software would have an easier time telling their customers, "sorry, they're not following the profile, so I don't support the way they're formatting their feed. That's why such-and-such feature doesn't work the way you'd expect with that particular feed."

3) If profiles of the same name are be built for each of the feed formats, then we can ensure that feeds in each of the formats can be used for particular purposes in roughly the same way. They could provide a basis for specifying the mapping of elements between feeds when used for particular purposes. (Although all the formats are similar, there is not a one-to-one mapping between the elements of each format, so without some set of guidelines, converting from one to another, or handling each in a way consistent with the others can be fairly difficult).

4) Profiles could be used to define a subset of a particular specification which one supports. For example, a simple Info Bite List client may not support the defaults elements and xml:base processing. A profile might be created which excludes those parts of the specification, enabling one to refer to a client that has a particular amount of partial support for the format with a standard name.

5) They provide a way for people who aren't in a position to make decisions about a format to comment on how they think the format should be changed or used. For example, I created the Info Bite List format, including the defaults section, which will probably be the most difficult part to implement. If the majority of Info Bite List clients adopt a profile that excludes defaults, they can send the message that defaults are too much of a headache to implement. It would almost be as if the standard didn't have defaults, but there was an extension that added them, which wasn't widely supported.

It might be argued that widespread use of profiles would just fragment the industry further. But considering that profiles are compatible refinements of standards rather than incompatible standards, I think that a carefully considered use of profiles could provide a useful framework for the expansion of the use of feeds for many purposes.