hcalendar-issues-fr

From Microformats Wiki
Jump to navigation Jump to search

Problématiques hCalendar

Ce sont des problématiques externes sur hCalendar avec différents degrés de mérite. De ce fait, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont exprimées à nouveau), et d'autres qui contiennent des discussions plus longues.

IMPORTANT : Lisez SVP les FAQ hCalendar avant de donner toute réaction ou soulever quelque problématique parce que vos réactions/quetions peuvent déjà avoir été résolues/fait l'objet d'une réponse.

Les problématiques proposées peuvent (et le seront probablement) éditées et récrites pour une meilleure concision, clarté, rationalité et rester sur un point de vue aussi neutre que possible. Formulez bien vos problématiques. — Tantek

Ajoutez SVP vos nouvelles problématiques en haut de la liste. Relancer SVP vers les problématiques résolues/rejetées avec de nouvelles information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques en doublon seront réinitialisés.

Voir problématiques hCard en rapport.


Problématiques

Ajoutez de nouvelles problématiques en haut de la liste :

  • problématique ouverte ! 2007-05-12 Un point pertinent extrait de la version du 22 février 2007 des problématiques hCalendar. Vaut la peine d'être conservé et résolu :
  • problématique ouverte ! 2007-01-20 soulevée par Andy Mabbett
Là où DTEND est une date, et non une date-time, il est requis que ce soit le jour après la fin de l'événement, par conséquent : <abbr class="dtend" title="2007-04-30">29 avril 2007</abbr>. Néanmoins, "29 Avril 2007" n'est pas une abréviation de 2007-04-30 ; c'est une abréviation de 2007-04-29. Le balisage comme montré est sémantiquement incorrect et sujet probablement à problèmes pour les utilisateurs ou agents utilisateurs qui utilisent l'attribut 'title', et non la valeur texte, de l'élément abbr.
Webf2 23:23, 11 May 2007 (PDT)
  • La date ISO 2007-04-30 est directement équivalente à 2007-04-30 00:00:00, ce qui est la raison pour laquelle elle est utilisée à l'heure de fin d'un événement arrivant le 2007-04-29. Dans ce contexte plus complet vous pouvez alors visualiser cela comme une abréviation de 'la fin du 29 avril 2007'. Les auteurs peu à l'aise avec ça pourrait utiliser <abbr class="dtend" title="2007-04-29 23:59:59">29 avril 2007</abbr>, ou être plus spécifique avec leurs horaires.
Ciaran McNulty 09:21, 12 May 2007 [GMT]
  • This certainly risks confusion. The abbr title includes different information than the content; different when read by a 'normal' user who does not know about the exclusive-end-date.
  • Le problème va se passer avec les dates (plutôt que les dates-times). L'attente utilisateur est différente qi vous parler de "3 heures", ce qui est vraiment un point dans le temps, et de 29 avril, quelque chose qui dure 24 heures. Pas de problème pour dire qu'une heure de fin est 'exclusive', mais une date de fin peut être et est généralement inclusive.
  • Utiliser un dtend plus précis est simplement un contournement, vous pourriez ne pas vouloir dire la seconde à laquelle un événement se finit (comme dans 2007-04-29 23:59:59). Vous pourriez facilement vouloir dire que cela tourne du Mercredi au Vendredi sans vous engager sur des horaires préciss - ou que l'événement soit parfois sur ce vendredi mais vous ne savez pas quand.
Les options possibles pourraient être :
  • Inclure une note dans le standard qui aille en marquage contradictoire tel que
<abbr class="dtend" title="2007-04-30">29 avril 2007</abbr>
mauvais en pratique et devrait être évité
  • Faire un break avec l'usage ical que le fait que les dates de fin soient exclusives.
  • Clarifier le sens :
<abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 Avril 2007</abbr>
<abbr class="dtend" title="value=exclusive:2007-04-30">29 avril 2007</abbr>
ou peut-être
<abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 avril 2007</abbr>
Webf2 00:25, 13 May 2007 (PDT)
  • problématique ouverte ! 2007-01-07 soulevée par Webf
    1. "A la recherche d'un mécanisme pour spécifier un dtstart sans utiliser <abbr>. Ce serait utilisé où il existe un certain nombre d'événements (comme dans les listes d'événéments de Webfeet) où vous ne voulez pas avoir la date visible répétée."
      • abbr est le seul élément correct à utiliser, à moins que vous ne souhaitiez afficher le date-time brut ISO-formaté pour l'utilisateur. Utilisez-le avec l'include-pattern, ce qui donne :


	<dt id="D20070120">
		<abbr class="dtstart" title="20070120">
		Samedi 20 janvier 2007
		</abbr>
	</dt>
	<dd>
		<span class="vevent">
		<object class="include" data="#D20070120"></object>
		[Détails du premier événement]
		</span>

		<span class="vevent">
		<object class="include" data="#D20070120"></object>
		[Détails du second événement]
		</span>
	</dd>

