xmdp-brainstorming-fr
Brainstorming XMDP
Authors
Ajoutez ici votre nom si vous produisez des contributions signifcatives sur cette page et souhaitez en assumer la responsabilité.
(traduction française Christophe Ducamp)
Introduction
Tantek Çelik a développé XMDP pour définir des extensions au XHTML comprenant des valeurs rel, des noms de classes et des <noms meta> de propriétés et valeurs. Selon la spec XMDP, un lien vers un microformat XMDP dans l'attribut profil de l'élément head indique que ce vocabulaire de microformat est formellement défini dans le document. Un parseur pourrait lire les valeurs d'attributs autorisées à partir du XMDP lié et de ce fait connaître explicitement quels microformats peuvent être utilisés, et quels noms de classes sont sensés convoyer quelles significations.
Cette page est pour explorer les additions / extensions possibles à XMDP.
Voir xmdp-faq et xmdp-problématiques pour les questions et problématiques.
Additions Possibles XMDP
résoudre quand les microformats peuvent être en utilisation
Actuellement l'existence potentielle de microformats dans un document peut être déclarée en référençant les URLs profils pour ces microformats dans l'attribut profil de l'élément head de ce document.
Une autre manière de faire serait d'inclure le <a rel="profile" href="XMDP URL">powered by microformat xyz</a> dans l'élément conteneur pour le microformat. La spec XMDP pourrait ensuite spécifier quand l'élément <a> est utilisé de cette façon, cela indique que le microformat est utilisé par l'élément contenant l'élément <a>.
Il existe néanmoins plusieurs problématiques claires avec cette proposition :
- Tous les microformats n'ont pas un élémentent conteneur. Considérez rel-tag un des microformats les plus largement utilisés.
- A un certain stade, le fait d'utiliser des microformats s'ajoute au coût d'écriture du document. C'est comme remplir un formulaire simplement pour écrire vos pensées. Mettre des éléments <a> avec chaque microformat ajoute des liens non désirés sur le sommet de cela.
identification du nom de classe racine
Ce serait tout à fait pratique pour les parseurs de microformats "génériques/universels" s'ils pouvaient lire un profil XMDP et comprendre lesquels des noms de classes définis sont des noms de classes racines pour les microformats, et de ce fait pouvoir distinguer ces limites d'objet.
Une simple idée serait que le premier nom de classe défini dans un profil (par ex hcard-profil) soit la classe racine pour ce microformat. Problèmes :
- Qu'en est-il d'un XMDP qui définit plusieurs microformats ?
- Qu'en est-il d'un microformat qui définit plusieurs noms de classes racines possibles (par ex. hCalendar permet "vcalendar" ou "vevent", hAtom permet "hfeed" ou "hentry") ?
faire un lien vers le XMDP
Comme signalé dans la noete sur "when microformats may be in use", il existe des méthodes additionnelles en discussion pour lier vers le XMDP en plus de la méthode actuelle d'utiliser l'attribut profils de l'élément head :
- Utiliser <link rel="profile" href="link to XMDP"/>. Cette méthode peut être utilisée maintenant et sera formalisée dans le XHTML 2.
- Un problème avec cette méthode est qu'elle exige (encore) un accès à l'élément head.
- Utiliser <a rel="profile" href="lien vers XMDP">powered by microformat xyz</a> dans le corps du document.
- comme noté par plusieurs personnes, cette approche a l'avantage supplémentaire de créer une opportunité marketing viral pour les microformats utilsiés. Par exemple, les développeurs pourraient ajouter des badges disant qu'ils utilisent le microformat xyz suggéré par l'exemple.
- Les environnements de publication de blogs vous permettent d'insérer des liens à la demande, ainsi cela obvie le besoin d'accès à l'élément head.
profils includes / aggregate
Les méthodes pour inclure une ou plusieurs valeurs, ou un XMDP entier dans un autre XMDP comme un moyen de créer un profil agrégé qui contient en fait des définitions provenant de plusieurs profils serait tout à fait utile. Elles permettraient aux documents avec des microformats de faire simplement référence à un URL profil plutôt qu'un ensemble séparé espace complet de tous les URLs profils des microformats qui peuvent être en utilisation.
aliaser le vocabulaire
Un document XMDP document pourrait être utilisé pour définir un profil microformat qui ne soit rien de plus qu'une simple correspondance dictionnaire entre un ensemble existant, non-standard de classes HTML et les définitions dans un profil microformat standard. Ceci permettrait aussi à un auteur de supporter un microformat donné en utilisant simplement l'URI d'un nouveau document profil comme la valeur d'un attribut/head de document individuel, plutôt que de modifier les valeurs individuelles de classes à travers chaque document pour se conformer à un profil existant. La suggestion initiale avec l'usage de la description de cas est dans ce microformats-discuss bilet. Note (extrait de la réponse de Kevin) ce que les attributs de classe HTML peuvent contenir plusieurs valeurs, par ex. class="post hentry", par conséquent un éditeur n'a pas à se débarasser de ses valeurs de classes existantes pour utiliser celles d'un microformat.
addition sous-classement / ontologie
On peut vouloir introduire une nouvelle propriété (ou valeur) et la baser sur une propriété existante (ou valeur). Dans ce XMDP échantillon, la valeur "self" est définie, basée sur la valeur "me" extraite de XFN 1.1 :
<dl class="rel"> <dt id='self'><a href="http://www.gmpg.org/xfn/11#me" rev="extends">self</a></dt> <dd>Ceci est un pointeur vers me, il agrandit la valeur "me" de XFN</dd> </dl>
Il existe deux pièces intéressantes qui ont été ajoutées, un URL avec une ancre vers un autre profil XMDP et un attribut rev. La valeur rev dans cet exemple est 'extends'. Ceci veut dire que la page fait référence aussi à elle-même, et que c'est augmenté par la propriété SEFL. Ainsi vous pourriez produire un XMDP qui liste tous les attributs rev possibles, 'extends', 'inverse', 'equivalent', etc. Puis vous pourriez 'aliaser' une propriété microformat vers une autre.
Un parseur/validateur/etc universel XMDP pourrait extraire la donnée à travers deux ou plusieurs profils XMDP et raisonner potentiellement entre eux. Ceci créerait une petite ontologie.
Il n'est pas clair si cette idée a véritablement une utilisé ou est simplement une solution cherchant un problème.
Schéma XMDP XML
Le lien montre un mauvaus exemple de créer XMDP à partir d'un schéma XSD. La grande question que je me pose est pourquoi ? Avoir XMDP défini dans XSD devrait faire que ce soit plus facile pour les machines de lire des Microformats, les reègles et la saisie stricte de données permettra aux Microformats d'être validés quand ils sont contenus dans un document XML/XHTML. Si un document utilise des microformats avec et XSD derrière de simples requêtes XPath peuvent être utilisées pour récolter l'information, ce peut être ensuite restitué vers du XML pour une traduction vers RDF ou tous les autres formats de transports XML.
XSD derrière XMDP a aussi des avantages distincts pour les auteurs de CMS, le XSD assis derrière xforms ou sxforms pour permettre la saisie de données à l'intérieur d'un CMS peut être utilisé pour générer du XMDP et des Microformats valides au moment de restituer le contenu. Ceci en théorie devrait faciliter pour les auteurs de CMS le développement d'un coeur sémantique autour des données avant d'exporter vers du XHTML + Microformats, RDF etc. et/ou faire que la requête de données via des webservices soit plus directe.
Relance
Ayant regardé les microformats un peu plus, je réalise la pauvreté de cet exemple ; néanmoins je pressens encore que placer un schéma derrière XMDP est un exercice qui en vaut la peine. Je ne me soucie pas de passer un peu de temps sur ça si quelqu'un pressent que c'est un exercice qui en vaille la peine, mais je proposerais ce qui suit :
- Définissez un ensemble lâche de conventions de microformats (par ex. une propriété méta sera liée à un attribut, etc.), et ayez ceux-ci définis dans un espace-nom microformat (mf:?).
- Créer un XSD pour des champs communs microformat sans structures (dtStart etc.), avec une saisie XSD et mf: rules (c'est à dire. mf:optional-html-attribute-binding="title" ou mf:html-attribute-binding="href" - les noms n'ont jamais été mon point fort)
- Commencer à travailler pour créer un schéma XSD incluant le schéma commun pour les spécifications agréées.
Il y aurait encore besoin de quelque forme de lien entre le XMDP et le XSD de définition (attribut profil ou élément lien ?). Avec ceux-ci en place il serait possible pour une application commet tails, ou à de nouvelles applications de choisir n'importe quel microformat dans une page et d'afficher les données, sans que l'application n'ait à être consciente du microformat standard spécifique.
Les microformats sont cools, tout particulièrement le fait que vous n'ayez pas besoin d'être un chercheur en fusées pour commencer à les utiliser. Néanmoins s'il peut y avoir un moyen d'interleaving l'adoption de microformats racines à l'intérieur de formes sémantiques plus complexes (RDF, etc.) à travers XML, alors ce serait obtenir un bonus ?