Difference between revisions of "dtend-issue-fr"

From Microformats Wiki
dtend-issue-fr
Jump to navigation Jump to search
m
m ([fr:sync'd with original])
Line 4: Line 4:
  
 
== résumé ==
 
== résumé ==
 
 
La propriété dtend [[hcalendar-fr|hCalendar]] de hCalendar 0.1. requiert que les dates de fin soient marquées comme arrivant un jour complet après ce que les personnes considèrent généralement comme la fin de la date d'un événement.
 
La propriété dtend [[hcalendar-fr|hCalendar]] de hCalendar 0.1. requiert que les dates de fin soient marquées comme arrivant un jour complet après ce que les personnes considèrent généralement comme la fin de la date d'un événement.
  
Line 28: Line 27:
  
 
== solutions possibles ==
 
== solutions possibles ==
As noted in the [[hcalendar-issues#issues_2007|issue description]] on the hCalendar issues page, there are at least a couple of possible solutions.
+
Comme noté dans la [[hcalendar-issues#issues_2007|description du problème]] sur la page problématiques hCalendar, il y a au moins quelques solutions possibles.
  
 +
=== dtend dates incluses ===
 +
{{ResolvedIssue-fr}}
 
<div class="discussion">
 
<div class="discussion">
* '''nouvelle propriété hCalendar 1.0.1 pour les dates de fin'''. As noted in the first resolution of the issue, we could introduce a new property, '''dtlast''' (described more in [[hcalendar-brainstorming#dtlast|hCalendar brainstorming: dtlast]]) which authors would use to specify the ''last'' day of an event, instead of dtend.
+
* '''redéfinir dtend hCalendar 1.0.1 pour être incluse pour les dates globales'''.
** Advantage: Maintains iCalendar conceptual compatibility for DTEND values.
+
** Avantage : Zéro impact sur le vocabulaire.
** Advantage: Compatibility with existing hCalendar 1.0 content that just happened to get the end date +1 distinction right.
+
** Avantage : Pas d'augmentation de la complexité à publier hCalendar.
** ... any other advantages?
+
** Avantage : Reflétera l'usage dominant de dtend dans les exemples dans la jungle, (plus de recherche et citations demandées). En d'autres mots, les auteurs on DEJA utilisé dtend en supposant que ça fonctionne de cette façon (dates de fin incluses), et seront en fait surpris de trouver que ce ne l'est pas. Faire ce changement à la sémantique DtEND peut en fait refléter plus la réalité de publication hCalendar que de conserver la sémantique précise du DTEND iCalendar. <strong id="existing-inclusive">Exemples d'usage de dtend incluses dans la jungle :</strong>
** Disadvantage: Increased vocabulary. '''dtlast''' is a new term, even if it is not new functionality. Essentially this puts additional burden on authors.
+
*** http://barcamp.org/ - BarCamp wiki, dates pour les BarCamps
** Disadvantage: Increased complexity/confusion. When to use dtend vs. dtlast?  hCalendar authors would now have to remember, use dtend for end *times* and dtlast for end *dates*. More explanation of the additional burden on authors.
+
*** [[événements|microformats.org/wiki/events/]] - plusieurs événements sur plusieurs jours, comme celui récemment de Glenn Jones (qui se décrit lui-même comme un développeur "très" connaisseur et prolifique de microformats) [[events/2010-03-12-sxsw|la page événement SXSW 2010]] utilise des DTEND incluses, (notamment un élément span qui ne fait PAS de contenu dupliqué).
** ... any other disadvantages?
+
*** la version draft du livre d'Emily Lewis <cite>Microformats Made Simple</cite>, utilise dtend pour les dates de fin incluses.
** Opinions:
+
*** La [http://simplebits.com/ page personnelle de Dan Cederholm SimpleBits] connaisseur et expert a un calendrier événements qui utilise des dates incluses dtend.
*** -1 despite originally proposing this solution, I now think an additional term, and rule for when to use the new term vs. the old term will actually make this problem worse and more confusing to web authors. [[User:Tantek|Tantek]]
+
*** http://upcoming.org (apparemment selon  Michael Kaply)
*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
+
*** ... plus d'instances de l'usage existant de DTEND pour des dates de fin *incluses*.
* '''redefine hCalendar 1.0.1 dtend to be inclusive for whole dates'''.  This is a bit more radical.
+
** Avantage : Bon nombre d'implémentations traitent les dates DTEND comme *incluses* (techniquement celles-ci violent la spec hCalendar en cours, mais elles peuvent délibérément faire ainsi pour refléter les pratiques de publication hCalendar actuelles). Implémentations :
** Advantage: Zero impact on vocabulary.
+
*** le validateur Rich Snippet de Google. Le  [http://www.google.com/webmasters/tools/richsnippets?url=http%3A%2F%2Fmicroformats.org%2Fwiki%2Fevents validateur Rich Snippet sur microformats.org/wiki/events] montre l'événement SXSW comme se finissant le 2010-03-16, ce qui est cohérent avec l'intention de publication.
** Advantage: No increase to hCalendar authoring complexity.
+
*** ... plus d'implémentations qui traitent les dates dtend hCalendar comme incluses
** Advantage: Will reflect dominant use of dtend in examples in the wild (more research and citations needed to back this up!). In other words, authors have ALREADY been using dtend assuming it works this way (inclusive end dates), and will actually be surprised to find out that it doesn't. Making this change to DTEND semantics may actually reflect hCalendar publishing reality more than keeping the precise iCalendar DTEND semantic. Examples of inclusive dtend usage in the wild:
+
** ... autres avantages ?
*** http://barcamp.org/ - BarCamp wiki, dates for BarCamps
+
** Inconvénients : Redéfinit DTEND pour être *légèrement* différent de la façon dont il est défini dans iCalendar. Ceci peut mener à des erreurs de la part des développeurs.
*** [[event|microformats.org/wiki/events/]] - several multi-day event listings, as recently as Glenn Jones (who himself is a ''very'' knowledgable and prolific microformats developer) [[events/2010-03-12-sxsw|event page for SXSW 2010]] use inclusive DTENDs (notably, using a span element that does NOT duplicate content).
+
*** Mitigation : it may be possible to mitigate this disadvantage by providing ''both'' very precise hCalendar to iCalendar processor conformance requirements, and sufficient test cases for hCalendar to iCalendar processors for them to get this correct in their code.
*** draft of Emily Lewis' book <cite>Microformats Made Simple</cite>, uses dtend for inclusive end dates.
+
** Inconvénients : breaking some amount of existing hCalendar content on the web (research needed to determine the extent of the problem)
*** microformats.org co-founder and expert [http://simplebits.com/ Dan Cederholm's home page] has an events calendar that uses inclusive dtend dates.
 
*** ... more instances of existing use of DTEND for *inclusive* end dates.
 
** Advantage: Some number of implementations treat DTEND dates as *inclusive* (technically these are violating the current hCalendar spec, but they may be doing so deliberately to reflect actual hCalendar publishing practices). Implementations
 
*** Google's Rich Snippet validator. The [http://www.google.com/webmasters/tools/richsnippets?url=http%3A%2F%2Fmicroformats.org%2Fwiki%2Fevents Rich Snippet validator on microformats.org/wiki/events] shows the SXSW event as ending on 2010-03-16, consistent with the published intent.
 
*** ... more implementations that treat hCalendar dtend dates as inclusive
 
** ... any other advantages?
 
** Disadvantage: Redefines DTEND to be *slightly* different from how it is defined in iCalendar. This may lead to errors on the part of developers.  
 
*** Mitigation: it may be possible to mitigate this disadvantage by providing ''both'' very precise hCalendar to iCalendar processor conformance requirements, and sufficient test cases for hCalendar to iCalendar processors for them to get this correct in their code.
 
** Disadvantage: breaking some amount of existing hCalendar content on the web (research needed to determine the extent of the problem)
 
 
*** Workarounds: Based on aforementioned research, workarounds may be possible, e.g. heuristics for when abbr is used similar to the example at the top of the page, to detect "off by one" cases and accommodate accordingly). Make it an explicit error for the human visible date to be different than the machine parsed date, and state specific error handling rules for hCalendar processors that "repair" this problem.
 
*** Workarounds: Based on aforementioned research, workarounds may be possible, e.g. heuristics for when abbr is used similar to the example at the top of the page, to detect "off by one" cases and accommodate accordingly). Make it an explicit error for the human visible date to be different than the machine parsed date, and state specific error handling rules for hCalendar processors that "repair" this problem.
 
** ... any other disadvantages?
 
** ... any other disadvantages?
** Opinions:
+
** Opinions :
 
*** +1 Based on the fact that this problem just hasn't gone away, and that people (smart knowledgable people!) continue to treat "dtend" end dates *inclusively*, I now think it makes more sense (and is more practical) to change the spec to be consistent with the dominant expectation of web authors, rather than continue attempting to change the expectations of web authors to be consistent with the spec. I think this is the simplest, most effective, and least risky option. [[User:Tantek|Tantek]]
 
*** +1 Based on the fact that this problem just hasn't gone away, and that people (smart knowledgable people!) continue to treat "dtend" end dates *inclusively*, I now think it makes more sense (and is more practical) to change the spec to be consistent with the dominant expectation of web authors, rather than continue attempting to change the expectations of web authors to be consistent with the spec. I think this is the simplest, most effective, and least risky option. [[User:Tantek|Tantek]]
 
*** +1 This appears logical and intuitive. We are effectively saying that end dates such as <code>DTEND</code> should parse to <code>YYYY-MM-DDT24:00:00</code>, and not <code>YYYY-MM-DDT00:00:00</code>. Seems simple, and entirely logical from a publishing stand —[[User:BenWard|BenWard]] 08:18, 27 August 2009 (UTC)
 
*** +1 This appears logical and intuitive. We are effectively saying that end dates such as <code>DTEND</code> should parse to <code>YYYY-MM-DDT24:00:00</code>, and not <code>YYYY-MM-DDT00:00:00</code>. Seems simple, and entirely logical from a publishing stand —[[User:BenWard|BenWard]] 08:18, 27 August 2009 (UTC)
Line 68: Line 60:
 
*** +1 I agree with MatthewLevine. Those who follow hCalendar development are likely to make the change to inclusive dates, and those who don't are likely using inclusive dates already. [[User:Chris Cressman|Chris Cressman]]
 
*** +1 I agree with MatthewLevine. Those who follow hCalendar development are likely to make the change to inclusive dates, and those who don't are likely using inclusive dates already. [[User:Chris Cressman|Chris Cressman]]
 
*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
 
*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
* ... other possible solutions?
 
 
</div>
 
</div>
 +
 +
==== Tests de cas avec dtend incluse ====
 +
Tests de cas qui vérifient l'implémentation de cette résolution de problème :
 +
* http://ufxtract.com/testsuite/hcalendar/hcalendar1.htm
 +
* ...
 +
 +
=== nouvelle propriété pour dates de fin ===
 +
<div class="discussion">
 +
* '''new hCalendar 1.0.1 property for end dates'''. As noted in the first resolution of the issue, we could introduce a new property, '''dtlast''' (described more in [[hcalendar-brainstorming#dtlast|hCalendar brainstorming: dtlast]]) which authors would use to specify the ''last'' day of an event, instead of dtend.
 +
** Advantage: Maintains iCalendar conceptual compatibility for DTEND values.
 +
** Advantage: Compatibility with existing hCalendar 1.0 content that just happened to get the end date +1 distinction right.
 +
** ... any other advantages?
 +
** Disadvantage: Increased vocabulary. '''dtlast''' is a new term, even if it is not new functionality. Essentially this puts additional burden on authors.
 +
** Disadvantage: Increased complexity/confusion. When to use dtend vs. dtlast?  hCalendar authors would now have to remember, use dtend for end *times* and dtlast for end *dates*. More explanation of the additional burden on authors.
 +
** ... any other disadvantages?
 +
** Opinions:
 +
*** -1 despite originally proposing this solution, I now think an additional term, and rule for when to use the new term vs. the old term will actually make this problem worse and more confusing to web authors. [[User:Tantek|Tantek]]
 +
*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
 +
</div>
 +
 +
=== autres ===
 +
<div class="discussion">
 +
* ... autres solutions possibles ?
 +
</div>
 +
  
 
== origines ==
 
== origines ==

Revision as of 09:29, 10 January 2010

<entry-title>dtend-problématique</entry-title>

Une problématique hCalendar.

résumé

La propriété dtend hCalendar de hCalendar 0.1. requiert que les dates de fin soient marquées comme arrivant un jour complet après ce que les personnes considèrent généralement comme la fin de la date d'un événement.

Par ex. si une conférence démarre le 12 mars 2010 et se termine le 16 mars 2010, alors la dtend doit être marquée avec la valeur de "2010-03-17" - ce qui s'apparente à un jour complet après la fin de la conférence. hCalendar suggère d'obscurcir cette disparité entre la date de fin visible par l'humain et la date machine spécifiée en utilisant la balise <abbr> :

<div class="vevent">
 <span class="summary">une conférence</span>
 démarre le <span class="dtstart">2010-03-12</span>, et 
 se termine le <abbr class="dtend" title="2010-03-17">2010-03-16</abbr>.
</div>

C'est dû au fait que hCalendar a été spécifié initialement avec la même sémantique que iCalendar, ce qui place cette exigence sur la propriété DTEND de l'objet VEVENT.

problèmes

C'est problématique pour plusieurs raisons :

  • Incohérence. It is odd that the value specified for machine consumption is different than the value specified for human consumption - regardless of format/syntax - and appears inconsistent to anyone who sees the tooltip, or views and copy/pastes the source. It looks like a bug or mistake, and in fact has been errantly "corrected" as such (e.g. even in the hCalendar spec itself).
  • Non inuitif pour la rédaction. When authors are writing up the end date for an event, they write up what a human expects to see - the last day of the event. It is an unintuitive leap to think to specify +1 day for machine consumption, and an additional cognitive load (in order to get it right).
  • Abus sémantique de abbr. An abbr's title attribute provides an expansion for the inner text. In no way is a +1 date an expansion of a date, it appears more like a completely different value.
  • Violation Requise de DRY. While the dtstart in the above example is specified only once, readable to both humans and machines, the dtend must be specified twice, once for humans, and once for machines, thus requiring a particularly bad DRY (Don't Repeat Yourself) violation, that of requiring data be specified twice, but slightly different in one instance than another, thus increasing the chances of duplication based errors even more (since verifiability is more difficult).
    • Empêche l'utilisation d'un marquage simple As a result of the forced DRY violation, it is not possible to use simple markup like <span class="dtend">2010-03-16</span> because while a human reads that as an event that ends on the 16th, an hCalendar 1.0 processor will read that as an event that ended the day before, on the 15th.

solutions possibles

Comme noté dans la description du problème sur la page problématiques hCalendar, il y a au moins quelques solutions possibles.

dtend dates incluses

problématique résolue

  • redéfinir dtend hCalendar 1.0.1 pour être incluse pour les dates globales.
    • Avantage : Zéro impact sur le vocabulaire.
    • Avantage : Pas d'augmentation de la complexité à publier hCalendar.
    • Avantage : Reflétera l'usage dominant de dtend dans les exemples dans la jungle, (plus de recherche et citations demandées). En d'autres mots, les auteurs on DEJA utilisé dtend en supposant que ça fonctionne de cette façon (dates de fin incluses), et seront en fait surpris de trouver que ce ne l'est pas. Faire ce changement à la sémantique DtEND peut en fait refléter plus la réalité de publication hCalendar que de conserver la sémantique précise du DTEND iCalendar. Exemples d'usage de dtend incluses dans la jungle :
      • http://barcamp.org/ - BarCamp wiki, dates pour les BarCamps
      • microformats.org/wiki/events/ - plusieurs événements sur plusieurs jours, comme celui récemment de Glenn Jones (qui se décrit lui-même comme un développeur "très" connaisseur et prolifique de microformats) la page événement SXSW 2010 utilise des DTEND incluses, (notamment un élément span qui ne fait PAS de contenu dupliqué).
      • la version draft du livre d'Emily Lewis Microformats Made Simple, utilise dtend pour les dates de fin incluses.
      • La page personnelle de Dan Cederholm SimpleBits connaisseur et expert a un calendrier événements qui utilise des dates incluses dtend.
      • http://upcoming.org (apparemment selon Michael Kaply)
      • ... plus d'instances de l'usage existant de DTEND pour des dates de fin *incluses*.
    • Avantage : Bon nombre d'implémentations traitent les dates DTEND comme *incluses* (techniquement celles-ci violent la spec hCalendar en cours, mais elles peuvent délibérément faire ainsi pour refléter les pratiques de publication hCalendar actuelles). Implémentations :
      • le validateur Rich Snippet de Google. Le validateur Rich Snippet sur microformats.org/wiki/events montre l'événement SXSW comme se finissant le 2010-03-16, ce qui est cohérent avec l'intention de publication.
      • ... plus d'implémentations qui traitent les dates dtend hCalendar comme incluses
    • ... autres avantages ?
    • Inconvénients : Redéfinit DTEND pour être *légèrement* différent de la façon dont il est défini dans iCalendar. Ceci peut mener à des erreurs de la part des développeurs.
      • Mitigation : it may be possible to mitigate this disadvantage by providing both very precise hCalendar to iCalendar processor conformance requirements, and sufficient test cases for hCalendar to iCalendar processors for them to get this correct in their code.
    • Inconvénients : breaking some amount of existing hCalendar content on the web (research needed to determine the extent of the problem)
      • Workarounds: Based on aforementioned research, workarounds may be possible, e.g. heuristics for when abbr is used similar to the example at the top of the page, to detect "off by one" cases and accommodate accordingly). Make it an explicit error for the human visible date to be different than the machine parsed date, and state specific error handling rules for hCalendar processors that "repair" this problem.
    • ... any other disadvantages?
    • Opinions :
      • +1 Based on the fact that this problem just hasn't gone away, and that people (smart knowledgable people!) continue to treat "dtend" end dates *inclusively*, I now think it makes more sense (and is more practical) to change the spec to be consistent with the dominant expectation of web authors, rather than continue attempting to change the expectations of web authors to be consistent with the spec. I think this is the simplest, most effective, and least risky option. Tantek
      • +1 This appears logical and intuitive. We are effectively saying that end dates such as DTEND should parse to YYYY-MM-DDT24:00:00, and not YYYY-MM-DDT00:00:00. Seems simple, and entirely logical from a publishing stand —BenWard 08:18, 27 August 2009 (UTC)
      • +1 The spec should reflect the intuitive publishing behaviour (inclusive end dates). Humans first. —Jeremy Keith
      • +1 Though I'm worried about tools catching up to this change. Ted
      • +1 The natural human way to think about dates is inclusively; if the dtend date and dtstart date are equal, that clearly doesn't imply zero duration. The microformats principle of making things easier for authors rather than parser writers wins here Kevin Marks
      • +1 It is much easier to migrate the limited number of tools and authors who already grok hCalendar 1.0 than to migrate publisher intuition. MatthewLevine
      • +1 I agree with MatthewLevine. Those who follow hCalendar development are likely to make the change to inclusive dates, and those who don't are likely using inclusive dates already. Chris Cressman
      • ... please add your +1/0/-1 opinion here and sign with three tildas (~~~)

Tests de cas avec dtend incluse

Tests de cas qui vérifient l'implémentation de cette résolution de problème :

nouvelle propriété pour dates de fin

  • new hCalendar 1.0.1 property for end dates. As noted in the first resolution of the issue, we could introduce a new property, dtlast (described more in hCalendar brainstorming: dtlast) which authors would use to specify the last day of an event, instead of dtend.
    • Advantage: Maintains iCalendar conceptual compatibility for DTEND values.
    • Advantage: Compatibility with existing hCalendar 1.0 content that just happened to get the end date +1 distinction right.
    • ... any other advantages?
    • Disadvantage: Increased vocabulary. dtlast is a new term, even if it is not new functionality. Essentially this puts additional burden on authors.
    • Disadvantage: Increased complexity/confusion. When to use dtend vs. dtlast? hCalendar authors would now have to remember, use dtend for end *times* and dtlast for end *dates*. More explanation of the additional burden on authors.
    • ... any other disadvantages?
    • Opinions:
      • -1 despite originally proposing this solution, I now think an additional term, and rule for when to use the new term vs. the old term will actually make this problem worse and more confusing to web authors. Tantek
      • ... please add your +1/0/-1 opinion here and sign with three tildas (~~~)

autres

  • ... autres solutions possibles ?


origines

Cette problématique a été soulevée par Tantek presque depuis le tout début où il donné un exemple en 2004, c'est quelque chose qu'il a dû explicitement couvrir et pointer dans chaque présentation qu'il a donné, cela a été soulevé sur la liste de discussion microformats-discuss, et documenté explicitement comme problématique sur la page wiki hCalendar issues par Andy Mabbett le 2007-01-20.

voir aussi