Revision as of 23:29, 22 June 2006

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. Quelques problèmes peuvent être ACCEPTES et peut être amener à provoquer des modifications ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour plus de concision, de camel, de rationnalité et aussi neutre en point de vue que possible. Formulez bien vos problématiques. — Tantek

Voir problématiques hCard en rapport.

Problématiques

Utilisez svp ce format :

YYYY-MM-DD 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 .

Et ajoutez de nouvelles problématiques en haut de la liste :

open issue! 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).
  - SPECUPDATE/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 ?
  - REJETE. Svp RTFM. Chercher la spec hCalendar pour *soit* l'"axe" ou les "en-têtes" aurait été trouvé en suivant l'exemple suivant dans la jungle : Web Essentials 05 a balisé son tableau de planning de programme avec hCalendar, en utilisant les attributs 'axes' et les attributs 'en-têtes'.
3. Les composants embarqués devraient-ils être autorisés ? RyanKing a déjà remarqué que vJournal chevauche les blog-posts (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).

1. - 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 'officies' de test hCaenar]] 'official' hCalendar tests?
  - ACCEPT PARTIAL. We probably need an hCalendar validator before we can declare any set of tests to be official.
2. The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.

<a name="myfrag">heading</a>
<div class="vevent">
  <div class="description">A nice event</div>
  <abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>

1. - ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
2006-02-01 raised by RyanKing
1. Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?
  - ACCEPTED. Yes, we should expliclty DROP "vjournal" from hCalendar.
2006-01-04 raised by CGranade
1. Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the class attribute is not portable across schemas.
  - REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.
2. All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.
  - ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
2005-10-14 raised by 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
  - ACCEPTED-PARTIAL. 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.
  - ACCEPTED. 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):
  - For more discussion of this, please see hCalendar brainstorming: UID handling

  <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 raised by RyanKing
1. How does one use ATTENDEE?
  - ACCEPTED. 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,

Web 2.0 Conference:

...

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

2005-07-21 raised by 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 raised by Kragen
1. The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about xFolk.
  - REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

2005-06-21 raised by Hixie
1. Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
  - ACCEPTED. Another to-do for Tantek, write-up hcalendar-parsing that documents precisely how user agents are to parse hCalendar markup.
2005-02-22 raised by Matt Raymond on the whatwg list:
1. There is no copyright statement and no patent statement.
  - ACCEPTED. I have updated hcalendar (and hcard, and all other MicroFormats) with a standard copyright statement and patent statement.

2005-02-18 raised by Matt Raymond on the whatwg list:
1. There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.
  - REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
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).
  - REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
3. The use of for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.
  - REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of : Human vs. ISO8601 dates problem solved
4. You have to create a complex set of rules for all possible uses of legacy markup within which can easily be implemented incorrectly.
  - REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
5. There are styling and tooltip issues that are unresolved.
  - REJECTED (empty statements). See the hCalendar FAQ for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
6. hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.
  - REJECTED (empty statements, invalid comparator). 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.
  - ACCEPT-PARTIAL. 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?)
    - ACCEPTED. 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?
        ACCEPTE. 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.
open issue! 2006-04-10 raised by Scott Reynen.
1. When someone looks at the hcalendar pages, one sees no collection of real-world publishing of event data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the process nor the hcalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.
open issue! 2006-04-13 raised by Tantek
1. Need to add a section on "Property Exceptions" like that in hCard to document how to publish / handle the METHOD property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert hCalendar to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default METHOD:PUBLISH on the VCALENDAR object in the resultant .ics stream.

hcalendar-issues-fr: Difference between revisions

Revision as of 23:29, 22 June 2006

Problématiques hCalendar