mais notez svp que vous devriez valider votre HTML - il a plus de 3000 erreurs ! le nombre élevé de nombre de microformats hCalendar (>500) amène les parseurs comme Tails de Firefox et Operator à répondre très lentement. Vous devriez utiliser CSS, des espaces non cassés et de nombreux sauts de lignes pour metter en page votre page - ceci réduira sa taille et permettra aux parseurs de travailler plus rapidement. Vous aurez besoin de styler object .include en display:none Andy Mabbett 04:10, 16 Jan 2007 (PST)
  • problématique ouverte ! 2006-10-21 soulevée par AndyMabbett
    1. "Il devrait y avoir quelque moyen de dire que l'URL d'une hCard ou d'un événement hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même."
  • problématique ouverte ! 2006-09-22 soulevée par AndyMabbett
    1. "Commment sont affichées les dates Julian ? A la limite de ce que je connais, ISO8601 n'a pas de facilité pour baliser les dates Julian, ainsi la forme 
      <abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr>
      serait utilisée ? Si oui, ce devrait être indiqué par un exemple."
  • problématique ouverte ! 2006-08-14 soulevée par Elias Sinderson
    1. Problématique 1 : Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une note technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la spéc HTML 4.0 utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types xsd:date et xsd:dateTime sont spécifiés comme étant le froamt étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
  • problématique ouverte ! 2006-03-07 soulevée par Justin McDowell
    1. Problématique 1 : j'aimerais voir une liste de propriétés, similaire à celle qui est vue sur la spec hCard, qui liste toutes les propriétés disponibles et sous propriétés dans une liste jolie et compacte. Ceci me ferait gagner beaucoup de temps et s'avère vraiment utile pour faire rapidement et facilement connaissance avec les possibilités de vCalendar.
  • 2006-02-17 soulevée par Mark Mansour - les remarques sont résumées ici
    1. Est-ce que vcalendar devrait être une classe ? La section 4.4 de RFC2445 dit : "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Aussi la classe vcalendar permettrait des propriétés sur le calendrier lui-même telles que METHOD et CALSCALE (Je ne pense pas que VERSION et PRODID soient particulièrement pertinents).
      • SPEC. UPDATE/FAQ ACCEPTEE Est-ce un cas de réparer qeulque chose qui n'est pas cassée ? Remarquez que "iCalendar object" != "vcalendar".

