Atom's feed <published> date should not have a date older than the <published> field's date

[pascalc]

Steps to reproduce the bug:

1/ syndicate the Atom feed of a tag to some external tool, a planet for example example feed:  http://myblog/?feed/tag/Kittens/atom

2/ On June 1 prepare a blog post with a publication date in the future, let's say June 16 3/ On june 2 update the blog post 4/ Wait June 16

expected result: On June 16 your blog post is published and fetched by the external tool (planet, feed reader)

Actual result: Your blog post does not appear on the planet because the <updated> field is older than the <published> field. At best, you appear in the archives of the planet.

example of generated Atom feed

<published>2011-02-28T10:00:00+01:00</published> <updated>2011-02-25T17:08:12+01:00</updated>

(Note that the rss2 fied does not have this bug, atom and rss2 feeds in Dotclear expose different blog posts dates)

expected behaviour: When the <updated> field is older than the <published> field, it should use the <published> date

I believe this regression was introduced here: http://dev.dotclear.org/2.0/changeset?old_path=%2Ftrunk%2Finc%2Fpublic%2Fdefault-templates%2Fatom.xml&old=3099&new_path=%2Ftrunk%2Finc%2Fpublic%2Fdefault-templates%2Fatom.xml&new=3099

The current workarounf is to add an atom.xml file in your theme tpl folder and remove the upddt="1" attribute from the updated field.

[franck]

Je propose un nouvel attribut sur EntryDate?, PingDate? et CommentDate? (peut-être d'autres ?) nommé "lastdt" et qui fournirait la plus récente de toutes les dates enregistrées.

Un avis ?

[Jean-Michel]

Je ne le trouve pas référencée mais j'avais le souvenir de l'existence d'une balise {{tpl:EntryUpdate}}.

[franck]

En fait Dotclear suit précisément la RFC 4287 à ce sujet :

L'élément atom:published est une structure de date indiquant un instant dans le temps associé à un événement tôt dans le cycle de vie de l'entrée.

atomPublished = element atom:published { atomDateConstruct }

L'élément atom:published sera typiquement associé à la création initiale ou à la première disponibilité de la ressource.

et

L'élément atom:updated est une structure de données indiquant l'instant dans le temps le plus récent où une entrée ou un fil ont été modifiés d'une façon estimée significative par l'éditeur. Toutes les modifications n'aboutissent donc pas nécessairement à une valeur de atom:updated changée.

atomUpdated = element atom:updated { atomDateConstruct }

Les éditeurs PEUVENT changer la valeur de cet élément dans le temps.

En l'espèce ce sont les clients du flux ATOM qui font mal leur boulot.

[pascalc]

Pas d'accord, d'abord, interpréter que la RFC dit que les dates de mises à jour d'un document peuvent être antérieures à sa date de publication c'est idiot. Il est évident que quand dans la RFC on utilise les termes 'updated', 'most recent' et 'was modified', il est implicite que la date de modification du document est postérieure à sa date de publication, c'est quand même pour ça que le premier champ s'appelle atomPublished et le second atomUpdated. Si un billet est modifié avant même d'être publié et donc avant même d'être dans le flux Atom, ça s'appelle une modification de son brouillon, pas une mise à jour(atomUpdated) d'un billet publié (atomPublished).

Je réouvre et je te demanderais si tu décides de refermer ce billet de documenter clairement ta motivation et la position de Dotclear, en particulier par rapport à ces critères :

• en quoi revenir au comportement précédent de Dotclear irait à l'encontre de la RFC. Faire un copier-coller de la traduction de la RFC n'est pas une justification car il n'y a aucun élément dans ton copier-coller qui justifie le comportement de Dotclear par rapport à cette RFC
• en quoi avoir des billets avec des dates de modification antérieures à la date de publication est un bénéfice pour la syndication de contenu et donc un bénéfice pour le rédacteur des billets d'une part et pour les lecteurs d'autre part.

[franck]

Ce que je dis c'est que nulle part dans la RFC n'est fait mention d'une contrainte (supérieur, inférieur, …) d'un élément (updated en l'occurence) par rapport à un autre (published). Chacune des infos est pertinente et indépendante. En cela Dotclear respecte la RFC.

Si Dotclear devait remplacer la valeur de updated par celle de published si celle-ci est postérieure, quel est l'intérêt de conserver updated ?

Maintenant on peut discuter de la façon dont les clients du flux ATOM gèrent ces informations, visiblement pas très bien, est-ce une raison suffisante pour modifier le comportement de Dotclear ?

[pascalc]

Ce n'est pas parce que ce n'est pas mentionné dans la RFC que c'est intelligent à faire. La RFC est écrite en anglais et le terme updated a un sens, si une définition différente du sens commun n'est pas fournie dans la RFC, c'est que c'est le sens commun de updated qui est utilisé et il indique une chronologie par rapport à la date de publication et pas par rapport à la préparation des billets dans l'interface d'admin. Merriam Webster dictionnary : "extending up to the present time : including the latest information"

Et oui, il n'y a pas d'intérêt à conserver updated s'il n'y a pas eu de mise à jour du document publié et c'est bien le cas, mais au moins, s'il avait la même date, il n'y aurait pas de bugs dans les clients externes au flux atom et je pense pas qu'on peut leur reprocher d'interpréter des mal des flux ATOM clairement bancals, poutre, paille tout ça...

[franck]

En effet, tout dépend comment est faire la lecture de la RFC. Personnellement j'y lis deux informations concernant deux processus différents, le premier concernant la modification du contenu (updated), le deuxième concernant la publication d'icelui. Ce sont deux processus qui peuvent complétement déconnecté à mon sens et chacun porteur de sens.

Vais voir ce que je peux faire de plus propre (probablement ne pas indiquer l'élément updated s'il est antérieur à published).

[franck <carnet.franck.paul@…>]

(In [18eae8f3a180]) Add "republished" test attribute for EntryIf? tag and used in atom.xml. May be useful for theme creators in order to add a mention if a post has been modified since his publication. Fixes #1161.