Blog Stéphane Bortzmeyer : RFC 4685 : Atom Threading Extensions

je préconiserais
<content>
<div class="chapo">chapo</div>
<div class="texte">texte</div>
<div class="ps">ps</div>
</content>

ainsi si ton serveur ne connaît pas la subtilité il enregistre toute la structure proprement comme même

Cela se nomme un « extension element ». C’est prévu dans Atom (et AtomPub) depuis le début. L’idée est en effet de mettre ces éléments supplémentaires dans un autre espace de noms. Parmi les exemples, des extensions normalisées dans un RFC comme le 4685 ►http://www.bortzmeyer.org/4685.html

Une bonne explication, avec un exemple simple ("expires"), est donné dans la section « Extending Atom » de ►http://www.ibm.com/developerworks/xml/library/x-atom10/index.html

Un exemple d’une bibliothèque qui les gère est ratom ►http://ratom.rubyforge.org (voir leurs exemples de code)

@stephane merci beaucoup, je lis ça dès que je me suis reposé.

Je tiens à redire que ça serait super cool un service standardisé de « découverte de champs » pour un type de ressource. Genre on envoie une requête au serveur APP : dis moi quels sont les champs à utiliser pour les <entry> de la <collection> « patates ». Et hop ça retourne la liste des champs que le serveur sait gérer. :)
On pourrait faire des clients qui savent alors adapter leurs formulaires (ajouter un champ et son label) dynamiquement !

@fil c’est intéressant du point de vue du client qui envoie vers un serveur « inconnu » et qui voudrait ne rien perdre, mais je me place surtout dans la position inverse du serveur qui aimerait pouvoir dire « moi je sais gérer tel et tel champ en plus du <content> » (géolocalisation, champs de SPIP en plus, etc). Mais apparemment, pour l’instant, on peut juste écrire de la doc pour décrire les spécificités d’un serveur.

Intéressant. Ce qui me fait tiquer, c’est que sur Seenthis, en plus du « feed » de news, on a une information structurée sous forme d’un forum associé.

La RFC 4685 propose une extension du format ATOM pour décrire des conversations : ►http://tools.ietf.org/html/rfc4685 Il a été proposé en 2007 de l’intégrer à une prochaine version de hAtom ( ►http://microformats.org/wiki/hatom-issues#marking_up_comments ) mais ça n’a pas l’air d’avoir avancé. Readability propose pour sa part de marquer tous les commentaires d’une classe « .comment » : ►https://www.readability.com/publishers/guidelines/#readabilityDirectives

Et pour ceux qui veulent un résumé en français du #RFC que suggère @clochix : ►http://www.bortzmeyer.org/4685.html