Current Spec : http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
Purpose of this Page To simplify cross-refencing between the format specification, AtomIssues, relevant Wiki pages, archived mailing list posts and other resources. Please limit entries to links.
AnswerMe: would it help if the text of the spec was pasted in here (properly interleaving the notes so far)? -- I considered that, but decided that including links-only would be easier to maintain across later versions of the specs. I don't know if that was the right decision...
[AsbjornUlsberg] I would like to have the full text in here.
-
[RandyCharlesMorin] +1
Introduction
-
is this the place to talk about requirements inherited from XML ?
-
is this the place to define an Atom Processor, the context for Atom error handling?
-
PaceNoInfoSet - Remove all references to the InfoSet from The Atom Syndication Format 0.3.
Example
Conformance
Notational Conventions
Atom Documents
-
PaceNoInfoSet - Remove all references to the InfoSet from The Atom Syndication Format 0.3.
-
Multiple document elements? (feed, entry, introspection)
Common Atom Constructs
-
these enumarated values for @mode were discussed at length, with (IIRC) mode='escaped' renamed to mode='text'
-
references?
-
discussion of default value if omitted, change from assume mode="xml" to one which is driven by @type
-
references?
-
Re: Example please! (was RE: More on mode=) -- not all content with type="*/xml" is valid XML 1.0 ... it could be valid XML 1.1 which is not backwards compatible
-
mode='escaped' or mode='text'?: might be worth noting that XML 1.0 does not permit most control characters, not even escaped as &x01;, and similarly worth noting that some "text" content may contain form-feed control codes (not allowed in XML 1.0, not even if escaped). Such "text" content would need to be base64 encoded.
-
replace atom:url with zero or more <link> elements with appropriate @rel and @type values (eg. bio, blog, FOAF, vCard, IM)
-
relax the requirement "MUST be one of the values enumerated in the Atom API specification"
-
references?
-
if enumeration requirement relaxed, specify that the relationship terms as specified in the Atom API specification will have the meanings as specified there (ie. not available for co-opting)
-
if the feed is accessible via an URL, propose requiring a link with rel='service.feed' and href='[URL to subscribe to this feed]'
-
for non-renewing feeds (eg. all entries for a month archived to a static file), have another relationship distinct from where to subscribe to for updates to the feed
Content Constructs
"type" Attribute
"mode" Attribute
Person Constructs
"atom:name" Element
"atom:url" Element
"atom:email" Element
Date Constructs
Link Constructs
"rel" Attribute
"type" Attribute
"href" Attribute
"title" Attribute
The "atom:feed" Element
-
new optional element of feed:issued? This would be a date construct reflecting when the feed was published, even if there are no modifications in this particular issue (ie. feed.modified would be the same)
-
@type MUST NOT be "multipart/alternative"
-
replace the word "content" with "attribute values".
-
should the feed:author element also be considered the maintainer of the feed, or should this element only be used as a way setting a default for the feed:items?
-
how to handle a mixture of copyrights in the one feed?
-
copyright for the collection which is the feed is different from copyrights of the items of that feed
-
In absence of a specified timezone, despite "SHOULD", does this mean the timezone must/should/may be assumed to be "Z"
"version" Attribute
"xml:lang" Attribute
"atom:title" Element
"atom:link" Element
The "atom:link" element is a Link construct that conveys a URI associated with the feed. The nature of the relationship as well as the link itself is determined by the element's content.
"atom:author" Element
"atom:contributor" Element
"atom:tagline" Element
"atom:id" Element
"atom:generator" Element
"atom:copyright" Element
"atom:info" Element
"atom:modified" Element
-
encapsulate the list of entries inside another element? this can then be used to contain "entry-default" elements distinct from "feed-specific" elements (eg. copyright)
-
@type MUST NOT be "multipart/alternative" ?
-
how are we to handle multi-lingual postings, where one text/html link points at the lang=EN version, and another points to the lang=FR version?
-
will the spec support hreflang?
-
Adding hreflang to the Autodiscovery spec (was: proposed xml:lang attribute for link elements)
-
HTML Errata: use hreflang with alternate link types (the HTML spec is wrong, it says use "lang" to denote translations)
-
handling alternates for different audiences?
-
globally unique id, or publishing source unique id? the entry <id> should remain the same even if that entry is syndicated into another feed by other publishers. This doesn't stop re-publishers from pointing to a different html representation if they wish (unlike the <guid permalink=true> analog of RSS 2.0).
-
"atom:entry elements MUST have exactly one "atom:id" element." spec draft 03 - is entry:id required?
-
The content of an atom:modified element MUST have a time zone whose value SHOULD be "UTC" -- that should be "Z" (or "+0000" ?)
-
"If any previously published instance of the atom:entry has contained an atom:modified element, all subsequent instances of that entry MUST contain an atom:modified element." RE: PaceEntryDates
-
please clarify what we mean by "issued", especially after a modification occurs. Is it the date/time the original version was published into the feed, or the date/time the current version was published?
-
any semantic meaning implied for future dates?
-
add a note that the value of atom:created SHOULD NOT change
-
The content of an atom:modified element MUST have a time zone whose value SHOULD be "UTC" -- that should be "Z" (or "+0000" ?)
-
Typo
-
atom:entry elements MAY contain an atom:created element, should read atom:entry elements MAY contain an atom:summary element,