hAtom 0.1

From Microformats Wiki
Jump to navigation Jump to search

Ce document est une spécification microformat draft. Bien que les "drafts" soient en quelque sorte mâtures dans le processus de développement, la stabilité de ce document ne peut être garantie, et les implémenteurs doivent être prêts à rester informés des futurs développements et modifications. Suivez cette page wiki, ou suivez les discussions sur la liste de discussion microformats-new pour rester informé.

hAtom est un microformat pour le contenu qui peut être syndiqué, initialement conçu pour les billets de blog mais pas exclusivement. hAtom est basé sur un sous-ensemble du format de syndication Atom. hAtom sera l'un des nombreux microformats standards ouverts.

Spécification Draft

Editor/Author
David Janes (BlogMatrix, Inc.)
Contributeurs
Benjamin Carlyle
Tantek Çelik (http://tantek.com/ and before at Technorati, Inc.)
Traduction
Christophe Ducamp


Les déclarations de copyright de brevets sont en vigueur.


Statut

hAtom 0.1 est une spécification draft microformats.org. La discussion publique sur hAtom a lieu sur hatom-feedback, le canal irc #microformats sur irc.freenode.net, et microformats-discuss et liste de diffusion.

Langues disponibles

La version anglaise de cette spécification est la seule version normative. Pour les traductions de ce document voir la section #traductions.

Errata et Mises à Jour

Des erreurs connues et des préoccupations dans cette spécification sont corrigées dans les problématiques résolues et fermées. SVP vérifiez là-bas avant de rendre compte de problématiques.

La mise à jour hAtom 0.2 est actuellement en développement et incorpore des corrections connus d'errata tout comme le modèle-de-classe-value.

Introduction

hAtom est un microformat pour identifier l'information sémantique dans les billets de blog et pratiquement n'importe quel autre endroit Atom peut être utilisé, comme les articles d'actualités. Le contenu hAtom est facilement ajouté à la plupart des blogs par de simples modifications aux définitions du gabarit du blog.

Les mots-clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "OPTIONNELLE" dans ce document doivent être interprétés comme décrits dans la RFC 2119.


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.

  1. 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.
    1. Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de classe équivalents aux noms des composants.
    2. 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.
  2. Utilisez la sémantique XHTML la plus précise pour construire des blocs pour chaque objet, etc.
  3. 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>).
  4. 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 '-'.
  5. 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 Format de Syndication Atom fournit la base conceptuelle pour ce microformat, avec les mises en garde suivantes :

  • Atom fournit beaucoup plus de fonctionnalités qu'il n'en faut pour un microformat "billet blog", aussi nous avons pris le nombre minimal d'éléments requis.
  • le modèle "logique" de hAtom est celui d'Atom. S'il y a un conflit, Atom devrait être pris comme correct.
  • le modèle "physique" de hAtom -- la véritable écriture des éléments -- est bien plus varié que ce que fournit Atom, du fait de la variété des manières dont sont effectivement produits les weblogs dans la jungle. Le microformat hAtom fournit un certain nombre de règles pour "ponter le fossé"

Schéma

Les éléments du schéma sont basés sur la nomenclature Atom et suivent le modèle de préfixer un identifiant unique (dans ce cas, 'h') sur la plupart des éléments conteneurs -- le Fil ou l'Entrée. Les parties de ce microformat sont basées sur l'analyse de beaucoup de weblogs, de bulletin board et de billets média et peuvent être lus sur blog-post-brainstorming#Eléments découverts.

Le schéma hAtom comprend les points suivants :

  • hfeed (hfeed). optionnel.
    • feed category. optionnel. mots-clé ou phrases, en utilisant rel-tag.
    • hentry (hentry).
      • entry-title. requis. texte.
      • entry-content. optionnel (voir desription champ). texte. [*]
      • entry-summary. optionnel. texte.
      • updated. requis en utilisant le datetime-design-pattern. [*]
      • published. optionnel en utilisant le datetime-design-pattern.
      • author. requis en utilisant hCard. [*]
      • bookmark (permalink). optionnel en utilisant rel-bookmark.
      • tags. optionnel. mots-clés ou phrases, utilise rel-tag.

[*] Quelques éléments requis ont des valeurs par défaut si elles manquent, voir en-dessous.

Détails Champ et Elément

Feed
  • un élément Feed est identifié par le nom de classe hfeed
  • un élément Feed représente le concept d'un fil Atom
  • l'élément Feed est optionnel et s'il manque, il est supposé être la page
  • les documents hAtom PEUVENT avoir plusieurs éléments Feed.
Feed Category
  • un élément Feed Category est identifié par rel-tag
  • un Fil PEUT avoir un Feed Category
  • un élément Feed Category représente le concept d'une catégorie Atom dans un fil
  • les éléments Feed Category DOIVENT apparaitre à l'intérieur d'un élément Fil mais pas à l'intérieur d'un élément Entrée
  • le rel-tag href encode le category:term atom ; le lien texte définit la category:label atom.
Entry
  • un élement Entry est identifié par le nom de classe hentry
  • un élement Entry représente le concept d'une entrée Atom
  • tout contenu microformat à l'intérieur d'un élément <blockquote> ou <q> dans l'Entry ne devrait pas être considéré comme partie de l'Entry.
Ceci permet la citation d'autres données microformatées sans se soucier de corrompre le modèle
Entry Category
  • un élément Entry Category est identifié par rel-tag
  • une Entrée PEUT avoir une Entry Category
  • un élément Entry Category représente le concept d'une catégorie Atom à l'intérieur d'une entrée
  • le rel-tag href encode le category:term atom ; le lien texte définit la category:label atom
