Subject: New: PaceProfileAttribute

From: James M Snell <[email-masked]>
Date: Sat, 05 Feb 2005 15:53:59 -0800

This is a modified version of Mark Nottingham's initial idea that 
reflects my thinking on the subject as developed through the mailing 
list discussion.  I posted it as PaceProfileAttribute as opposed to 
Mark's initial PaceProfile in case he wanted to go ahead and attempt to 
submit his original idea under the PaceProfile name.

== Abstract ==

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.

== Status ==

Proposed.

== Rationale ==

(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.

== Proposal ==

  * replace the @version attribute on the atom:feed element with a 
@profile attribute on both the atom:feed and atom:entry elements

4.1.1 The "profile" Attribute

atom:feed and atom:entry elements MAY have a "profile" attribute whose 
value is a list of names or 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 references 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 "http://www.iana.org/assignments/atom/profiles".

The value of "profile" helps consumers process the entry/feed by 
identifying which metadata elements are required in the item.  That 
said, the identification of profiles is intended to be informational 
only and does not impose any behavioral requirements on implementations.

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.  An entry 
or feed element that adheres to multiple profiles SHOULD specify each 
applied profile in the "profile" attribute.

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.

  * atom:feed elements MUST contain exactly one atom:title element
  * atom:feed elements MUST contain at least one atom:link element with 
a rel attribute value of "alternate"
  * atom:feed elements MUST NOT contain more than one atom:link element 
with a rel attribute value of "alternate" that has the same type 
attribute value.  If a feed's atom:link element with type="alternate" 
resolves to an HTML document, then that document SHOULD have a 
autodiscovery link element [Atom-autodiscovery] that reflects back to 
the feed.  atom:head elements MAY contain additional atom:link elements 
beyond those described above.
  * atom:feed elements MUST contain exactly one atom:author element, 
UNLESS all of the atom:feed element's child atom:entry elements contain 
an atom:author element.  atom:head elements MUST NOT contain more than 
one atom:author element.  [[inheritance]]
  * atom:feed elements MUST NOT contain more than one an 
atom:contributor element.
  * atom:feed elements MUST NOT contain more than one an atom:copyright 
element.
  * atom:feed elements MUST NOT contain more than one an atom:id element.
  * atom:feed elements MUST contain exactly one atom:updated element.
  * atom:feed elements MAY contain any number of atom:category elements.
  * atom:feed elements MUST NOT contain more than one atom:post element.
  * atom:feed elements MUST NOT contain more than one atom:introspection 
element.
  * atom:feed elements MUST NOT contain more than one atom:tagline element.
  * atom:feed elements MUST NOT contain more than one atom:generator 
element.
  * atom:feed elements MUST NOT contain more than one atom:info element.
  * atom:feed elements MAY contain any number of atom:enty elements.

6.1.2 Requirements for atom:entry

  * atom:entry elements MUST have exactly one "atom:title" element.
  * atom:entry elements MUST contain exactly one atom:id element.
  * atom:entry elements that contain no child atom:content element MUST 
contain at least one atom:link element with a rel attribute value of 
"alternate".  atom:entry elements MUST NOT contain more than one 
atom:link element with a rel attribute value of "alternate" that has the 
same type attribute value.  atom:entry elements MAY contain additional 
atom:link elements beyond those described above.
  * atom:entry elements MUST contain exactly one atom:updated element.
  * atom:entry elements MUST NOT contain more than one atom:published 
element.
  * atom:entry elements MUST contain exactly one atom:author element, 
unless, in an Atom Feed Document, the atom:feed element contains an 
atom:author element itself.  atom:entry elements MUST NOT contain more 
than one atom:author element.
  * atom:entry elements MUST NOT contain more than one atom:contributor 
element.
  * atom:entry elements MUST NOT contain more than one atom:host element.
  * atom:entry elements MUST NOT contain more than one atom:copyright 
element.
  * atom:entry elements MAY contain any number of atom:category elements.
  * atom:entry elements MUST contain an atom:summary element in any of 
the following cases:
    *  the atom:entry element contains no atom:content element.
    *  the atom:entry contains an atom:content which has a "src" 
attribute (and is thus empty).
    *  the atom:entry contains content which is encoded in Base64; i.e. 
  the "type" attribute of atom:content is a MIME media type [RFC2045] 
and does not begin with "text/" nor end with "+xml".
  * atom:entry elements MUST NOT contain more than one atom:summary element.
  * atom:entry elements MUST NOT contain more than one atom:edit element.

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

== Impacts ==

  * Replaces @version
  * Requires some reorganization of the spec. Specifically, the pieces 
that define which metadata elements must be included in both the feed 
and entry elements would be moved to the section that defines the Atom 
Core Profile.
  * Allows other profiles to the developed that may or may not be 
compatible with the core.  For interoperability sake, strongly 
recommends that new profiles that happened to be developed be created so 
that they are compatible with the core.
  * Requires the creation of a IANA Registry for Atom Profiles that 
operates in similar fashion to the registry of link relations.

== Notes ==

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

----

CategoryProposals

-- 
- James M Snell

---

From: Eric Scheid <[email-masked]>
Date: Sun, 06 Feb 2005 15:11:49 +1100

> name to the string "http://www.iana.org/assignments/atom/profiles".

suggestion:

    s/a list/a space delimited list/

otherwise this might be legal (but ambiguously parseable):

    profile="feed:archive:http://www.example.com/"

also, might we need to make clear that the URI must not be a relative uri?

e.