#microformat

#développement #web aussi

faut rester proche, tant que faire se peut, de iCal... facile à dire, je sais, mais j’ai essayé quand j’étais un jeune codeur fou (avec RSS en fait) :p

Le truc, c’est qu’il n’y avait pas tellement le choix, fallait adopter une convention pour encapsuler les infos iCal dans les balises RSS... et avoir un décodeur en face... une sorte de standard dans le standard... Bref, il manque une RFC (ping @stephane) :)

Ce serait chouette que tu parviennes à quelque chose, bon courage ! ;)

Remarque, je dis ça, mais t’as peut-être pas le choix, le mieux serait que ton flux soit en iCal, ça serait plus simple...

Je ne sais pas... Je ne vois pas trop pourquoi rester absolument proche de ical, sinon autant utiliser un #flux #ical (ce que je vais faire de toute façon aussi).

Atom a déjà des éléments de base pour certaines informations (description, auteurs, date de mise à jour du contenu, date de publication, etc). Donc on utilise déjà ces infos. Pour ce qui manque, le principe d’Atom c’est d’ajouter des extensions : autrement dit des schémas supplémentaires déclarés au début dont on ajoute des éléments dans les entrées ou dans le flux.

Par exemple j’ai déjà utilisé opensearch pour décrire que ça renvoyait pas l’ensemble, qu’il y avait plusieurs pages, le total, etc.
Ou encore georss pour ajouter les coordonnées.

Mais à part le format de Google, je ne vois rien d’autres de standards pour « la date de fin » par exemple. Ainsi que le lieu (pas les coordonnées, mais le nom de l’endroit et son adresse).

Bon après j’ai d’autres trucs à mettre dedans mais c’est moins générique : le ou les tarifs, le ou les publics, la distribution (artistes, intervenants, etc).

Ah ben voilà @james nos messages se sont croisés. Oui il y aura aussi un flux ical. Mais c’est pour proposer plusieurs formats de flux différents.

ou bien coller un http://microformats.org/wiki/hcalendar dans le flux ?

Mais oui ! un #microformat ! :)

Sinon, parallèlement à ça : je crois que #SPIP ne sait pas lire iCal. Il me semble que c’était d’ailleurs pour ça que j’avais essayé d’échanger des évènements entre sites avec du RSS. C’est con, hein, je sais, mais au final, si les CMS savait lire iCal aussi simplement qu’ils lisent du XML, ça serait cool.

Dans « content » (avec type="html") tu veux dire @fil ?

Oui effectivement, cela permettrait d’avoir un flux lisible par tous les lecteurs classiques, et d’avoir en même temps les infos récupérables, une à une, par une machine.

Mais baliser le content HTML avec des microformats n’empêche pas d’ajouter les bonnes balises XML si des extensions possibles existent. Ou des balises « métiers » propres au site, pour ce qui n’existe pas. Bon ok ça augmente la taille du code, mais ça évite de scanner deux fois avec deux parseurs différents (un pour le XML du Atom, un pour trouver des microformats dedans ensuite) pour ceux qui connaîtraient à l’avance les balises utilisées.

La combinaisons des deux me semblent pas mal pour couvrir tous les cas.

@james ya des libs PHP qui existent en tout cas : fézendonc un plugin ! :)

oui, ouieuh, je me suis déjà dit çaeuh ... :p

Voici un document qui explique comment intégrer correctement les microformats dans une liste de contenus, et notamment dans un flux Atom :
http://www.opensearch.org/Documentation/Recommendations/OpenSearch_and_microformats

(J’utilise déjà en partie OpenSearch pour indiquer le nombre total de résultats, le pas de la pagination, etc.)

C’est un truc comme ça que tu veux faire ?
http://code.demosphere.eu/fr

Non. :)

Et ça ?

Adding event times and location to RSS and Atom feeds | Oxford University Computing Services, In a pickle
http://blogs.oucs.ox.ac.uk/inapickle/2009/12/16/adding-event-times-and-location-to-rss-and-atom-feeds

<ev:startdate>2010-01-18T16:00:00+00:00</ev:startdate>
<ev:enddate>2010-01-18T17:00:00+00:00</ev:enddate>

#atom #events #xml

Ah super intéressant, merci @touti.

Cette page de l’université d’Oxford propose deux solutions :
– le module pour RSS « event » du W3C qui est en brouillon :
http://web.resource.org/rss/1.0/modules/event
– le format xCal qui est une mise en XML du format iCal, et qui est aussi en brouillon :
http://tools.ietf.org/html/draft-royer-calsch-xcal-03