Entry Title
  • un élément Entry Title ('entry-title') est identifié par le nom de classe entry-title
  • une Entry DEVRAIT avoir une Entrée Titre
  • un élément 'Entry Title' représente le concept d'une entrée titre Atom
  • si 'Entry Title' manque, utilisez
    • le premier élément <h#> dans l'Entry, ou
    • le <title> de la page, s'il n'y a pas d'élément Feed enclos, ou
    • supposez que ce soit la chaîne vide
Entry Content
  • un élément "Entry Content" est identifié par le nom de classe entry-content
  • une Entry DEVRAIT (DEVRAIT) avoir une Entrée Contenu
  • un élément "Entry Content" représente le concept d'un contenu Atom
  • une Entry PEUT (PEUT) avoir 0 or plus éléments "Entry Content". L'"Entry Content" logique d'une Entrée est la concaténation, par ordre d'apparition, de toutes les Entrées de Contenus dans l'Entrée.
Beaucoup de weblogs découpent le contenu en plusieurs sections avec un lien "En savoir plus" et des trucs javascript. Ceci est aussi requis dans les cas où les 'entry-title' sont codés dans la ligne et sont considérés comme partie du contenu.
  • si 'Entry-Content' manque, supposez que c'est la chaîne vide.
Entry Summary
  • un élément Entry Summary est identifié par le nom de classe entry-summary
  • un élément 'Entry Summary' représente le concept d'un summary Atom
  • une 'Entry' PEUT (PEUT) avoir 0 ou plus d'éléments 'Entry Summary'. L'"Entry Summary" logique d'une Entry est la concaténation par ordre d'apparition, de tous les 'Entry Summary' dans l' 'Entry'.
Entry Permalink
  • un élément 'Entry Permalink' est identifié par rel-bookmark
  • une Entry DEVRAIT (DEVRAIT) avoir une 'Entry Permalink'
  • un élément 'Entry Permalink' représente le concept d'un lien Atom dans une entrée
  • si 'Entry Permalink' manque, utilisez l'URI de la page ; si l'Entry n'a pas d'attribut "id", ajoutez cela comme un fragment vers l'URI de la page pour distinguer les entrées individuelles
Entry Updated
  • un élément 'Entry Updated' est identifié par le nom de classe updated
  • un élément 'Entry Updated' représente le concept de Atom updated
  • une Entry DEVRAIT (DEVRAIT) avoir un élément 'Entrée Mise à jour'
  • utiliser le datetime-design-pattern pour encoder la date et l'heure de mise à jour
  • s'il n'existe pas d'élément 'Entry Updated',
    • utilisez l'élément 'Entry Published' si présent
    • autrement la page est invalide hAtom
Entry Published
  • un élément 'Entry Published' est identifié par le nom de classe published
  • un élément 'Entry Published' représente le concept de Atom published
  • utilisez le datetime-design-pattern pour encoder la date et l'heure de publication
Entry Author
  • un élément 'Entry Author' est représenté par le nom de classe author
  • un élément 'Entry Author' représente le concept d'un Atom author
  • un élément 'Entry Author' (DOIT) être encodé dans une hCard
  • un élément 'Entry Author' DEVRAIT être encodé dans un élément <address>
  • une Entry DEVRAIT avoir au moins un élément 'Entry Author'
  • une Entry PEUT avoir plus qu'un élément 'Entry Author'
  • si l'Entrée Auteur manque
    • trouvez le(s) élément(s) <address> Plus Proche En Parent avec le nom de classe author et qui soit/soient une hCard valide.
    • autrement l'entrée est hAtom invalide

Profil XMDP

Voir hAtom-profile.

Exemples

Voir exemples hatom.

Exemples dans la jungle

Cette section est informative. Voir hAtom-exemples dans la jungle

Implémentations

Cette section est informative.

Les implémentations qui suivent ont été développées et elles génèrent ou parsent les liens hAtom. Si vous avez une implémentation hAtom, sentez-vous libre de l'ajouter en haut de cette liste. Une fois que la liste sera devenue trop grosse, nous produirons une page wiki séparée comme hatom-implementations.



Copyright

Cette spécification est (C) 2005-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).

  • Tantek : Je sors toutes mes contributions à cette spécification dans le domaine public et j'encourage les autres auteurs à faire ainsi.
    • Quand tous les auteurs/éditeurs auront fait ainsi, nous pourrons retirer la référence au modèle MicroFormatCopyrightStatement et la remplacer avec le modèle MicroFormatPublicDomainContributionStatement.


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.


Références

Références Normatives

Références Informatives

Spécifications Qui utilisent hAtom

Travail Similaire

Pour aller plus loin :

Chantier en Cours

Cette spécification est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils sont ajoutés. Il existe un document séparé où nous conservons nos brainstorms et autres explorations en rapport avec hAtom :

Version 0.1

La version 0.1 est sortie le 28 février 2006.

Discussions

Q&R

  • Si vous avez quelque question à propos de hAtom, regardez les FAQ hAtom, et si vous ne trouvez pas de réponses, ajoutez vos questions !

Problématiques

Voir aussi


Traduction

Lisez la spécification draft hAtom dans d'autres langues:

Retrieved from "http://microformats.org/wiki/index.php?title=hatom-fr&oldid=69788"