geo-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
Line 121: Line 121:
Notez que parce que l'exemple du vrai monde utilisait un présentation lisible humainement des coordonnées géo, nous utilisons le [[abbr-design-pattern-fr|abbr-design-pattern-fr]] pour conserver cette présentation plus lisible humainement, et en plus elle fournit les valeurs numériques respectives absolues pour le geo.
Notez que parce que l'exemple du vrai monde utilisait un présentation lisible humainement des coordonnées géo, nous utilisons le [[abbr-design-pattern-fr|abbr-design-pattern-fr]] pour conserver cette présentation plus lisible humainement, et en plus elle fournit les valeurs numériques respectives absolues pour le geo.


== Exemples dans la jungle ==
== exemples dans la jungle ==
Cette section est '''informative'''.
Cette section est '''informative'''.


Revision as of 07:19, 24 January 2007

geo

geo (nom de travail, prononcé "ji-oh") est un simple format pour baliser l'information latitude longitude, adaptable pour embarquement dans le (X)HTML, Atom, RSS et le XML arbitraire. geo est une représentation 1:1 de la propriété "geo" dans le standard vCard (RFC2426) dans XHTML, l'un des nombreux standards microformat ouverts.

Spécification Brouillon / Draft

Editeur/Auteur

Tantek Çelik, Technorati, Inc.

Traduction en cours

Christophe Ducamp

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

Patents

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 à tous ceux qui ont participé dans le Geo Microformat BOF à la conférence Where 2.0 de O'Reilly, et tout particulièrement Nat Torkington et Vee McMillen de O'Reilly pour organiser et héberger le BOF. Merci à Chris Hibbbert pour avoir fourni l'exemple de geo-cache du vrai monde.

Introduction et Historique

Le standard vCard (RFC2426), a été largement implémenté de façon interopérable (par ex. l'application carnet d'adresses d'Apple). Le microformat hCard a de manière similaire reçu une adoption significative de la part de nombreux sites publiant le format des proxies hCards aux vCards, jusqu'aux parseurs javascript côté client.

A la conférence Where 2.0 en juin 2005, il y a eu une reconnaissance largement acceptée que la communauté avait besoin d'un moyen pour publier simplement et facilement sur le web une information d'adresse qui soit visible, extractible, compte tenu du fait que souvent les blogueurs et les nombreux autres sites publient des informations d'adresses. Le geo microformat BOF a discuté tout particulièrement de ce sujet et s'est conclu avec une décision consensuelle de simplement essayer d'utiliser geo venant de vCard/hCard.

Cette spécification présente le microformat geo, qui est une représentation 1:1 de la propriété mentionnée ci-dessus geo extraite du standard vCard en réutilisant simplement la propriété geo et les sous-propriétés telles quelles extraites du microfomat hCard.

Les auteurs peuvent à la fois embarquer directement des adresses geo dans leurs pages web et fils, tout comme baliser des adresses existantes dans le contexte du reste de l'information dans leurs pages web et fils.

Si l'auteur connaît et publie le name de l'endroit en plus de sa geo lat/long, alors l'auteur DOIT utiliser hCard au lieu de simplement geo pour publier le nom et le geo lat/long du lieu.

Si l'auteur connaît et publie l'adresse du lieu, OU si l'adrese du lieu était ce qui était véritablement saisi par un humain, et que l'auteur ait simplement passé ça en lat/long en utilisant quelque sorte de service, alors l'auteur DEVRAIT utiliser adr pour publier l'information véritable humaine saisie parce qu'elle communique bien plus d'information sémantique que de simples coordonnées geo lat/long.

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

Propriétés Singulières

Remarquez que toutes les propriétés dans geo sont des propriétés singulières et par conséquent le premier élément descendant avec cette classe devrait prendre effet, tous les autres étant ignorés.

Lisible Humain vs Machine

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, ce qui fournit à la place une version humainement présentable de la valeur.

Extraction Valeur

Parfois, seule la partie d'un élément qui est l'équivalent pour une propriété devrait être utilisée pour la valeur de la propriété. A cette intention, le le nom de classe value est utilisé pour extraire la partie de l'élément qui est la valeur de la propriété. Voir hCard pour les détails à ce sujet.

Nom Classe Racine

Le nom de classe racine pou une adresse adr est geo.

Liste Propriétés

Ceci est la liste des propriétés dans geo, extraite de hCard :

  • latitude
  • longitude

Profil XMDP

Voir profil hCard pour le profil XMDP de hCard qui contient la liste complète au-dessus des propriétés, avec des références vers leurs définitions RFC 2426.

Détails Parsage

Voir parsage hCard, avec la seule différence étant que "geo" est le nom de classe racine, plutôt que "vcard".


Exemples

Cette section est informative.

Exemple extrait de RFC2426

La section 3.4.2 de RFC2426 a un exemple geo simple : 

GEO:37.386013;-122.082932

ce fragment de vCard comme un geo initialement documenté sur la page des exemples de hCard : 

<span class="geo">
 <span class="latitude">37.386013</span>, 
 <span class="longitude">-122.082932</span>
</span>

ce geo pourrait être affiché sous :

37.386013, -122.082932


Exemple geo du vrai monde

Voici un échantillon d'info publiée lat/long (tiré de geocaching: Noble Steed) : 

N 37° 24.491 W 122° 08.313

avec un balisage geo : 

<div class="geo">
 <abbr class="latitude" title="37.408183">N 37° 24.491</abbr> 
 <abbr class="longitude" title="-122.13855">W 122° 08.313</abbr>
</div>

Ce geo pourrait être aussi affiché comme :

N 37° 24.491 W 122° 08.313

Notez que parce que l'exemple du vrai monde utilisait un présentation lisible humainement des coordonnées géo, nous utilisons le abbr-design-pattern-fr pour conserver cette présentation plus lisible humainement, et en plus elle fournit les valeurs numériques respectives absolues pour le geo.

exemples dans la jungle

Cette section est informative.

Les sites suivants ont publié des geo en dehors du contexte normal des hCards, et sont par conséquent un endroit génial pour commencer à regarder des exemples "dans la jungle" afin d'essayer de parser, indexer, organiser, etc., en plus des exemples dans beaucoup d'exemples de hCard dans la jungle. Si vous trouvez des geos en dehors des hCards n'importe où ailleurs, sentez-vous à l'aise pour les ajouter en haut de cette liste. Une fois que la liste sera devenue trop grosse, nous ferons une page wiki séparée.

Implémentations

Cette section est informative.

Les implémentations suivantes ont été développées et soit génèrent ou parsent des geos en dehors du contexte des hCards. Si vous avez une implémentation geo, sentez-vous libre de l'ajouter en haut de la liste. Une fois que la liste sera devenue trop grosse, nous ferons une page wiki séparée.

Références

Références Normatives

Références Informatives

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 seront ajoutés.

Travaux en rapport

  • luna (proposition pour un microformat style-geo pour les coordonnées sur la Lune)
  • mars (proposition pour un microformat style-geo pour les coordonnées sur la planète Mars)
  • geo-extension-stawman - étend geo pour inclure les formats du dessus et pour représenter les coordonnées sur d'autres planètes, lunes, etc.

Travaux similaires

Voir aussi

Pages apparentées

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