rel-tag-issues-fr

From Microformats Wiki
Jump to navigation Jump to search

Problématiques relTag

Il existe des problématiques soulevées à l'extérieur à propos des rel-tag avec des degrés de mérite très différents. Par conséquent, quelques problématiques sont REJETEES pour un certain nombre de raisons évidentes (mais encore documentées ici au cas où elles surviendraient de nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être amener à des modificatons ou améliorations dans la spécification. Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour une écriture allant vers la clarté, la plénitude, la rationnalité et aussi neutres en point de vue que possible. — Tantek

Problématiques

SVP, utilisez ce format :

  • AAAA-MM-JJ soulevées par NOMAUTEUR
    1. Problématique 1 : Voilà la première problématique que j'ai.
    2. Problématique 2 : Voilà la seconde problématique que j'ai.
  • problématique ouverte ! 2007-02-03 soulevée par Evan
    1. Il peut y avoir de la valeur à adopter, supporter ou commenter sur le format machine tags format en utilisation chez Flickr. Les tags Machine (appelés aussi triple tags) sont un format structuré de tag avec la syntaxe "namespace:property=value". Exemples: "geo:city=Portland". Il n'est pas clair de savoir comment les tags machines interagissent avec d'autres microformats ("geo:long=..." et "geo:lat=..." sont deux exemples couramment utilisés, qui chevauchent clairement geo), si d'autres sites et services supporteront les tags machines et comment les inclure ici.
  • problématique ouverte ! 2007-01-10 soulevée par Andy Mabbett
    1. J'ai récemment reçu une circulaire par email, demandant que les images et billets de blog à propos d'un événement particulier soient tagués dans le style :
20070110 AB123YZ postcode:uk=AB123YZ upcoming:id=123456 upcoming:event=19876 upcoming:venue=14567 url=example.com geocoded geotagged geo:lat=52.3456 geo:lon=-1.2345
Y'a t'il quelque travail à réaliser, pour documenter un tel "schéma" de tag. ? Andy Mabbett 12:43, 10 Jan 2007 (PST)
  • 2006-01-10 soulevées par Adam Willard
    1. Problématique 1 : En quelque sorte confuse. SVP soit réparez ou élaborez la différence dans les URLS dans l'aire Espace Tags. -> est-ce /tag/ ou /tags/ ou /wiki/. Est-ce que cette URI est modifiable ou est-ce simplement en train de montrer d'autres implémentations. Si c'est le cas, je suis confus sur l'implémentation. Est-ce que /wiki/ ne montre seulement que le contenu tagué de wiki ? Est-ce que les URIs devraient être construites comme /definition/ /blog/ etc... pour renvoyer ces items ? Ou est-ce simplement renvoyer des pages et le webmestre a juste décidé sur /wiki/ ou /tag/ ou /applicationdir/ ?
      • FAQ ACCEPTE - Nous avons besoin de faire de ça une entrée FAQ. RyanKing 14:46, 25 Jan 2006 (PST) (@TODO)
    2. Problématique 2 : Plus d'informations sur l'implémentation véritable d'un espace tag serait utile. J'ai écrit un système de tagging sur notre intranet et nous faisons tourner IIS. Aussi j'ai dû installer URLrewrite (ISAPI) pour créer l'URI /tag/tagnom.

