Revision as of 17:42, 31 December 2006 by ComputerKid (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)

Jump to: navigation, search


hAtom 0.2

This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.


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.

Feed XXX (atom:xxx)

Template section: if there is something clearly from an Atom Feed that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

Datetime format (atom:updated and atom:published)

2006-05-23 raised by Robert Bachmann

Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.

Feed id (atom:id)

2006-04-01 raised by Robert Bachmann

atom:id is required for atom:feed. Thus it should be available in hAtom to. The Feed permalink should be used as the feed ID.

2006-12-31 response by Emanla Eraton

No, it shouldn't be a permalink. It should be a "tag:" ID for entries.

Feed permalink (atom:permalink)

2006-04-01 raised by Robert Bachmann

I'm proposing the following rules:

* feed level = inside a Feed element but not inside an Entry element

2006-04-03 ChrisCasciano - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.

2006-04-03 Robert Bachmann: I've replaced "SHOULD" with "MAY".
2006-04-24 Robert Bachmann: Maybe we could simplify my proposal to:
"Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI"
IMO this would be good enough for at least 80% of the cases.

Feed updated (atom:updated)

2006-04-01 raised by Robert Bachmann

atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:


$a = array();
for each $entry in $feed {
    if ($entry.updated)
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];

* feed level = inside a Feed element but not inside an Entry element

Feed title (atom:title)

2006-04-01 raised by Robert Bachmann

atom:title is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

2006-04-05 Robert Bachmann: Okay. Deleted "the first <h#> element in the Feed, or"
2006-04-12 User:DavidJanes Note also in support of this decision that many blogs use <h#> to encode the date for a group of postings
2006-04-12 Robert Bachmann: Sorry, this was a "copy & paste" mistake. Fixed now.

Feed author and Entry author (atom:author)

2006-04-01 raised by Robert Bachmann

I'm proposing the following rules for Feed author:

I'm proposing the following rules for entry author:

* feed level = inside a Feed element but not inside an Entry element

2006-04-17 Robert Bachmann: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

Entry XXX (atom:xxx)

Template section: if there is something clearly from an Atom Entry that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

Entry id (atom:id)

2006-04-01 raised by Robert Bachmann

atom:id is required for atom:entry. Thus it should be available in hAtom to.

The Entry permalink should be used as the entry 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

Other Questions and Issues

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

Entry Updated Required? -- Blogger Issue

The hAtom 0.1 spec states if there is no Entry Updated element...the page is invalid hAtom I have a real problem with this because I work with Blogger, where we cannot output datetime-design-pattern-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? -- singpolyma 05:45, 28 Mar 2006 (PST)

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

The hAtom 0.1 spec states the follwing two items about the Feed element:

  1. the Feed element is optional and, if missing, is assumed to be the page
  2. hAtom documents MAY have multiple Feed elements

I'm concerned about the implementation details of multiple feeds and that the current 0.1 spec isn't sufficient to define multiple distinct feeds in a single html document and that even if some of those areas were modified if there are real mechanisms out there to support a document with multiple feeds.

To provide examples of how multiple feeds might reside in a document under hAtom 0.1 I've created this collection of hAtom multiple feed tests

Some of the questions that need to be answered (more details and some conclusions at a later time):

  1. Can a unique reference be made to each feed? Are there ambiguous references?
  2. Can a unique label or feed name be generated from each feed for the purpose of selection by the subscriber?
    • Using the feed title seems to be an option. It is likely (thought not guaranteed) that it is unique.
  3. What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
    • Robert Bachmann (2006-05-23): IMO the simplest soultion would be to require that each feed element MUST have an XHTML id attribute.
  4. What rules are needed for the detection, selection and consumption of feed documents so that people can select and maintain a subscription to the proper feed?
  5. How should a consuming application deal with potential changes to feeds found in a document over time (either id changes, additional feeds added, removal of feed, etc)? (this issue could be generalized to single feed documents as well)
  6. Chris Casciano (2006-07-24): A good chat session on this issue can be found here

Draft Rules for multiple feeds

(2006-07-24): Written by Chris Casciano

Discussion of Draft Rules

hAtom 0.1

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

This page documents the issues that have been raised regarding the hAtom draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).


Feed (atom:feed)

RyanKing: STATUS: RESOLVED - 'hfeed' and not required (a la hcalendar)

Initial proposal

atomfeed (or rather, "atom-entry")


The above proposal was not fully accepted and some other possibilities were proposed:


The feed is a root class name of hAtom, similar to "vcalendar" in hCalendar, thus it should be fairly unique, per the root class name naming-principles. - Tantek

Entry (atom:entry)

RyanKing: STATUS - RESOLVED - 'hentry'

Initial Proposal

atomentry (or rather, "atom-entry")


The above proposal was not fully accepted. Other alternatives:


Entry Title (atom:title)

RyanKing: STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content'


The title class is defined by hCard to mean "job title". Possible alternatives include (Please add to list):


Entry Content (atom:content)

STATUS - RESOLVED going with entry-content


Entry Summary (atom:summary)

STATUS - RESOLVED - going with 'entry-summary'

The summary class is defined by vCalendar, iCalendar, hCalendar, and also hReview, to mean "summary or title". Possible alternatives include (add to list):


Entry Permalink (atom:link)

STATUS - RESOLVED - 'bookmark'


Entry Published (atom:published)


Entry Updated (atom:updated)

STATUS - RESOLVED - 'updated'


go back throught blog-post-examples to see what conventions we have.

Entry Author (atom:author)

STATUS - RESOLVED - 'author' required, should use <address>


Entry Contributor (atom:contributor)


Entry Geo (geo:Point)

GeoRSS Resources

Questions and Comments


Relationship to hReview definitions needs clarification

[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

Tantek: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.


DavidJanes: Should hCards be required for the <address> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.


This seems precisely analogous to S5:

I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--Ernie Prabhakar

Repeated Elements

We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See here, here, here and here.

Your thoughts please... -- David Janes

STATUS - RESOLVED. The spec has explicit rules for disambiguating all these items if they appear multiple times.


If you have concerns about opaqueness, that is, stopping interpretation below certain hAtom elements, raise them here.

Opaqueness of other microformat elements

How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise, Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- BenjaminCarlyle

Opaqueness of summary and content

DavidJanes?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. last-modified-brainstorming introduces an idea of using <ins> and <del> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the mfo proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules: <div class="content"><div class="summary">...</div>...</div>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.


The current spec under Schema:Nomenclature:Entry includes the text: "if practical, also define id="unique-identifier" to the Entry" What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?


HTML Title

Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?


Should hAtom use rel-tag for atom category elements? -- DavidJanes

Excess disambiguation rules?

Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?



Does this specification depend on acceptance of a hAtom-compatible mfo? See mfo-examples.

Is atom:content necessary?

Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

Published as default value for atom:updated

It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:

  1. If multiple updated fields exist, choose the most recent one.
  2. If only one updated field exists, choose that value.
  3. If no updated field exists but a published field exists, use the published value for atom:updated.
+ 1 Robert Bachmann

Designating the page author

(2006-02-07 raised by Robert Bachmann)

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

(2006-02-13 example by Chris Casciano) There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.


Entry Updated Required? -- Blogger

See Also


Please use this format (copy and paste this to the end of the list to add your issues):

hatom-issues was last modified: Wednesday, December 31st, 1969