#ical

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

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é