hatom-issues-fr

(Difference between revisions)

Jump to: navigation, search
m
m (à synchroniser et traduire)
Line 3: Line 3:
= hAtom 0.2 =
= hAtom 0.2 =
-
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 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.
 +
 
 +
==Geo==
 +
*2006-02-03 soulevée par Brian
 +
*# Nous pouvons utiliser le microformat [[geo-fr|geo]] dans [[hatom-fr|hAtom]] pour représenter un élément GeoRSS
 +
 
== Relation de rel-bookmark vers url+uid ==
== Relation de rel-bookmark vers 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.
+
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 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:
+
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) To leave things as they are. The two permalink concepts are to be kept separate.
+
1) Laisser les choses telles qu'elles sont. Les deux concepts des permaliens doivent être maintenus séparés.
-
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.
+
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) 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.
+
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.
-
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==
+
== Fil <i>XXX</i> (atom:<i>xxx</i>) ==
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.
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.
Line 105: Line 110:
: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
 +
 +
2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.
== Feed <i>author</i> et Entrée author (atom:<i>author</i>) ==
== Feed <i>author</i> et Entrée author (atom:<i>author</i>) ==
Line 511: Line 518:
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.
-
=== GeoRSS Ressources ===
+
=== Ressources GeoRSS  ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]
Line 517: Line 524:
== Questions et Commentaires ==
== Questions et Commentaires ==
-
=== Limitations ===
+
=== Limites===
* 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.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
* 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.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
Line 561: Line 568:
* [[Tantek]]: 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]]: 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.
-
=== Repeated Elements ===
+
=== Eléments répétés===
-
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 [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].
+
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 [[hatom-fr#Nesting_Rules|ici]], [[hatom-fr#Entrée_Title|ici]], [[hatom-fr#Entrée_Permalink|ici]] et [[hatom#Entrée_Publiée|ici]].
-
Your thoughts please... -- [[User:DavidJanes|David Janes]]
+
Vos idées, svp... -- [[User:DavidJanes|David Janes]]
-
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.
+
'''STATUT - RESOU'''. La spec a des règles explicites de désambiguation pour tous ces items s'ils apparaissent plusieurs fois.
=== Opacité ===
=== Opacité ===
-
If you have concerns about [[hatom#hAtom_Opaque-fr|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.
+
Si vous avez des soucis à propos de l'[[hatom-fr#hAtom_Opaque-fr|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 ====
==== Opacité des autres éléments microformat ====
Line 582: Line 589:
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.
-
==== Opaqueness of summary and content ====
+
==== 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 <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> 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.
[[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 <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> 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.
Line 655: Line 662:
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.
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.
-
==== Proposal ====
+
==== Proposition ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.
Line 664: Line 671:
= See Also =
= See Also =
-
* [[hatom-fr|hAtom]] - the draft proposal
+
* [[hatom-fr|hAtom]] - la proposition draft
-
* [[hatom-faq-fr]] - knowledge base
+
* [[hatom-faq-fr|hAtom-faq]] - base de connaissance
-
* [[blog-post-brainstorming-fr]]
+
* [[blog-post-brainstorming-fr|billets de blogs-brainstorming]]
-
* [[blog-post-formats-fr]]
+
* [[blog-post-formats-fr|billets de blogs-formats]]
-
* [[blog-post-examples-fr]]
+
* [[blog-post-examples-fr|billets de blogs - exemples]]
-
* [[blog-description-format-fr]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
+
* [[blog-description-format-fr]] - comme décrire un blog (à l'opposition des entrées individuelles, ce qui est ce que nous faisons ici)
-
* [[mfo-examples-fr]]
+
* [[mfo-examples-fr|mfo-exemples]]
-
* [[naming-principles-fr]]
+
* [[naming-principles-fr|principes de nommage]]
= Gabarit =
= Gabarit =
-
Please use this format (copy and paste this to the end of the list to add your issues):
+
SVP utilisez ce format (copiez et coller ça à la fin de la liste pour ajouter vos problématiques) :
-
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
+
* AAAA-MM-JJ soulevé par [http://votrepageperso.exemple.com VOTRENOM].
-
*# ''Issue 1: Here is the first issue I have.''
+
*# ''Problématique 1 : Voici la première problématique que je rencontre.''
-
*# ''Issue 2: Here is the second issue I have.''
+
*# ''Problématique 2 : Voici la seconde problématique que je rencontre.''

Revision as of 16:44, 27 February 2007

Contents


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.

Geo


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)

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.

Format Datetime (atom:updated et 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.

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:

Algorithm:

$a = array();
for each $entry in $feed {
    if ($entry.updated)
      $a.add(pad_datetime($entry.updated))
    else
      $a.add(pad_datetime($entry.published))
  }
$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.
2007-02-26 Mike Kaply: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

Feed author et Entrée 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"

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

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


Contributeurs

Feed (atom:feed)

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

Proposition Initiale

atomfeed (or rather, "atom-entry")

Alternatives

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

Discussion

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

Alternatives

The above proposal was not fully accepted. Other alternatives:

Discussion

Entrée Titre (atom:title)

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

propositions

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

Discussion

Entry Content (atom:content)

STATUS - RESOLVED going with entry-content


Discussion

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):

Discussion

Entry Permalink (atom:link)

STATUS - RESOLVED - 'bookmark'

Discussion

Entry Published (atom:published)

Discussion

Entry Updated (atom:updated)

STATUS - RESOLVED - 'updated'

Discussion

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

Entry Author (atom:author)

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

Discussion

Entry Contributor (atom:contributor)

Discussion

Entry Geo (geo:Point)

Ressources GeoRSS

Questions et Commentaires

Limites

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.

hCards

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

RESOLVED: MUST use hCard for author.

Comparisons

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.

Opacité

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.

Identification

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?

STATUS - OPEN.

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)?

rel-tag

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?

Dépendances

mfo

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.

Proposition

Entry Updated Obligé ? -- Blogger

See Also

Gabarit

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

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

Views