Ceci est un peu confus aussi lisez calmement et avec attention la RFC 2445 à cet égard. En outre, la spec. hCalendar dirait *précisément* comment générer des propriétés VCALENDAR en son absence.

    1. Comment vont se comporter les axes et en-têtes  ?
      • ACCEPTE. Ceci est documenté dans le hcalendar-brainstorming-fr mais DOIT être migré vers le propre hCalendar parce que les éditeurs et implémenteurs se sont tous mis d'accord là-dessus (il y a des mois). Ajoutez ceci comme une to-do pour Tantek.
    2. Il y a eu une discussion que l'axe de la table et les en-têtes devraient être utilisés pour saiir l'information du calendrier sous une format plus compact, mais aucun exemple n'est disponible. Est-ce quelqu'un aurait des exmples ou devrions-nous essayer d'en inventer quelques-uns ?
    3. Les composants embarqués devraient-ils être autorisés ? RyanKing a déjà remarqué que vJournal chevauche les billets de blog (même si ce n'est pas toujours accepté à cette heure), mais les composants to-do, free/busy, timezone, alarms devraient-ils être acceptés ?

Ils ont tous imaginé cela comme aussi pertinent par la spec ical parce que les événements se déroulent (mon implémentation).

      • SPECUPDATE/FAQ - ACCEPTEE. une autre to-do pour Tantek.

Spécifiez explicitement quels sont les objets iCalendar (en plus de VEVENT) qui sont permis dans hCalendar. Candidats actuels en plus : VTODO (plein d'exemples de cette information sur le web), VFREEBUSY (déjà au moins sur un site de publier cette info), VALARM (peut-être, me semble grossier, mais sans une exigence du vrai monde pour utiliser le cas que nous devrions probablement ometre). Actuellement en cours de dépose : (construction horrible), VJOURNAL (démodé par hAtom).

    1. Validation des tests hCalendar. Les tests de hCalendar ont été rendus disponibles depuis un moment, mais seu Brian Suda et moi avons produit des contributios à leurs contenus. Est-ce que quelqu'un d'autre saurait des idées et devrions-nous essyar de faire que ces idées-là et devrions-nous essyer de les produire pour produire des tests 'officiels' de tests hCalendar ?
      • ACCEPTATION PARTIELLE. Nous avons probablement d'un validateur hCalendar avant que nous ne déclarions quelque collection de tests pour que ce soit officiel.
    2. L'utilisation de fragments n'est pas claire. L'interprétation de fragments semble être dépendante de l'agent. Les fragments annoncent généralement un titre ou une balise, comme une déclaration goto pour HTML. Malheureusement, cela peut sauter au milieu des éléments (plutôt que vers le début d'un élément). Comment cela devrait-il être géré. par ex :
<a name="myfrag">Titre</a>
<div class="vevent">
  <div class="description">Un bel événement</div>
  <abbr class="dtstart" title="2005-10-05">5 octobre</abbr>
</div>
      • ACCEPTEE. Nous devrions clarifier aux convertisseurs comment interpréter un fragment id. Les interprétations sont toutes cohérentes. Cela pointe vers l'élément qui doit être converti. Si cet élément est vide alors ainsi se fait la conversion. Il n'y a pas de problématique ici autre qu'un besoin pour plus de documentation.
  • 2006-02-01 soulevée par RyanKing
    1. Problématique 1 : Du fait que maintenant, ou plus tard nous aurons hAtom, devrions-nous ne plus permettre vJournal, afin que nous n'ayons pas deux formats de billets de blogs ?
      • ACCEPTEE. Oui, nous devrions explicitement ABANDONNER "vjournal" venant de hCalendar.
  • 2006-01-04 soulevée par CGranade
    1. Les interactions avec de solide espace-nom. A ce stade il semble que hCalendar ne puisse pas être embarqué dans des schémas non-XHTML qui sont aussi solidement sous espaces-noms (par ex. : RDF, Atom) sans une erreur résultante de validation, parce que l'attribut class n'est pas portable à travers les schémas.
      • REJETEE. L'attribut class est utilisé sur les éléments XHTML, qui sont XML, qui peuvent être embarqués dans tout autre XML. La problématique telle que posée ne fait pas de sens.
    2. Tous les exemples en XHTML. XHTML ne devrait pas être l'unique hébergeur vers les microformats, et de ce fait il ne devait pas être l'unique exemple de langage hôte. A la place de cela, des exemples dans Atom, RSS, RDF, etc. devraient être aussi fournis.
      • ACCEPTEE. Ceci est définitivement quelque chose à ajouter aux *-pages d'exemples pour chaque microformat.
  • 2005-10-14 soulevée par MarkoMrdjenovic
    1. UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. RFC recommends use of addr format for uids which is problematic in html id (does not validate). HenriBergius pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org
      • ACCEPTEE-PARTIELLEMENT. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
    2. DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.
      • ACCEPTEE. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
    3. Here is an example from Midgard CMS (which will be easy to change according to bergie on irc): 
  <li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
    <abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
    <abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
    <a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
        <span class="summary">From the other cal</span>
    </a>
    <abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
  </li>
  • 2005-09-29 soulevée par RyanKing
    1. How does one use ATTENDEE?
      • ACCEPTEE. Another to-do for Tantek - document how to use ATTENDEE with hCard.
  • 2005-07-27 raised by Paolo Massa
    1. I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<a class="url" href="http://www.web2con.com/">

Web 2.0 Conference:

...

I hope to have been clear but I'm not so sure ;-)


  • 2005-07-21 soulevée par Neil Jensen
    1. should we create a vfreebusy class for HTML representations of freebusy data? Discussion on hCalendar brainstorming. Additional background: here.
  • 2005-07-11 soulevée par Kragen
    1. La spécification class="url" telle que <a href="..."> devrait être un "should", et non un "must". D'autres moyens de référencer l'URL event, comme <iframe src="..."> et <embed src="...">, devraient être mentionnées. A ce jour X2V ne semble pas les gérer. Ceci provient d'une discussion à propos de xFolk.
      • REJETEE. Manque de cas d'utilisation. Nous ne devrions pas ajouter de "moyens supplémentaires de référencer l'URL event" à moins que vous ne puissiez présenter un exemple concret du vrai monde sur le web qui l'exige.
  • 2005-06-21 soulevée par Hixie
    1. Issue H-1 : Cette spécification manque d'une section agent utilisateur. Il n'y a basiquement rien qui dise comment les hCalendars doivent être parsés, comment gérer les erreurs et ainsi de suite. Elle est définie en termes de DOM ? Est-elle définie en termes de sérialisation ? Comment gérer le contenu inattendu ou le contenu manquant ?
  • 2005-02-22 soulevée par Matt Raymond sur la liste whatwg:
    1. Il n'y pas de déclaration de copyright et pas de déclaration de brevets.
      • ACCEPTEE. J'ai mis à jour hCalendar (et hCard, et tous les autres microformats) avec une déclaration de copyright standard et une déclarationd e brevet.
  • 2005-02-18 soulevée par Matt Raymond on the whatwg list:
    1. Il n'y a pas moyen pour quelqu'un de lire le marquage pour dire si un nom de classe est le nom d'un attribut ou simplement le nom d'une classe utilisée pour la mise en forme.
      • REJETEE (strawman, hypohtèse pauvre). Il n'y a pas besoin de différencier dans le cas général. Dans le cas spécifique, un vocabulaire est défini à l'intérieur d'un contexte.
    2. As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).
      • REJETEE (hors du sujet). Les propriétés extension sont en dehors du champ actuel de hCalendar.
    3. L'utilisation de pour les dates est incorrect. "August 5th, 2004" n'est pas l'abréviation de 2004-09-05. En fait, le contraire est plus proche de la vérité.
    4. Vous devez créer un ensemble complexe de règles pour toutes les utilisations possibles d'un marquage légal dans qui puisse être facilement implémenté incorrectement.
      • REJETE (déclarations fausses, strawman). Pas de marquage légal. Pas besoin de créer des règles pour toutes les utilisations possibles de marquage légal. pas besoin de créer un ensemble de règles complexes.
    5. Il existe des problématiques de stylisation et de tooltip qui restent non résolues.
      • REJETEE (déclarations vides). Voir hCalendar FAQ pour les réponses aux questions concernant la stylisation et les tooltips. Autrement, soulevez svp des problématiques spécifiques avec des exemples valides et clairs.
    6. hCalendar/hCard est plus compliqué pour les webmestres à lire et comprendre et plus compliqué pour les développeurs à mettre en place.
      • REJETEE (déclarations invalides, comparateur invalide). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
    7. I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.
      • ACCEPTEE-PARTIELLEMENT. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay A Touch of Class. And yes, class names can and should be used for user-defined semantics. hCalendar is one such user, and it is reasonable for users to use each others class names.
      • Would it be more in the spirit of HTML to define these classes in a metadata profile, so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of microformats specifications in general? (If not, why not?)
        • ACCEPTEE. Yes, all microformats that introduce new classnames SHOULD include an XMDP profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
          • Ok, but in order to refer to a profile, it needs a URI. Tantek writes in a message of Jul 21 "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?
            • ACCEPTEE. voir profile-uris ; ceci est une migration à partir de la liste to-do de Tantek, pour que les deux puissent fournir des probils d 'auteurs amateurs et d'URLs (probablement sur gmpg.org) pour ces profils sur hCalenar.
  • problématique ouverte ! 2006-04-10 raised by Scott Reynen.
    1. Quand quelqu'un cherche des pages hCalendar, on ne voit pas de collection de publication du vrai monde de données événements ni de discussion des propriétés implicites par de tels exemples, je pense que c'est bien plus facile d'inférer que les microformats proviennent d'autres formats plus que des comportements véritables. Il n'y a rien dans le processus ni dans les pages hCalendar expliquant ce décalage. J'argumenterais qu'il devrait y avoir une explication, probablement dans les deux lieux.
  • problématique ouverte ! 2006-04-13 soulevée par Tantek
    1. Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans hCard pour documenter comment publier / gérer la propriété METHOD et potentiellement d'autres. Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir hCalendar vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un METHOD:PUBLISH par défaut sur l'objet VCALENDAR dans le flux résultant .ics.

Gabarit

Utilisez svp ce format :

  • {{OpenIssue-fr}} AAAA-MM-JJ soulevée par NOMAUTEUR
    1. Problématique 1 : Voici la première problématique que j'ai .
    2. Problématique 2 : Voici la seconde problématique que j'ai .


Pages en rapport

Cette spécification est un chantier en cours. Au fur et à mesure que les aspects additionnels sont discutés, compris et écrits, ils seront ajoutés. Ces idées et questions sont maintenues sur des pages séparées.

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