Nous les horribles types Microsoft ne sommes pas aussi chanceux d'avoir Mod Rewrite.

      • REJETE NON PERTINENT - Implémenter un espace tag est bien en dehors des frontières de la spécification rel-tag. --RyanKing 14:46, 25 Jan 2006 (PST)
  • open issue! 2007-01-01 soulevée en Jan 2006 par Ben Buchanan sous limitations of rel="tag" microformat
    1. Résumé : Sous la proposition actuelle, les tags et les espaces tags pertinents sont potentiellement difficiles à créer ; et il est encore facile d'abuser le système. Les humains peuvent être encore dupés et aussi les machines. C'est une spec géniale si vous arrivez à avoir une structure de répertoire compatible, mais si votre site ne correspond pas alors soit vous recréez tout votre système... ou plus probablement, vous conseillez malheureusement au client que les tags n'arrivent pas.
  • 2006-02-09 soulevées par JonathanFeinberg
    1. Problématique 1 : C'est bizarre d'avoir le tag annoté par l'URL. Le contenu du tag a est un endroit parfaitement adapté pour contenir le tag.
      • REJETE, IGNORE PRATIQUE ETABLIE. Flickr et del.icio.us et d'autres sites de tagging ont installé le standard defacto d'avoir le terme tag annoté par le dernier segment dans l'URL. rel-tag a été conçu pour influencer ce comportement existant. Les arguments théoriques sur la pertinence ne sont pas appropriés du fait d'une pratique existante et très débordante.
    2. Problématique 2 : Il n'y a pas moyen de distinguer entre une notion d'utilisateur individuel et un tag global (cad. le tag java de Fred versus toutes les choses taguées avec java.
      • REJETE FAUX. FAQ ACCEPTEE. Les espaces tag (voir spécification rel-tag) sont utilisés pour distinguer, par ex. Flickr fait ça avec les photos provenant d'un utilisateur avec un tag, vs. photos provenant de tous les utilisateurs avec un tage. to-do - ajouter ça aux rel-tag.
    3. Problématique 3 : Ce n'est pas raisonnable de restreindre l'implémentation REST de l'hébergeur selons cette idée de spec. plutôt limitée d'un "bon" URL tag. L'idée de tags comme paramètres de requête est rejetée sans justification, par exemple.

Les paramètres de requête sont un moyen parfaitement légitime d'état annoté.

      • REJETE, IGNORE PRATIQUE ETABLIE. Flickr et del.icio.us et d'autres sites de tags ont établi le standard de facto d'avoir le terme tag annoté par le dernier segment dans l'URL et par conséquent ont défini ce qui fait un "bon" URL tag. rel-tag a codifié cette bonne pratique.
  • 2006-02-09 soulevées par Robert Yates
    1. Problématique 1 : Ainsi je travaille aux côté de Jonathan chez Lotus / IBM et nous avons plusieurs systèmes en développement chacun avec sa propre implémentation de tag. Tous ont leurs propres pages qui sont dédiées

pour lister les choses qui ont été taguées par un tag donné. Quelques-uns de ces systèmes utilisent une notation url qui se finti par /tag mais beaucoup (la majorité) ne le font pas. Nous cherchons à avoir une manière standard que ces systèmes puissent taguer sémantiquement leurs tages et reltag semble très prometteur. Néanmoins, compte tenu du fait que quelques-uns des systèmes produisent des urls tag qui ne finissent pas par /tag nous sommes un peu dérangés. Ce serait extrêmement difficile et en quelque sorte impraticable de faire que tous ces groupes s'assurent que leurs urls de tag se finissent pas /tag. Etes-vous en train d'imaginer une autre approche. Nous aimerions utiliser relTag dans nos produits, mais pour le moment nous ne le pouvons pas. A la recherche de quelque aide / orientation.

      • Clarification : Par '/tag' voulez-vous dire '/<tag-name>'? --RyanKing 15:21, 9 Feb 2006 (PST)
        • oui -- rob yates 18:56, 9 Feb 2006 (EST)
      • Je voulais faire une étude rapide pour voir combien d'autres sites se battraient pour adopter facilement ce format, du fait qu'ils

ne finissent pas actuellement leurs urls tag par '/<tag-name>'. Bien que je sois finalement d'accord sur le fait que finir par '/<nom-tag>' est une bonne pratique, je pressens que leurs exigences à être une option pour les sites qui ne font pas ça, mais veulent encore sémantiquement taguer leurs tags. Voilà quelques sites que j'ai trouvés et qui ne peuvent pas facilement adopter le reltag sans retravailler la logique côté serveur. Il y a quelques grands noms sur cette liste.


  • 2006-04-06 soulevée par Evan
    1. L'étendue dit que 'rel="tag" est spécifiquement conçue pour "taguer" du contenu, généralement des pages web (ou des portions de celui-ci, comme des billets de blog).',

mais il n'est pas clair comment associer un tag à une portion d'une page web et pas une autre. Quelques cas communs : galeries de photos, billets de blogs, répertoires de pages jaunes, répertoires de hcard, listes de bookmarks style-del.icio.us. Est-ce que le tag s'applique à l'élément de <a> contenant ? Tous les éléments contenant ? Une possibilité que je suggère : le tag s'applique à l'élément le fermant juste après avec un attribut "id" (adressable, au moins en XHTML, comme #idval), ou à la page entière s'il n'existe pas un tel élément. Une autre possibilité est d'avoir une classe tagtarget, de façon à ce que le parent avec cette classe-là soit l'objet étant tagué.


  • 2006-11-24 soulevée par Andy Mabbett
    1. Pourquoi ne pas permettre aussi de taguer des liens dans une page (par ex après "#" tout comme après "/") ? Ensuite, si j'ai une page avec des sous-sections, chacune de celles-ci seraient un tag, selon son ID :
<ul class="navbar">
<li><a href="#whisky" rel="tag">Whisky</a></li>
<li><a href="#vin" rel="tag">Vin</a></li>
</ul>
[...]
<h2 id="whisky">"Whisky</h2>
[...]
<h2 id="vin">"Vin</h2>
[...]
  • 2006-11-25 soulevée par Andy Mabbett
    1. Une attention devrait être portée au moment de recommander Wikipedia comme un espace-nom. Par exemple, un article à propos de Birmingham, Alabama, tagué avec un lien vers http://fr.wikipedia.org/wiki/Birmingham lierait vers un article traitant de Birmingham, Angleterre. De la même manière, un tag utilisant http://wikitravel.org/en/Newcastle liera vers une page de dés-ambiguation.
  • 2005-06-21 soulevées par Hixie
    1. Problématique H-1 : Cette spécification manque d'une section de conformité agent utilisateur. Est ce que l'AU crawle simplement le DOM en cherchant tous les <html:a> elements avec un attribut "rel" qui contient un mot-clé "tag" (après le découpage de la séparation espace) et puis saisit la valeur href="" ?

Que penser des liens relatifs ? Est-ce qu'ils doivent implémenter xml:base ? <html:base> ? D'autres choses ?

    1. Problématique H-2 : Quel est le problème ? Est-ce que la recherche texte-libre n'est pas plus efficace que de compter sur les personnes pour placer un tag particulier ?

Pages en rapport

La spécification rel-tag est un chantier en cours. Au fur et à mesure que des aspects sont discutés, compris et écrits, ils seront ajoutés. Ces idées, problématiques et questions sont maintenues sur des pages séparées.

Retrieved from "http://microformats.org/wiki/index.php?title=rel-tag-issues-fr&oldid=37146"