Defines a constrained class of extension that can be modelled without knowledge of their exact specification.
This defines the relationship between extensions and core constructs, which may also provide a basis for specifications to map Atom to models and languages such as RDF and UML.
It moves Atom closer to feature-parity with RSS 1.0, without complicating the core syntax.
Atom provides a clear definition of its core elements that should enable a mapping from Atom syntax to a model such as RDF to be specified. However, extensions are currently only defined in terms of an unrestricted XML syntax, rather than as entities that can be usefully modelled.
Many extensions for existing flavours of RSS are simple elements with textual content denoting a property of the <item>. It would be useful to provide Atom with a built-in interpretation of this simple class of property.
This interpretation makes many terms defined in existing vocabularies available for use as Atom extensions.
The PRISM metadata vocabulary 1 is one such vocabulary, used by Nature to add detailed metadata specific to publishing.
Atom is a mark-up language for feeds, not a general-purpose knowledge representation format, so extension authors should not be restricted to a constrained syntax.
This proposal provides a compromise between a constrained model and mark-up flexibility, by defining two classes of extension.
In Section 3.2, replace the paragraph:
Person constructs MAY be extended by namespace-qualified element children.
Person constructs MAY contain Extension constructs. Extension constructs used in this context should be interpreted as having the containing person as their Subject.
In Section 4.2, replace the paragraph:
The atom:head element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. This specification assigns no significance to the order of appearance of the child elements of atom:head.
The atom:head element MAY contain Extension constructs. Extension constructs used in this context should be interpreted as having the feed as their Subject.
In Section 5, replace the paragraph:
The atom:entry element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. This specification assigns no significance to the order of appearance of the child elements of atom:entry.
The atom:entry element MAY contain Extension constructs. Extension constructs used in this context should be interpreted as having the entry as their Subject.
Add Section 3.8:
3.8 Extension constructs An Extension construct is a namespace-qualified element and its content. The element MUST be defined outside of the Atom namespace. An Extension construct defines properties of its Subject that are not supported natively by the core Atom specification. There are two classes of Extension construct: Simple Extension constructs, and Structured Extension constructs: 3.8.1 Simple Extension constructs A Simple Extension construct MUST NOT have any attributes or child elements. The element MAY contain either character data, or be empty. The construct can be interpreted as a simple property of its Subject. The pair consisting of the namespace-URI of the element and the local name of the element can be interpreted as the name of the property. The character data content of the element can be interpreted as the value of the property. If the element is empty, then the property value can be interpreted as an empty string. 3.8.2 Structured Extension constructs The root element of a Structured Extension construct MUST have at least one attribute or child element. It MAY have attributes, it MAY contain well-formed XML content (including character data), or it MAY be empty. The structure of a Structured Extension construct, including the order of its child elements MAY be significant, so it MUST be preserved by processors. This specification does not provide an interpretation of a Structured Extension construct. The syntax of the XML contained in the construct, and an interpretation of how the construct relates to its Subject is defined by the specification of the Atom extension.
Add Section 9.1:
9.1 Requirements for Extension constructs The meaning of an Extension construct MUST NOT depend on the presence or absence of another Extension construct or core element. The presence of an Extension construct MUST NOT redefine the meaning of another Extension construct or core element. The meaning of a Simple Extension construct MAY be specified by a compatible vocabulary. A compatible vocabulary MUST use languages capable of interpreting a (namespaceUri, localName) pair as a property name. The specification of a Structured Extension construct MUST require at least one required attribute or one required child element to distinguish it from a Simple Extension construct.
Does not change, or restrict the future growth of the core Atom syntax.
Defines a new optional attribute for extension constructs.
This proposal is based on draft-ietf-atompub-format-04.txt.
PacePropertyDesign also defines classes of element so that they can be interpreted as RDF, but this proposal does not attempt to define a model for interpreting core elements. Core elements are well enough defined that a separate Internet Draft should be able to define a mapping to RDF, even if the mapping from the syntax to the model is not particularly uniform.
PacePropertyDesign models the contents of extension elements as a literal XML string. While this is a comprehensive approach, it forms islands of XML which are opaque to RDF processors. This proposal prefers to allow the extension author to define a more usable mapping.
The Atom RDF mapping specification may choose to define a mapping profile which preserves unknown Structured Extension constructs for when round-tripping is important, but that need not be defined here.
Incorporated suggestions from AntoneRoundy: Clarify that Structured Extension constructs can be empty.
Incorporated suggestions from SamRuby: Replace atom:notation="structured" with a requirement for Structured Extension constructs to contain a minimum of one attribute or child element.
Incorporated suggestions from RobertSayre: Sections 9.1.1 and 9.1.2 are unnecessary.
Incorporated suggestions from Graham: Re-word use of "tuple"; Re-word use of "unstructured text".
- 1 http://www.prismstandard.org/