hAtom issues

(Difference between revisions)

Jump to: navigation, search
(Geo: Supporting 'geo' in hAtom 0.2.)
(Added issue looking for explicit support for <ins> and <del> `datetime` markup for the `updated` properties.)
Line 14: Line 14:
== issues ==
== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[#Template|Template]].  Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues.  Duplicate issue additions will be reverted.
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[#Template|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 <code>updated</code> timestamps in <code>ins</code>elements ====
* {{OpenIssue}} 2010-01-20 raised by [[User:BenWard|BenWard]]
*# hAtom includes the <code>updated</code> property for the last modification/revision date of an entry. HTML already has an <code>ins</code> element for marking up inserted changes to text, and that element has a <code>datetime</code> attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that <code>datetime</code> attribute, but the document semantics suggest it would be an appropriate source for the <code>updated</code> property. Example: <http://blog.benward.me/post/250674456>
*#* Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.
*#* Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.

Revision as of 08:46, 21 January 2010

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


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: Wednesday, December 31st, 1969