UserPreferences

PacePersonRef


Abstract

This proposal defines a method for creating person constructs at the feed level (which do not apply directly to the feed as a whole) and then referring to them from the feed level or within entries. Because referring to an author can be done compactly, inheritance by entries that don't specify an author of the feed:author is less valuable, and therefore is removed.

Status

Open
Author: AntoneRoundy

Related and Conflicting Proposals

Rationale

In most feeds, the author is the same for many, if not all, entries, leading to repetition of author metadata. This can be avoided by specifying the metadata in one place in the feed and referring to it from other parts of the feed.

Another solution (the current solution) that reduces repetition even further for feeds authored primarily by a single Person is for entries which do not specify an author to inherit the author of the feed. Arguments have been made against inheritance--for example, the problem of indicating an unknown or anonymous author in a feed which has specified an author (find references for others)--therefore this proposal does away with inheritance. That portion of the proposal could be removed if the concensus is that inheritance is desirable.

Also, at a conceptual level, while identification of the author and contributor(s) is part of an entry, their metadata isn't necessarily part of an entry. Thus it may be logically preferable to specify that metadata outside of the entry itself.

Key questions

  1. Do we want a mechanism for specifying Person metadata once and referring to it from elsewhere in the feed?

  2. Do we want entries to inherit the author from the feed if they don't specify one?

  3. Do we want to define our own attributes (id and ref) or use common attributes (xml:id and xlink:href, for example)?

  4. Do we want to be able to refer to externally defined Person constructs, or must the data be local? (This is not the same question as "do we want a Person construct to be extendable to refer to externally defined and possibly externally stored resources?", which is beyond the scope of this proposal.)

Proposal

Insert the following before section 4.5 atom:author of the Atom format specification:

4.5 atom:people Element

The "atom:people" element is a container for atom:person elements. It MAY contain any number of atom:person elements.

4.5.1 atom:person Element

The "atom:person" element is a Person construct, and MUST follow all requirements for Person constructs. Additionally, it MUST NOT have a ref attribute and it MUST have an id attribute.

4.5.1.1 id Attribute

The atom:person element's id attribute is a string. It MUST be locally unique to the file. It is NOT REQUIRED to be unique across feeds, is NOT REQUIRED to keep the same value when the same feed is served later. The same id MAY be used for a different Person construct each time the feed is served.

Remove "[[explain inheritance]]" from section 4.5.

Replace section 4.13.3 with the following:

4.13.3 "atom:author" Element

The "atom:author" element is a Person construct that indicates the primary author of the entry. atom:entry MAY contain one atom:author element, but MUST NOT contain more than one. If it does not contain an atom:author element, then the author of the entry MUST be considered unknown or anonymous. It is not inherited from the feed.

Insert the following under section 3.2 Person Contructs:

3.2.1 "ref" attribute

The "ref" attribute associates a Person construct with an atom:person element appearing inside the atom:people element. If a Person constuct has a ref attribute, it MUST NOT have any child elements. Instead, their values are taken from the atom:person whose id attribute matches the ref attribute.

Example

<feed> 
        <!-- Complete Person constructs can appear outside of <people> --
                when they do, they apply to their parent element -->
        <author>
                <name>Arthur McFeed</name>
        </author>

        <people>
                <person id="qwerty">
                        <name>John Doe</name>
                </person>
                <person id="asdf">
                        <name>Jane Smith</name>
                        <url>http://www.janesmith.com/</url>
                </person>
        </people>
        
        <!-- John Doe is a contributor to the feed -->
        <contributor ref="qwerty" />

        <entry>
                <!-- John Doe is the author of this entry -->
                <author ref="qwerty" />
        </entry>

        <entry>
                <author>
                        <name>Sylvester McMonkey McBean</name>
                </author>
                <!-- Jane Smith is a contributor to this entry -->
                <contributor ref="asdf" />
        </entry>

        <entry>
                <!-- This entry contains no author or contributor --
                        it does NOT inherit them from feed ->
        </entry>
</feed>

Impacts

Because person constructs could still appear within entries and outside of <people> at the feed level, feed generators are not required to make any changes. Clients would however be required to parse <people> and make the connection between person references and the person constructs defined there.

Notes

[AntoneRoundy] If we really want to create conceptual separation between the Persons' metadata and entries, we could require that all Person constructs be specified inside <people> and be referenced from within entries.

[AntoneRoundy] <people> could be removed from this proposal since there will be no confusion between <person> elements and other Person constructs.

Position Statements

This is not a place for discussion. If making a statement beyond simply listing your name, please be extremely brief. Link to a longer message in the mail list archive if needed.

Pro

Con


CategoryProposals