UserPreferences

PaceProfile


Abstract

Rearrange the format draft to allow @version (or a replacement attribute, @profile) to identify the kinds of metadata that are required in the feed. Also, provide better separation between Atom-defined elements that are containers and Atom elements that are metadata.

Status

New.

Rationale

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.

Proposal

1) Change the organisation of the document to this rough outline. For each section listed, content will be the same (delta editorial work as a result of rearrangement) as in the current draft, except where noted.

  1. Introduction [ No change ]

  2. Atom Documents [ No change ]

  3. Atom Container Elements [ This new section describes a fundamentally different kind of element in Atom; the *container element*, as opposed to the *metadata element*. Container elements are used to delineate the shape of the feed (e.g., head, entries), and to contain metadata. Generally, container elements will have a much slower rate of change than metadata elements. ]

  4. [ No change ] [ About the same as now, *except* that it doesn't nominate or require any specific metadata elements. ]
  5. Atom Core Metadata Elements [ About the same as the current list of metadata, *except* that each one doesn't talk about whether the element is required or not, but *does* talk about what the cardinality constraints are when it is present. E.g., "When present, there MUST be exactly one atom:title element." ]

  6. Common Atom Constructs [ No change ]

  7. Atom Profiles [ Atom Profiles are a way to package sets of metadata so that a feed is suitable for a particular application. For example, a "weblog" profile might say that the title, description and content metadata for feeds must be present, while another application of Atom might not need this metadata.

An Atom Profile MUST be identified by a URI (which can be used in feed/@profile), and MUST nominate two sets of metadata elements; one for atom:head, and one for atom:entry. Members of these sets are considered required for instances of feeds that advertised that profile; Atom Documents that advertise a profile MUST contain that profile's required elements in the appropriate Atom container elements, if those container elements appear in that type of Atom Document. ]

  1. Managing Feed State [ No change ]

  2. Securing Atom Documents [ No change ]

  3. Embedding Atom in Other Formats [ No change ]

  4. Extending Atom [ Note that people can author new Metadata Elements as well as new Atom Profiles ]

  5. IANA Considerations [ No change ]

  6. Security Considerations [ No change ]

Impacts

Changes the layout of the specification and the ability to define new extensions and profiles; does not affect current implementations at all, with the possible exception of changing @version to @profile (see below).

Notes

This effectively positions Atom Documents as *containers* of bags of metadata, and the children of those containers as *metadata*; the only place where we constrain what metadata the feed requires is in the profile definition. This flexibility point allows new arrangements of metadata to be accommodated as new profiles, while still providing default profiles with the spec so that we ship something interoperable. It also means that the only reason to change the namespace for atom:feed, atom:head and atom:entry is if their semantics change; likewise, the only reason to change the namespace for one of the metadata elements is if its semantics changes.

I'm not stuck on the term "profile"; in fact, I'm happy to ditch @profile as long as the semantics of @version are changed to this.

Note that a profile DOES NOT preclude the addition of more metadata; it only states what metadata is required to be there. So, you can extend a profile, you just can't go below its bar.

I don't believe it should be possible to nominate more than one profile at a time, but I'm not tremendously against it; there shouldn't be any big problems.

I don't believe it should be possible to specify profiles at different places in an Atom Document; this brings different kinds of profiles, and is too fine-grained a mechanism to be useful IMO.

Note that cardinality information for a particular metadata element now lives *with* that element; if you want to change how many can appear, come up with a new element.


CategoryProposals