Jump to: navigation, search


hAtom 0.2

Cette section est destinées à discuter de ce que vous aimeriez voir dans la prochaine version de hAtom, c'est à dire 0.2.


Relation de rel-bookmark vers url+uid

Le concept de permalien est disponible dans hCard et hCalendar sous les classes url et uid. Cette combinaison fait correspondre la sémantique du permalien en indiquant que l'url devrait être déréréférencée pour trouver une version dynamique ou mise à jour du contenu, et que cette url est un id unique stable qui peut être utilisé pour identifier le contenu.

hAtom 0.1 utilise rel-bookmark pour le concept du permalien. L'état actuel du uid-brainstorming-fr indique que le concept permalien hCard et hCalendar doit être probablement utilisé dans les microformats subséquents. Ce peut être important de réconcilier hAtom avec cette trajectoire. Les réconciliations possibles comprennent :

1) Laisser les choses telles qu'elles sont. Les deux concepts des permaliens doivent être maintenus séparés.

2) Traiter les deux concepts comme équivalents. Permettre les deux dans hAtom et considérer permettre les deux dans d'autres formats. Par ex <a rel="bookmark" href="http://example.com/"> trouvera les valeurs uid et url si elles ne sont pas fournies explicitement.

3) Choisir l'un sur l'autre pour hAtom et peut être aussi pour les futurs microformats. "url uid" permet quelque plus grande liberté (l'uid peut être pointé comme un uid non url), mais ce n'est pas clair à cette étape si cette liberté est garanties ou recommandable à autoriser.

Fil XXX (atom:xxx)

section Gabarit : s'il y a quelque chose provenant clairement d'un Fil Atom que vous aimeriez dans hAtom 0.2, utilisez cette section comme un gabarit et répliquez là ici au bon endroit. Voir la section hAtom en dessous pour plus de détails.

Format Datetime (atom:updated et atom:published)

2006-05-23 soulevée Robert Bachmann

Atom exige l'utilisation de datetimes RFC3339 alors qu'hAtom 0.1 ne spécifie pas quels formats datetimes peuvent être utilisés.

Fil id (atom:id)

2006-04-01 soulevée par Robert Bachmann

atom:id est requis pour atom:feed. De ce fait ce devrait être disponibles aussi dans hAtom. Le permalien Feed devrait être utilisé comme le feed id.

Feed permalink (atom:permalink)

2006-04-01 soulevée Robert Bachmann

Je propose les règles suivantes :

* 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 soulevé 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 souvlevée par 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 et Entrée author (atom:author)

2006-04-01 soulevée par 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"

Entrée 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.

Entrée id (atom:id)

2006-04-01 soulevée par Robert Bachmann

atom:id est requis pour atom:entry. De ce fait il devrait être dipsonible aussi dans hATom.

L'Entrée permalien devrait être utilisée comme l'id d'entrée.

2006-12-31 réponse par Emanla Eraton Non, ce ne devrait pas être un permalien. Ce devrait être un "tag:" id pour les entrées.


author en tant que hCard est bien trop comme exigence

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

Autres Questions et Problématiques

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

Entry Updated Exigée ? -- Problématique de Blogger

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

Règles Brouillons pour plusieurs fils

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

Discussion de Règles Brouillons

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)

Proposition Initiale

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'

Proposition Initiale

atomentry (or rather, "atom-entry")


The above proposal was not fully accepted. Other alternatives:


Entrée Titre (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)

Ressources GeoRSS

Questions et Commentaires


Les relations vers les définitions hReview ont besoin de 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

Eléments répétés

Nous permettons à certains éléments d'être répétés, comme un Permalien d'Entrée, l'Entrée Publiée et le Titre de l'Entreée, même s'il peut y avoir au plus une valeur réelle. Nous fournissons des règles de "désambiguation" pour trouver quelle est la vraie valeur. Voir ici, ici, ici et ici.

Vos idées, svp... -- David Janes

STATUT - RESOU. La spec a des règles explicites de désambiguation pour tous ces items s'ils apparaissent plusieurs fois.


Si vous avez des soucis à propos de l'opacité, ce qui veut dire arrêter l'interprétation en dessous de certains éléments hAtom, soulevez-les là.

Opacité des autres éléments microformat

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

Opacité du résumé et du contenu

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

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

Désigner l'auteur de la page

(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 Obligé ? -- Blogger

See Also


SVP utilisez ce format (copiez et coller ça à la fin de la liste pour ajouter vos problématiques) :

hatom-issues-fr was last modified: Tuesday, May 1st, 2007