machine-data-fr

From Microformats Wiki
Jump to navigation Jump to search

Données Machine dans les Microformats

Les microformats sont conçus pour marquer une information consommable par l'humain, comme cela se rencontre généralement dans la jungle. Mais dans un certain nombre de cas exceptionnels, il a été nécessaire de spécifier des formats précis de données pour des propriétés spécifiques. Les formats pour les dates, horaires, et lieux sont standardisés d'une manière qui ne correspond pas toujours à la manière dont l'information est publiée visiblement. Ceci est nécessaire pour faire que la donnée soit compréhensible par les parseurs. De la même manière, il y a des mots-clés dans la hCard qui doivent être écrits en anglais ('type' telephone dans la hCard par exemple).

Il est nécessaire pour ces formats de données d'être fixés pour rendre la donnée parsable par les machines ; le coût pour un parseur de supporter chaque format publié de date-time dans le monde (ce qui inclut des approximations comme 'il y a cinq minutes') est trop élevé, comme l'est la gestion de traduction internationale (telle que les téléphones mobiles ; US-English ‘cell’ publié comme un 'mobile' British English).

Dans certains cas, la version humaine de la donnée peut être sémantiquement décrite sous une forme abrégée de la donnée machine, et la donnée machine peut être aussi consommable par l'homme. Par exemple le date-design-pattern utilise l'élément abbr du HTML pour étendre une représentation de date humaine en une date au format ISO 8601 : ‘January 1st’ est une forme abrégée ‘2008-01-01’. La dernière est aussi déchiffrable pour les humains (et peut leur être exposée à travers des infobulles et des screen-readers).

Dans d'autres cas, cette donnée machine n'est pas déchiffrable par les humains. Dans le hAudio, la propriété duration utilise ISO 8601, ce qui aboutit en une donnée machine de PT3M23S ; non compréhensible pour les humains, et par conséquent pas une expansion valide de ‘trois minutes et ving-trois secondes’.

Cas de Formats de Données Fixés dans les Microformats

Ce qui suit sont tous les usages actuels des formats de données machine fixés requis par les différents microformats.

hCalendar

  • Usages de ISO 8601 pour dtstart, dtend, duration et rdate

hCard

  • Telephone mots-clés type : voice, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs.
  • Address mots-clés type : INTL, POSTAL, PARCEL, WORK, dom, home, pref.
  • Email mots-clés type : INTERNET, x400, pref.
  • Usages de date ISO 8601 pour bday
  • ISO 8601 time zone pour tz
  • Les numéros de téléphone requièrent une forme numérique, bien que les numéros de téléphone puissent être présentés sous forme alpha-numérique : par ex +1-555-FORMATS

hReview

  • Usages d'un date-time ISO 8601 pour dtreviewed
  • Usages de valeurs entières de 0-5 pour rating (les éditeurs peuvent par exemple, afficher une évaluation en pourcentage)

hAtom

  • Usages d'un date-time ISO 8601 pour updated
  • Usages d'un date-time ISO 8601 pour published

hResume

  • Uses ISO 8601 date for individual experience items.
  • Uses ISO 8601 date for individual education items.

Geo

  • requiert latitude et longitude en format décimal (1.23232;-2.343535), mais peut être publié en degrés  : N 37° 24.491, W 122° 08.313
  • Les lieux sont le plus souvent publiés tout simplement comme des noms d'endroits (pas des coordonnées abrégées)

hAudio

  • Utilise ISO 8601 pour la duration de la plage, par ex. PT3M23S

Embarquement de Formats de Données Fixés dans les Microformats

Il existe actuellement trois méthodes supportées pour inclure ces formats de données fixés dans un document microformaté.

Contenu de Page Visible

Vous pouvez utiliser le class-design-pattern pour marquer la donnée visiblement dans la page.

Ben est né le <span class="bday">1984-02-09</span>.

Nous nous rencontrons sur le Toit de la Grande Arche (<span class="geo">48.892381, 2.236274</span>).


Abréviation

Dans quelques cas, les formats de données spécifiés produisent des expansions valides de formes communes pour les humains, tels que les dates dans un champ birthday de hCard :

Ben est né le <abbr class="bday" title="1984-02-09">9 février</abbr>

