hAtom issues

Jump to: navigation, search

These are externally raised issues about hAtom with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read the hAtom FAQ and the hAtom resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek


closed issues

See: hatom-issues-closed

resolved issues

See: hatom-issues-resolved


Please add new issues to the bottom of the list by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.


No defined parsing rule for updated timestamps in inselements

open issue! 2010-03-20 raised by Singpolyma

  • Should we talk about parsing of <time> element?. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it.
    • Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. TobyInk 23:00, 21 March 2010 (UTC)


too many required hentry properties

entry-title optionality

updated optionality

author optionality


add url property to hentry

misuse of address element


marking up comments

atom:category scheme



Relationship of rel-bookmark to url+uid

The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of uid-brainstorming indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

Datetime format (atom:updated and atom:published)

Feed id (atom:id)

It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.

Feed permalink (atom:permalink)

Feed updated (atom:updated)

Feed title (atom:title)

Feed author and Entry author (atom:author)

Entry id (atom:id)


author as an hcard is too much to require

The following 3 items were extracted from the conversation starting on irc with logs available starting around here

Entry source (atom:source)

Other Questions and Issues

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

Entry Updated Required? -- Blogger Issue

moved to hatom-brainstorming

'MAY have multiple Feed elements' -- details and viability of multiple feeds

moved to hatom-brainstorming

pre 0.1 issues

This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section

See: hatom-issues-pre-0.1


Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2

See Also

hAtom issues was last modified: Sunday, August 25th, 2013