hcalendar-fr: Difference between revisions
m (→Exemples dans la junge: typo) |
(implementations moved to a separate page) |
||
Line 182: | Line 182: | ||
== Implémentations == | == Implémentations == | ||
Cette section est '''pour information'''. | Cette section est '''pour information'''. Le nombre d'implémentations hCalendar a aussi grandi bien au delà des capacités de pouvoir les maintenir dans la page. Elles ont été migrées vers une [[hcalendar-implementations-fr|page séparée]]. | ||
Voir [[hcalendar-implementations-fr|hCalendar Implementations]]. | |||
== Références == | == Références == |
Revision as of 18:21, 18 December 2006
hCalendar
hCalendar est un format simple, ouvert, distribué pour le calendrier et les événements, fondé sur le standard iCalendar (RFC2445), adaptable pour l'embarquement dans (X)HTML, Atom, RSS et le XML arbitraire. hCalendar est l'un des nombreux standards ouverts microformat.
Vous voulez démarrer par écrire un événement hCalendar ? Utilisez le hCalendar creator pour écrire un événement et le publier, ou suivez les trucs de publication hCalendar pour ajouter de la syntaxe hCalendar à votre page d'événements à venir ou des événements que vous mentionnez dans vos billets de blogs, wikis, etc.
Spécification
- Editeur
- Tantek Çelik (Technorati, Inc)
- Auteurs
- Tantek Çelik, Technorati, Inc
- Brian Suda
(traduction Christophe Ducamp)
Copyright
Cette spécification est (C) 2004-2024 par les auteurs. Néanmoins, les auteurs ont pour but de soumettre cette spécification à un corps de standards avec une politique libérale de copyright/licence telle que GMPG, IETF, et/ou W3C. Quiconque souhaite contribuer devrait lire avant de contribuer leurs principes de copyright, politiques et licences (par ex. les Principes GMPG) et être d'accord avec eux, y compris le fait de licencier toutes les contributions sous les licences nécessaires (par ex. CC-by 1.0 et suivantes).
Brevets
Cette spécification est sujette à une politique de brevets libres de droits, par ex. pour la Politique de Brevet du W3C, IETF RFC3667 et RFC3668.
Inspiration et Remerciements
Merci à :
- Adam Bosworth pour avoir mené la présentation FOO Camp 2004 HTML For Calendars presentation qui a rassemblé une masse critique de parties intéressées.
Introduction
Le standard iCalendar (RFC2445), a été très largement mis en oeuvre avec interopérabilité (par exemple l'application "iCal" d'Apple intégrée dans MacOSX).
En outre, les blogueurs discutent souvent d'événements sur leurs blogs -- événements à venir, compte-rendus des événements passés, etc. Avec simplement une tout petit peu de structure, les blogueurs peuvent discuter d'événements dans leurs blogs d'une manière telle que les spiders et autres agrégateurs puissent retrouver de tels événements, les convertir automatiquement vers iCalendar, et les utiliser dans n'importe quel service ou application iCalendar.
Cette spécification présente le format hCalendar, qui est une représentation 1:1 du standard iCalendar précité en XHTML sémantique. Les Blogueurs peuvent embarquer à la fois les événements hCalendar directement dans leurs pages web, et les styler avec CSS pour les faire apparaître comme désiré. En outre, hCalendar permet aux applications de retrouver l'information sur de tels événements à partir de pages web sans avoir à référencer un fichier distinct.
Principes de Design XHTML Sémantique
Note : les Principes de Design XHTML Sémantique ont été écrits initialement dans le contexte de développement de hCard et hCalendar, par conséquent il peut être plus facile de comprendre ces principes dans le contexte de la méthodologie de design hCard (ce qui veut dire, lisez ça d'abord). Tantek
XHTML est construit sur du XML, et par conséquent les formats fondés sur XHTML peuvent être utilisés non seulement pour une présentation d'affichage pratique, mais aussi à des fins d'échanges de données. A bien des façons, les formats fondés sur XHTML illustrent le meilleur des mondes tant du HTML que du XML. Néanmoins au moment de construire des formats basés sur XHTML, cela aide d'avoir un ensemble de principes directeurs.
- Réutilisez autant que possible le schéma (noms, objets, propriétés, valeurs, types, hiérarchies, contraintes) à partir des standards de référence établis et bien supportés. Evitez de redéclarer les contraintes exprimées dans le standard source. Des mentions à titre d'information peuvent passer.
- Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de classe équivalents aux noms des composants.
- Les composants pluriels sont produits au singulier, et par conséquent plusieurs éléments imbriqués sont utilisés pour représenter plusieurs valeurs de texte qui sont délimitées par des virgules.
- Utilisez la sémantique XHTML la plus précise pour construire des blocs pour chaque objet, etc.
- Autrement utilisez un élément générique structurel (par ex.
<span>
ou<div>
), ou l'élément contextuel approprié (par ex. un<li>
dans un<ul>
ou<ol>
). - Utilisez des noms de classes basés sur des noms extraits du schéma original, à moins que le XHTML sémantique de construction de bloc ne représente précisément cette partie du schéma original. Si les noms dans le schéma original ne sont pas sensibles la casse, alors mettez tout dans un équivalent en bas de casse. Les noms de composants implicites en prose (plutôt qu'explicites dans le schéma défini) devraient aussi utiliser les équivalents bas de casse pour une facilité d'utilisation. Les espaces dans les noms des composants deviennent des caractères tiret '-'.
- Pour finir, si le format de la donnée selon le schéma original est trop long et/ou non amical sur le plan humain, utilisez
<abbr>
au lieu d'un élément générique structurel, et placez les données littérales dans l'attribut 'title' (là où vont les expansions abbr), et l'équivalent le plus bref et le plus lisible humainement dans l'élément lui-même. De plus amples explications de cet usage de<abbr>
: Human vs. ISO8601 dates problem solved
Format
En Général
Le standard iCalendar (RFC2445) constitue la base de hCalendar.
Note : l'éditeur et les auteurs de cette spécification sont en train de suivre l'effort "iCal-Basic" et ont l'intention de fonder le profil noyau du hcalendar sur iCal-Basic. Voir les références pour un lien vers le brouillon en cours.
Le format basique de hCalendar est d'utiliser les noms d'objet/propriété en bas de casse pour les noms de classes, et de mapper l'encapsulage des objets iCalendar directement à l'intérieur du XHTML imbriqué.
Plus d'Equivalents Sémantiques
Néanmoins, pour quelques propriétés il existe un équivalent plus sémantique, et par conséquent elles ont un traitement spécifique, c'est à dire :
URL
dans iCalendar devient<a class="url" href="...">...</a>
à l'intérieur de l'élément avecclass="vevent"
dans le hCalendar.ATTENDEE
,CONTACT
, etORGANIZER
dans le iCalendar peuvent être représentés par une hCard dans le hCalendar .- Un lieu nommé
LOCATION
(potentiellement avec une adresse et/ou geo) dans iCalendar peut être représenté par une hCard imbriquée dans le hCalendar. De la même façon, une adresseLOCATION
peut être représentée par un adr et un geo (latitude et longitude)LOCATION
peut être représenté par un geo. UID
dans le iCalendar devient simplement une autre sémantique appliquée à un URL spécifique pour un événement hCalendar.
Propriétés Singulier vs Pluriel
Pour les propriétés qui sont singulières (par ex. "N" et "FN" extrait de vCard), le premier élément descendant avec cette classe-là devrait prendre effet, tous les autres étant ignorés.
Pour les propriétés qui peuvent être plurielles (par ex. "TEL" extrait de la vCard), chaque instance de classe devrait créer une instance de cette propriété. Les propriétés plurielles avec des sous-types (par ex. TEL avec WORK, HOME, CELL extrait de la vCard) peuvent être optimisées pour partager un élément commun pour la propriété elle-même, avec chaque instance de sous-type étant un descendant proprement classé de l'élément propriété.
Plusieurs Propriétés Singularisées
Parce que les noms de propriétés plurielles deviennent leurs équivalents singuliers, même si la propriété plurielle originale n'a permis seulement qu'une valeur unique avec plusieurs composants, ces composants-là multiples sont représentés chacun avec leurs propres singularités nommées propriété et la propriété a en fait plusieurs valeurs et est sujette au traitement ci-dessus des propriétés à plusieurs valeurs.
Lisible par des Humains vs Machines
Si un élément <abbr>
est utilisé pour une propriété, alors l'attribut 'title
' de l'élément <abbr>
est la valeur de la propriété, au lieu des contenus de l'élément, qui fournit à la place uen version humaine présentable de la valeur. Cette spécification recommande que de tels éléments <abbr>
soient utilisés pour les propriétés suivantes iCalendar :
- DTSTART, DTEND, DURATION, RDATE, RRULE
Exemple
Voilà un événement échantillon dans un iCalendar :
BEGIN:VCALENDAR PRODID:-//XYZproduct//EN VERSION:2.0 BEGIN:VEVENT URL:http://www.web2con.com/ DTSTART:20051005 DTEND:20051008 SUMMARY:Web 2.0 Conference LOCATION:Argent Hotel\, San Francisco\, CA END:VEVENT END:VCALENDAR
et un équivalent en format hCalendar avec différents éléments optimisés de façon appropriée. Voir étapes-hcalendar-exemple 1 pour l'origine.
<span class="vevent"> <a class="url" href="http://www.web2con.com/"> <span class="summary">Web 2.0 Conference</span> : <abbr class="dtstart" title="2005-10-05">5</abbr>- <abbr class="dtend" title="2005-10-08">7</abbr> octobre à l'<span class="location">Hôtel Argent, San Francisco, CA</span> </a> </span>
qui pourrait être affiché comme :
Web 2.0 Conference : 5-7 octobre, à l'Hôtel Argent, San Francisco, CA
L'exemple suivant spécifie un rendez-vous programmé qui commence le 12 mars 1998 à 08:30 EST et se termine à 09:30 EST le 12 mars 1998.
BEGIN:VCALENDAR BEGIN:VEVENT UID:guid-1.host1.com DTSTAMP:19980309T231000Z DESCRIPTION:XYZ Réunion Bilan SUMMARY:Projet XYZ Réunion Bilan DTSTART:19980312T133000Z DTEND:19980312T143000Z LOCATION:1CP Salle de Conférence 4350 END:VEVENT END:VCALENDAR
L'équivalent en hCalendar :
<div class="vevent"> <h3 class="summary">XYZ Réunion Bilan</h3> <p class="description">Projet XYZ Réunion Bilan</p> <p>programmé le <abbr class="dtstart" title="1998-03-12T08:30:00-05:00">12 mars 1998 à partir de 08:30 EST</abbr> jusqu'à <abbr class="dtend" title="1998-03-12T09:30:00-05:00">09:30 EST</abbr></p> <p>Lieu : <span class="location">1CP Salle de Conférence 4350</span></p> <small>Réservé par : <span class="uid">guid-1.host1.com</span> le <abbr class="dtstamp" title="19980309T231000Z">9 mars 1998 18:00</abbr></small> </div>
Ceci pourrait s'afficher comme
XYZ Réunion Bilan
Projet XYZ Réunion Bilan
programmé le 12 mars 1998 à partir de 08:30 EST jusqu'à 09:30 EST
Lieu : 1CP Salle de Conférence 4350
Réservé par : guid-1.host1.com le
9 mars 1998 18:00Note 1 : L'information produit n'est pas nécessaire parce que le hCalendar est un format interchangeable. Quand hCalendar est transformé en iCalendar, le moteur transformant devrait ajouter sa propre ID produit.
Note 2 : Un élément entourant le <span class="vcalendar">
est optionnel et laissé comme ceci. Il est optionnel parce que le contexte d'un vcalendar est implicite quand un vevent est rencontré. Le contexte/étendue implicite est celui du document. Les auteurs peuvent explicitement utiliser des éléments avec class="vcalendar" pour emballer les ensembles de vevents qui appartiennent tous au même calendrier, par exemple au moment de publier plusieurs calendriers sur la même page.
Note 3 : L'information de version n'est pas nécessaire directement dans la syntaxe hCalendar parce que la version sera définie par le profil de qui est utilisé/référencé dans l'attribut 'profile' de l'élément <head>.
Note 4 : Les dates ISO8601 (requises par iCalendar) ne sont pas très humaines. En outre, l'année est souvent comprise implicitement par les humains à partir du contexte. Par conséquent les éléments <abbr>
sont utilisés pour fournir simultanément une date humaine et/ou une heure dans les contenus visibles de l'élément, tout en plaçant respectivement l'heuredate ISO8601 parsable par les machines dans l'attribut 'title'. La notation YYYY-MM-DD devrait être utilisée pour une meileure lisibilité.
Note 5 : La différence entre la date DTEND ISO8601 (2005-10-08) et la date lisible par un humain (7) n'est PAS une erreur. DTEND est exclusif, voulant dire que l'événement finit simplement avant le DTEND. De ce fait pour les événements qui démarrent sur un jour et finissent sur un autre jour, la date DTEND doit être spécifiée comme le jour après le jour qu'un humain dirait que c'est le dernier jour de l'événement.
Note 6 : L'endroit (Location) dans cet exemple contient une structure implicite (nom du lieu de l'événement, ville, état) qui devrait être balisée explicitement sous une hCard. Voir hCalendar brainstorming: hCard locations pour une explication sur la façon de faire ça.
Plus d'exemples
Voir hCalendar exemples pour plus d'exemples, y compris des exemples extraits de la RFC 2445 iCalendar convertis en hCalendar.
Exemples dans la jungle
Cette section est informative. Le nombre d'exemples hCalendar dans la jungle a grandi bien au-delà de la capacité de pouvoir être maintenus à l'intérieur de cette spécification. Ils ont été migrés vers une page séparée.
Voir hCalendar Exemples dans la jungle.
Implémentations
Cette section est pour information. Le nombre d'implémentations hCalendar a aussi grandi bien au delà des capacités de pouvoir les maintenir dans la page. Elles ont été migrées vers une page séparée.
Voir hCalendar Implementations.
Références
Références Normatives
Références Informatives
- CSS1
- terme hCalendar introduit et défini sur le Web, 30 septembre 2004
- FOO Camp 2004 Présentation HTML For Calendars, 11 septembre 2004
- FOO Camp 2004 Présentation : Simple Semantic Formats, 10 septembre 2004
- iCal-Basic draft 04
- Contributed from http://developers.technorati.com/wiki/hCalendar
- XHTML 1.1
Travail similaire
Pages Apparentées
- hCalendar creator (feedback) - créez vos propres événements hCalendar.
- hCalendar authoring - apprenez comment ajouter du balisage hCalendar à vos événements existants.
- hcalendar-intro brouillon en langage clair introduction (pour utilisation en Evangélisme)
- hCalendar FAQ - Si vous avez quelque question à propos du hCalendar, regardez cette page, et si vous ne trouvez pas de réponses, ajoutez vos questions !
- parsage hCalendar - Détails normatifs sur la manière de parser hCalendar.
- problématiques hcalendar - SVP ajoutez tous les problèmes que vous avez avec les spécifications sur le document problématiques
- hCalendar profile - Le profil XMDP pour hCalendar
Cette spécification est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront ajoutés. Ces pensées, problématiques et questions sont maintenues dans des pages séparées.
- hCalendar Brainstorming - l'endroit où nous maintenons nos brainstorms et autres explorations en rapport avec hCalendar
- hCalendar tests - une page wiki avec de vrais événements embarqués hCalendar pour faire des essais de parsage.
- implémentations iCalendar
Pour aller plus loin
- jwz - Hula (required reading)
- Groupware Bad de Jamie Zawinski critallise la raison pour hCalendar (emphase ajoutée ) :
"A cette heure, les gens font cela en publiant des fichiers .ics, mais ce n'est pas trivial de faire ainsi, et c'est du travail de la part des autres personnes pour les regarder. If it's not HTML hanging off our friend's home page that can be viewed in any browser on a public terminal in a library, the bar to entry is too high and it's useless."
- Jason Klemow's blog
- Moving forward with microformats de Jon Udell fournit un exemple hCalendar et quelque discussion.
- Voir aussi les blogs qui discutent de cette page et le tag hCalendar
- article Wikipedia sur hCalendar (requiert un remaiement, une expansion et une traduction)