Remarquez néanmoins que tous les formats de données ne sont pas des expansions valides. En HTML, l'élément abbr fonctionne sémantiquement à un niveau texte, pas à un niveau donnée. Tant la forme abrégé (le texte à l'intérieur) que la forme étendue (le title) ont besoin d'être consommables par les humains.

Ce qui veut dire dans hAudio, que l'utilisation d'une abréviation pour duration est incorrect :

<abbr class="duration" title="PT3M23S">3 minutes, 23 secondes</abbr>

Whilst the data ‘PT3M23S’ is an expanded form of ‘3 minutes, 23 seconds’, the text is not; ‘PT3M23S’ is nonsense to most human beings. abbr is an element that describes the text, not the data. HTML4 has no way to mark up arbitrary data.

Donnée Supplémentaire

The machine data form can be included alongside any human legible text, and hidden using another layer of the browser stack (namely, CSS). This behavior is derived from the value excerpting behavior in hCard.

So, for example, when describing a location by name, but still wanting to include geo for the machine-readable location:

<span class="geo">Northumberland Avenue, London <span class="value">51.507033,-0.126343</span></span>

Then, optionally use CSS to hide the data you don't want displayed:

.geo > .value { display: none; }

The same pattern works for the hAudio duration example given above:

<span class="duration">3 minutes and 23 seconds <span class="value">PT3M23S</span></span>

And again, the optional CSS:

.haudio .duration > .value { display: none; }

Of course, this does result in a dependency on CSS to make the data invisible to users, and will result in the machine data being displayed alongside the human form in any user agent without CSS support. That's a compromise that has to be resolved based on the requirements of individual sites.

Méthodes Proposées

Donnée Supplémentaire Invisible

This section is a proposed extension to value-excerpting, is currently open to active discussion and is not currently supported in parsers. You must not implement this in pages at this time.

Value excerpting is already implemented as a means of extracting data from within a microformat property. Where the element (any element) with class="value" is also empty (containing no inner-text), parsers should instead read the value of the title attribute of that element.

So, the following code will read the inner-text of the element, as per current implementations:

<span class="dtstart">Tomorrow lunchtime <span class="value">2008-05-17T12:00:00+0100</span></span>

The data format, poorly legible to most humans remains visible in the page. To make the machine data invisible at an HTML level, the following can also be parsed:

<span class="dtstart">Tomorrow lunchtime <span class="value" title="2008-05-17T12:00:00+0100"></span></span>

The span with class="value" is empty, therefore the parser must read the value of the title attribute instead. Where the element is not empty, the title attribute is ignored.

Empty elements are invisible within the page, and take up no physical space, so the title is not exposed as a tool-tip. Also, the entire element is ignored by assistive technology such as screen readers, therefore the data is not exposed to any user. This assistive technology claim is based on informed, expert advice, but is awaiting confirmation through testing. That testing is forthcoming.

HTML has no pure way of including machine data inline. The use of value excerpting, which can be applied to any HTML element, is the least obtrusive way to embed data into HTML, without overloading existing element semantics and without browser compatibility issues.

Problèmes Potentiels

  • Some parsers (particularly those that run incoming HTML through Tidy to convert it into well-formed XML) may strip empty inline elements. A workaround may be to allow (or even require) hard white space (i.e. &nbsp;) within the element with class='value".
    • It is, however, trivial to patch and build Tidy not to do this (keeping empty elements where that element also has a class attribute). Parser writers need to feed back on whether using a custom build is impossible to their solution, but since Tidy can be made to work, the problem can likely be alleviated. Ben Ward has put up an experimental build of Tidy with patched element-dropping behavior here: tidy-microformats.zip

Autres Propositions

Cette section doit être étendue.

  • ufusetitle class
  • adopter l'attribut RDFa "content"
  • "data:" prefix

Remerciements

  • Mike Davies pour sa suggestion d'utiliser un span vide comme moyen d'embarquer de la donnée sans qu'elle ne soit exposée dans les technologies assistives.
  • Jeremy Keith pour l'assistance au raffinement l'extension de donnée invisible pour l'extraction-valeur

Pages en Rapport

Retrieved from "http://microformats.org/wiki/index.php?title=machine-data-fr&oldid=34571"