This is the beginning of an effort to capture the Best Current Practices for Atom.
Ground rules
-
This is a work in progress draft
-
Nothing here should be considered normative.
-
Everything is up for discussion.
Best Practices
-
General
-
By Element
-
atom:feed
-
atom:entry
-
atom:content
-
@src attribute
-
Many feed readers are incapable of preserving the base URI unless xml:base is used. Consider always using absolute IRIs or xml:base
-
atom:author
-
atom:category
-
While the spec allows atom:category to have child text and elements, most feed consumers are incapable doing anything with the extra markup. Child markup should be avoided. See: http://feedvalidator.org/docs/warning/AtomLinkNotEmpty.html
-
atom:contributor
-
atom:generator
-
atom:icon
-
Many feed readers are incapable of preserving the base URI unless xml:base is used. Consider always using absolute IRIs or xml:base
-
atom:id
-
atom:link
-
While the spec allows atom:link to have child text and elements, most feed consumers are incapable doing anything with the extra markup. Child markup should be avoided. See: http://feedvalidator.org/docs/warning/AtomLinkNotEmpty.html
-
Many feed readers are incapable of preserving the base URI unless xml:base is used. Consider always using absolute IRIs or xml:base
-
atom:logo
-
Many feed readers are incapable of preserving the base URI unless xml:base is used. Consider always using absolute IRIs or xml:base
-
atom:published
-
atom:rights
-
atom:source
-
atom:subtitle
-
atom:summary
-
atom:title
-
Many implementations limit atom:title to either plain text or a strict markup subset. Limit (x)html markup in the atom:title to: (TODO: list safe markup subset)
-
atom:updated
-
atom:name
-
atom:uri
-
atom:email
-
Encode and decode non-ASCII characters according to the rules of RFC2822 email headers.
-
When presenting internationalized email addresses to users, be able to show them both the
-
RFC4287 says that email addresses have to conform to the addr-spec production of RFC2822. That production is very complex and it is likely that Atom processors only implement a subset of it; in particular, (nested) comments, (folded) whitespace, domain literals, and the obsolete syntax are unlikely to be supported. When producing Atom documents, use email addresses that conform to the following simplified grammar:
-
encoded and the decoded versions of the address.
simple-addr-spec = simple-local-part "@" simple-domain simple-local-part = dot-atom-text / simple-quoted-string simple-domain = dot-atom-text simple-quoted-string = DQUOTE *(simple-qcontent) DQUOTE simple-qcontent = %d33 / ; US-ASCII not including control %d35-91 / ; characters, space, "\", or %d93-126 ; or the quote character
-
app:edited
-
app:control
-
app:draft
-
By Construct
-
Atom Text Constructs
-
Atom Person Constructs
-
Atom Date Constructs
-
By Link Rel
-
alternate
-
related
-
self
-
Either always use an absolute IRI or always use xml:base. See http://feedvalidator.org/docs/warning/RelativeSelf.html
-
enclosure
-
via
-
edit
-
edit-media
-
first
-
next
-
last
-
previous
-
next-archive
-
prev-archive
-
current
-
license
-
payment
-
By Topic
-
Accessibility
-
Aggregation/Resyndication
-
If an entry being resyndicated uses relative IRIs, in the Atom markup or content, ensure that xml:base is set appropriately on the entry
-
If the entry does not contain an atom:source element, add one
-
Preserve all rights and license information in the entry
-
Archiving
-
Use RFC 5005
-
Use the <fh:archive> element
-
Use links with rel="prev-archive" or rel="next-archive" as appropriate. Alternately, if this feed is meant to be complete, consider adding an <fh:complete> element.
-
Authentication
-
Binary Content
-
Categorization
-
Charsets
-
Digital Signatures
-
Duplicate Detection
-
Encryption
-
Extensions
-
Elements and Attributes
-
Link Relations
-
Feed Readers
-
Most feed clients prefer to associate the first (or last) 'alternate' link with atom:title for display purpose. See a survey
-
HTTP (conditionals, compression, etc)
-
Use Gzip compression
-
Use Etags and support conditional requests. If you can't use Etags, use Last-Modified
-
Internationalization
-
Bidi characters
-
When using (x)html in text constructs or content, use the appropriate bidi markup; avoid using the unicode bidi control codes in markup.
-
IRIs
-
Namespaces
-
Namespace prefix declarations for atom and xhtml haven't proven to be very interoperable in the context of an Atom document. Avoid declaring prefixes for the atom and xhtml namespaces. See http://feedvalidator.org/docs/warning/AvoidNamespacePrefix.html
-
Paging
-
Use RFC 5005
-
Rights and Licensing
-
See RFC 4946 (currently experimental)
-
Sanitization
-
(X)HTML markup contained in text constructs and content should be limited to a subset of elements, attributes, and styles that are known to be safe. See http://wiki.whatwg.org/wiki/Sanitization_rules
-
Subscription
-
The "self" link should either be an absolute IRI or xml:base should be used.
-
Synchronization
-
Textual Content
-
Threading
-
Use RFC 4685