Le deuxième étant beaucoup plus complet.

On y trouve des exemples (simples) d’utilisation. Et aussi une inclusion de #vCard dans un flux Atom.

Ah et pour @james : lire du iCal dans SPIP et mieux encore directement dans une boucle, c’est en fait déjà possible avec DATA et le plugin « icalendar » de @fil :
http://contrib.spip.net/Plugin-iCalendar
http://zone.spip.org/trac/spip-zone/browser/_plugins_/icalendar

Ça inclut une classe PHP qui a l’air assez complète (que je viens de mettre à jour).

ah oui tiens, j’avais #oublié

l’engueulade entre les gens qui travaillent sur ces sujets de manière ouverte depuis des années (microformats, RDFa) et Google (dans le rôle de la terreur) est très intéressante : http://www.w3.org/2011/06/semtech-bof-notes.html
#open-web #internet #standards (via @karlpro)

cf http://seenthis.net/messages/20560

Ben, l’exemple cité en ►http://schema.org/docs/gs.html n’est même pas en XHTML donc ça va être dur à traduire...

Super cool ce début d’ouverture, merci !

Par contre, pourquoi les avoir mis dans un sous-dossier « seenthis » s’ils peuvent être utilisées indépendamment, génériquement ? (Oui j’pouvais pas m’empêcher de la poser celle-là...)

Comme je disais plus tôt, là où tu lis la date au format unix
Math.floor($(this).attr(« title »))
tu pourrais lire aussi la décoder si elle est au format datetime
http://seenthis.net/messages/8747
ce qui rendra les choses plus #microformats

@rastapopoulos

– parce que j’ai besoin de les identifier comme tels : ceux-là, je ne souhaite pas qu’on me les pourrisse sans me demander mon avis ; je n’ai pas le temps de suivre tous les plugins que j’ai installés sur la Zone, mais suivre un sous-dossier, ça je dois pouvoir y arriver ;

– parce que je ne suis pas encore certain que tout sera livré sous forme de plugins bien finalisés, alors un sous-dossier générique pourrait s’avérer utile.

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

#hNews ►http://microformats.org/wiki/hnews
et donc #hAtom ►http://microformats.org/wiki/hAtom

et/ou HTML5

En pratique ces marqueurs améliorent un peu le score de certains blocs de texte, mais de façon secondaire ; il ne suffit pas de marquer un texte .entry-content pour qu’il soit « pris » par readability. On continue donc à perdre parfois le chapo et tout le temps les notes de bas de page.

il faudrait de préférence utiliser le #microformat #datetime ; ci-dessous une solution pour l’afficher proprement avec #javascript http://stackoverflow.com/questions/436374/how-can-i-convert-datetime-microformat-to-local-time-in-javascript
(#seenthis_todo)

J’ai l’impression que ce microformat #datetime est encore trop « ouvert » et qu’il vaudrait mieux un format bien défini, celui du RFC 3339 http://www.bortzmeyer.org/3339.html

Non, je ne peux pas changer ce contenu, actuellement placé en « title » : c’est le timestamp que j’utilise, en permanence, pour calculer le « il y a... » dynamiquement en javascript. (@fil, dans ton microformat, le gars stocke bien la valeur de la date dans un title, il aura donc exactement le même problème que moi.)

C’est plutôt l’utilisation du « title » qui pose problème (puisque son contenu apparaît au survol prolongé). Je ne vois que deux solutions pour l’instant :
– utiliser une structure plus complexe pour stocker mon timestamp ailleurs dans le DOM (vraiment pas envie de complexifier le DOM pour ça),
– utiliser un « data-* » de HTML5 (data-time, essentiellement). Cette solution a ma préférence.

Mais :
– si je passe en HTML5, j’aimerais tout passer en #HTML5 ;
– j’ai codé ça sous forme de plugin #SPIP (que je vais diffuser), et je ne sais pas encore comment faire pour générer une fois du XHTML, une fois du HTML5 avec le même plugin. Et j’ai pas envie de faire un plugin qui pète la validation d’un site juste pour afficher une date relative dynamiquement.

pas d’accord ; le title au format datetime est relativement lisible pour un #humain (beaucoup plus que le nombre de secondes écoulées depuis #EPOCH)

Hashtag : #WordPress