Replacement for @version that places an optional @profile attribute on atom:feed and atom:entry elements. @profile identifies a list of Profiles against which the feed/entry element was generated. A profile is a specification detailing which metadata elements are required in the entry/feed and the cardinality of such. A Core Profile is defined to which all Feed/Entry elements are assumed to adhere to unless otherwise specified using the @profile attribute. This proposal rearranges the current spec a bit by moving the metadata containment requirements for both the feed and entry elements into a new section of the document.




(Taken from Mark Nottingham's initial proposed posted to the mailing list)

"There are a number of use cases for Atom (e.g., blogs, news, archiving, stock quotes, systems monitoring); each has potentially different requirements for the presences of certain kinds of metadata. To cater to these use cases, and allow implementations to make assumptions about feed content when presenting it, we need to identify the *profile* of metadata that a feed can be expected to contain."

"Furthermore, we need to ship at least one profile with the spec. Right now, it's embedded in the schema of what metadata elements are required; it would be better to explicitly call it out."

This proposal is an extension of Mark's initial concept that allows the profile attribute to be a list of profile names. The idea is that a single entry/feed may be created to adhere to multiple profiles. For example, a given feed may conform to blog, news and archiving profiles.

An important aspect of this proposal is that it places no behavioral requirements on the part of Atom implementations. The profiles attribute is strictly informational. If a atom processor finds a feed that uses a profile it does not understand, it can ignore that profile and attempt to parse the feed under the assumption that it adheres to the Core Profile that would be defined by the spec.

While there should be some concern over the potential for confusion caused by incompatible profiles, the reality is that it is not likely that many different Atom profiles will be created and that those created will generally be defined in such a way that they are backwards compatible with the core profile. I know this is an optimistic view, but it is one that is based on the assumption that the vast majority of Atom implementors will view interoperability and backwards compatibility as a Good Thing and that the amount of work involved with implementing non-backwards compatible, non-interoperable profiles is significant enough to deter such silliness from becoming rampant. The profile mechanism allows us to evolve the metadata containment requirements independent of the semantics of the individual elements themselves, thus achieving the goal originally intended for the version attribute, but in a way that is much more flexible and with defined semantics. The existing version attribute really had no defined semantics for how requirements modifications would occur, how backwards compatibility should be handled, etc. This proposal provides those things with a minimum of new overhead.


4.1.1 The "profile" Attribute

atom:feed and atom:entry elements MAY have a "profile" attribute whose value is a space delimited list of names or non-relative URI's identifying one or more metadata profiles that have been applied to the feed or entry. A profile is a description what metadata elements are required and optionally, for each one that is required, the maximum number that may be present.

Each item in the list MUST be either a name, which is non-empty and does not contain any colon (":") or space (" ") characters, or a URI [RFC3986]. The use of relative URIs is not allowed. If a name is given, implementations MUST consider the name to be equivalent to the same name registered within the IANA Registry of Atom Profiles Section 9, and thus the URI that would be obtained by appending the value of the name to the string "".

The identification of profiles applied to an entry or feed is intended to be informational only and does not impose any behavioral requirements on implementations. An entry or feed is "compliant" with a profile if and only if it adheres to all of the requirements set forth in the profile description. A feed or element may be compliant with multiple profiles. An entry or feed element that complies with multiple profiles SHOULD specify each profile in the "profile" attribute.

The profile name "core" is used to identify the Atom Core Profile described in Section 6.1. An entry or feed element that does not specify a "profile" attribute MUST adhere to the Core Profile.

6.0 Atom Profiles

Atom Profiles are specifications that identify named collections of metadata elements that are required to be present in either the feed or entry elements. Each profile is identified either by a name registered within the IANA Registry of Atom Profiles described in Section 9.2 or a URI. A profile describes the the elements that MUST be present within the entry or feed element and the maximum/minimum number of such elements that are allowed. The profile(s) to which an entry or feed element applies is identified using a @profile attribute on either entry or feed elements.

Profiles are informational only, and do not impose any behavioral requirements on implementations. Specifically, the only Profile that Atom implementations are required to support is the Atom Core Profile described in Section 6.1 below. Support for all other profiles is optional. If an implementation is presented with a feed or entry whose @profile attribute specifies a profile unknown to the implementation, the implementation MAY choose to ignore that profile and continue processing.

6.1 The Atom Core Profile

The Atom Core Profile is the default profile for all Atom feeds and entries and is identified by the name "core" as registered in the IANA Registry of Atom Profiles. All entry and feed elements that do not explicitly specify a @profile attribute MUST conform to the Atom Core Profile.

6.1.1 Requirements for atom:feed

atom:feed elements conforming to the Atom Core Profile MUST adhere to the following requirements.

6.1.2 Requirements for atom:entry

6.2 Interoperability Considerations for Atom Profiles

Interoperability between Atom implementations relies on the ability to for those implementations to rely on a consistent collection of required metadata elements. The Core Profile described above is intended to provide a foundation upon which such interoperability may be based. New Atom Profiles MAY choose to either extend or modify the requirements specified by the Core. Profiles that seek only to extend the Core without changing any of those core requirements will have a much greater chance of ensuring appropriate levels of interoperability. Profiles that modify the core requirements run the risk of breaking interoperability in Atom implementations. Because of this, for the sake of protecting interoperability, it is highly recommended that new profiles seek to extend the core rather than modify it.

9.2 Registry of Atom Profiles

This registry is maintained by IANA and initially contains the Atom Core Profile identified by the name "core". New assignments are subject to IESG Approval, as outlined in [?]. Requests should be made by email to IANA, which will then forward the request to the IESG requesting approval. The request should contain discussion of at least the following five topics:

* A value for the name identifying the profile that conforms to the syntax rule given in Section 4.1.1 * Common name for the profile type * Description of the profile requirements / semantics including how the profile modifies/extends the Atom Core Profile * Atom Core Profile interoperability considerations * Security considerations



This was initially proposed by Mark Nottingham and developed further through discussion on the mailing list.