(Difference between revisions)

Jump to: navigation, search
(title already defined by hCard)
(Entry Title (atom:title))
Line 58: Line 58:
* <code>class="subject"</code> (RFC822)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 Tantek
: +1 BenjaminCarlyle
: +1 BenjaminCarlyle
: +1 KevinMarks
* <code>class="fn"</code> hReview item consistency
* <code>class="fn"</code> hReview item consistency

Revision as of 10:12, 6 January 2006


Discussion Participants




Questions or comments about hAtom go here. Please add your name to the Contributors section above.

Goals for hAtom

  1. to provide a blog-post microformat, based on how people actually produce weblogs
  2. based on (1), use Atom as it provides the most suitable data model for doing so
  3. based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
  4. provide a baseline envelope format for similar {title|link|content|summary} web pages

Anti-Goals for hAtom

  1. Not to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave identically to what they before hAtom was applied.

New Nomenclature

David Janes added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

How to use this. If you like a particular use, place something like ': +1 YourName' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

Feed (atom:feed)

+1 DavidJanes
+1 Tantek
+1 BenjaminCarlyle
+1 MarkRickerby


Entry (atom:entry)

+1 MarkRickerby
+1 DavidJanes
+1 Tantek
+1 BenjaminCarlyle


Entry Title (atom:title)

-1 KevinMarks (clashes with atom)
+1 Tantek
+1 BenjaminCarlyle
+1 KevinMarks


BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

Entry Content (atom:content)

+1 Tantek
+1 DavidJanes


It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our naming-principles, lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

Entry Summary (atom:summary)

+1 Tantek
+1 BenjaminCarlyle


Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com describes summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt.

Entry Permalink (atom:link)

+2 DavidJanes
+1 Tantek
+1 BenjaminCarlyle


BenjaminCarlyle: No real contraversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.

Entry Published (atom:published)

+1 Tantek


BenjaminCarlyle: I would still like to see a clear engagement with last-modified before voting on this one.

Entry Updated (atom:updated)

+1 Tantek


BenjaminCarlyle: I would still like to see a clear engagement with last-modified before voting on this one.

Entry Author (atom:author)

+1 Tantek


BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

Entry Contributor (atom:author)

-1 Tantek - recommend postpone from hAtom first version, since the 80% case does not need "contributor". We can always add it later if we need it.


Questions and Comments


There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added. -- singpolyma 03:35, 3 Jan 2006 (PST)


Note: microformats naming-principles include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in hCard.

Why atomentry?

class="atomentry" (or rather, "atom-entry")
Why not simply "entry"? The parallel to Atom is clear, but in the

context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point. -- DannyAyers

I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. Dr. Ernie 16:59, 25 Oct 2005 (PDT)
DannyAyers My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

STATUS - RESOLVED. We're going with "entry".

Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an hCalendar event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:

Why atomfeed?

class="atomfeed" (or rather, "atom-entry")
As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?

-- DannyAyers

This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. Dr. Ernie 16:59, 25 Oct 2005 (PDT)
Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct. - Tantek
The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again) -- DannyAyers
I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- David Janes
Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics". - Tantek

STATUS - PARTIALLY RESOLVED. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:

Why rel="link" ?

I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the w3c list of rel's, so there is an Occam's Razor case for using this. KevinMarks

STATUS - RESOLVED. We are using rel="bookmark".

title already defined by hCard

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

summary already defined and used by vCalendar/iCalendar/hCalendar/hReview

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

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:

Why content?

The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

Date and time names alternatives

Relationship to hReview definitions needs clarification

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:

"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.

- Tantek


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

STATUS - OPEN. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, hReview 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and feedback. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<div class="author">bonehead</div>

has an assumed defined mapping to

<div class="author vcard"><span class="fn">bonehead</div></div>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.


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

STATUS - RESOLVED. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

See the mfo-examples document, and add further thoughts on this matter there. -- Tantek

Opaqueness of summary and content

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 t new hosting arragements 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?

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <a href="http://apple.com/ipod" rel="tag">iPod</a>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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.


Does this specification depend on acceptance of a hAtom-compatible last-modified?

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.

See Also

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