Discussion:ICalendar
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
Lien externe mort -> redirigé
modifierBonjour,
Pendant plusieurs vérifications automatiques, un lien était indisponible. Merci de vérifier si il est bien indisponible et de le remplacer par une version archivée par Internet Archive si c'est le cas. Vous pouvez avoir plus d'informations sur la manière de faire ceci ici.
Les erreurs rapportées sont : consécutives au transfert de ces archives, voir donc
http://www.imc.org/ietf-calendar/ [1]
▪ Eskimbot ☼ 31 janvier 2006 à 04:46 (CET)
Redirection : Trebly (d) 20 octobre 2009 à 16:10 (CEST)
Lien externe mort
modifierBonjour,
Pendant plusieurs vérifications automatiques, un lien était indisponible. Merci de vérifier si il est bien indisponible et de le remplacer par une version archivée par Internet Archive si c'est le cas. Vous pouvez avoir plus d'informations sur la manière de faire ceci ici. Les erreurs rapportées sont :
Lien externe mort
modifierBonjour,
Pendant plusieurs vérifications automatiques, un lien était indisponible. Merci de vérifier si il est bien indisponible et de le remplacer par une version archivée par Internet Archive si c'est le cas. Vous pouvez avoir plus d'informations sur la manière de faire ceci ici. Les erreurs rapportées sont :
Norme ou standard ?
modifierBonjour,
Dans l'article, il est écrit "iCalendar est une norme".
Une norme ? Quel est l'organisme qui a normalisé ce format ?
Ne serait-ce pas plutôt un standard ? ou un projet de norme ?
En conséquence, je propose une modification de l'article.
Synanceia (Pierre) (d) 15 octobre 2008 à 06:38 (CEST)
- L’IETF. « Norme » est à mon humble avis la meilleure traduction de l’anglais « standard ». .Chatfeuille.☭., le 3 février 2009 à 15:10 (CET)
Trebly (d) 20 octobre 2009 à 15:42 (CEST)
Bien d'accord, mais le problème est à mon avis, non dans le "concept" mais dans le droit. On connait bien l'ISO et le normes européennes CEN , mais bien des organismes souvent très structurés définissent des "standard", des "normes". Pour éviter toute ambiguïté il conviendrait ici dans Wikipédia que le mot norme ne soit utilisé seul que pour désigner les normes ISO ou CEN (quoique) ou le concept en soi. Pour les autres il conviendrait d'avoir la discipline de citer systématiquement l'organisme normalisateur.
En l'occurence il s'agit via l'IAB : (Interactive Advertising Bureau - Internet) et surtout l'ISOC : http://www.isoc.org/ The Internet Society puis l'IESG (http://www.ietf.org/iesg/) émanation de l'IAB ayant pour objet les problèmes de formalisation des standard proposés par l'IETF (http://www.ietf.org/), de norme que l'on qualifiera au plus proche de "normes IETF"
- Bien d'accord pour norme plutôt que standard. D'après Standard#Distinction_entre_standard_et_norme, iCal est une norme, normalisée par l'IETF, mais pas un standard car de nombreux logiciels largement utilisés n'implémentent pas iCal (MS Outlook, MS Project). ~Futal
- Je crois que tu comprends à l'envers: aucune norme ou standard n'est obligatoire (seule la loi revêt un caractère obligatoire), donc ne sont sensés appliquer une norme ou standard que ceux qui prétendent s'y conformer. Quand un standard devient obligatoire, il est révisé dans sa forme légale et devient nécessairement une norme défini par l'organe législatif.
- Ce qui différencie une norme d'un standard c'est avant tout ceux qui la définissent: n'importe qui peut créer un standard, même sans aucun concertation : le standard vient du seul fait de sa publication et diffusion pour le porter à connaissance du public (un brevet ne peut donc pas être un standard car sa diffusion est restreinte). Dans Wikipédia on a plein de standards: ils sont tous issus de démarches volontaires, mais ce ne sont pas des "normes" à proprement parler.
- Une norme est en revanche issue d'un processus de concertation et de cooptation, et il va s'imposer à ceux qui l'ont approuvé. Une norme en revanche n'est pas toujours publiée ou pas librement accessible (c'est le cas de la plupart des normes de l'ISO qui ne publie aucun standard, juste des normes: ces normes pourront revêtir plus tard un caractère obligatoire dans certains pays qui les transforment en lois et textes réglementaires (mais ces lois et réglements ne sont pas plus des normes en tant que telles, ils échappent totalement au contrôle des personnes ayant établis ces standards ou des organismes ayant établi les normes).
- Nombre de normes et standards ne visent qu'à établir une conduite ou un objectif commun. On peut toujours passer outre (mais alors ne pas prétendre s'y conformer: seules les normes cependant sont protégées contre cet abus de conformité prétendue, les organismes normalisateurs pouvant se prévaloir de leur autorité sur une norme dont ils sont propriétaires).
- En revanche, un standard n'a pas d'organisme normalisateur, c'est une production privée, protégée uniquement par celui qui l'a écrite et publiée (et en pratique ceux qui veulent protéger leur standard contre un abus de conformité ou d'usage le font avec les brevets et les marques, et non pas avec une simple licence de droit d'auteur qui ne protège que le texte du standard mais pas son utilisation et encore moins une quelconque mention de conformité).
- Bref iCalendar est publié par l'IETF, mais seulement en tant que RFC décrivant les meilleures pratiques discutées. Mais cela reste d'abord un instrument de travail et si ce n'est donc pas une norme (il n'y a pas eu de processus formel d'approbation engageant l'IETF ou ses participants) on peut dire toutefois que c'est un standard (à caractère facultatif, et où même la "conformité" ne fait l'objet d'aucun critère objectif ni de certification ou de contrôle, ce qui fait que tout utilisateur d'iCalendar peut décider de l'utiliser seulement en partie ou d'en dévier: il n'y a aucune clause obligatoire, le document RFC a beau utiliser des "SHOULD" c'est non contraignant, on peut passer outre et en pratique il n'y a strictement aucune implémentation qui s'y conforme, c'est juste une spécification qui sert à inspirer et progresser dans le bon sens). Le jour où l'IETF le décidera (ou bien jamais) il pourra passer cette RFC au statut de "Best Current Practice" (BCP), mais en attendant c'est juste un standard en ébauche même pas encore au niveau du "Standard Track", ni même une "recommandation".
- Conclusion : ce n'est PAS DU TOUT une norme (qui inclurait des clauses contraignantes et une protection contre ses abus d'usage ou de conformité et éventuellement une implémentation dans la législation de certains pays/Etats/collectivités et une approbation par l'organisme normalisateur au nom de tous ses membres).
- Ne pas confondre avec le sens courant du mot "standard" qui dans l'esprit des gens pourrait signifier que l'usage est établi comme le plus courant et que toute déviation non conforme serait illégale ou illégitime ou carrément dépassé/obsolète/impratique/inutile (l'art, la création, l'innovation demandent la faculté de se sortir des standards pour produire quelque chose de différent ou nouveau ou pour conserver la mémoire et la diversité ; la liberté impose la faculté de se défaire des normes et lois contraignantes par une opposition beaucoup plus courageuse et souvent une démarche politique militante visant à s'opposer directement à l'organisme ou l'autorité normalisatrice pour retirer ce statut normatif de ce qui n'aurait du être qu'un standard de proposition, ouvert à l'évolution et à l'expérimentation de solutions alternatives).
- Dernière note: l'IETF est bien un organisme de normalisation, mais ce texte n'est PAS une de ses "normes" puisqu'il n'a pas atteint ce statut, c'est même à peine une ébauche de standard, disons que ce standard est largement ouvert, juste un instrument de travail pour discuter du sujet et expérimenter, AVANT de standardiser (le statut affiché en tête est clair: "PROPOSED STANDARD", passé un délai de quelques années après sa publication, s'il n'est pas remis à jour par un autre RFC, il deviendra automatiquement obsolète et ne sera jamais un standard ni une norme). Le terme exact devrait donc être "proposition de standard", mais pas du tout "norme" ni "standard". Cette proposition est encore active puisque la révision (corrective) a été publiée en 2016 (donc cette proposition n'est pas encore obsolète). Mais ce n'est toujours pas approuvé comme peuvent l'être d'autres RFC qui sont dans le "Standard Track" et "officiellement recommandés" en tant que "Best Current Practice" (avec un numéro BCP pour son suivi à long terme pour les autres RFC qui viendraient s'y adjoindre ou le réviser).
- Pour qu'un standard soit approuvé, puis qu'il devienne une norme (contraignante pour ceux qui disent s'y conformer) ou une loi (contraignante pour tous) il va s'écouler un temps très long et en fait bien des standards approuvés n'auront jamais ce statut de norme. Contrairement au français, les deux termes "norme" et "standard" sont confondus en anglais sous le seul terme "standard", pour les différencier ils doivent compléter en indiquant un statut précis et explicitant ces termes; de même l'anglais parlera d'organismes de standardisation ou de normalisation de la même façon quelle que soit le statut des documents qu'ils ont publiés ou sur lesquels ils travaillent ; en français on peut distinguer "organisme de standardisation" et "organisme de normalisation" par le fait qu'ils ont où pas la faculté d'imposer des clauses contraignantes dans certains usages ou certains pays ou chez certains utilisateurs: les organismes de standardisation sont un abus de langage car le plus souvent ce sont juste des organismes privés qui se contentent juste de décrire publiquement leurs procédés et méthodes et d'en faire publicité, au lieu de déposer des brevets pour empêcher les autres d'utiliser réellement les idées brevetées dont les titulaires de brevets sont d'ailleurs très rarement les auteurs ni les implémenteurs ou utilisateurs finals, mais juste se prévaloir d'une exclusivité pour accorder les droits et régler les litiges liés à l'utilisation du brevet et collecter des dividendes très au delà de ce qu'ils ont du payer pour obtenir l'enregistrement du brevet et qui d'ailleurs se gardent bien de les publier, avec des brevets tenus complètement secrets pendant des années entre le dépôt et l'obtention finale).
- Un autre abus de langage courant est l'expression "standard ouvert" (traduction trop littérale de l'expression anglaise "open standard" qui nécessite une précision): par définition un standard en français est nécessairement ouvert (contrairement à la "norme" qu'on traduit en anglais comme un "standard fermé" ou "closed standard", dont il n'est pas possible de dévier sans rompre une clause contraignante de conformité, un de celle des "MUST", mais dont on peut outrepasser les "SHOULD" dans certaines conditions décrites par la norme). Un "standard ouvert" (expression redondante en français) ou juste "standard" ne devrait contenir aucun "MUST".
- Dans le monde légal, une "norme" s'appelle une "loi" (y compris la Constitution) ou un "contrat", et un "standard" s'appelle une "charte" (qui peut être discutée à tout moment et ne fait que donner une ligne directrice de principe).
- Dans le monde mathématique, une "norme" s'appelle un "thérorème", et un standard s'appelle un "axiome". Mais aucun théorème ne peut exister sans axiome préalable.
- De même aucune norme ne peut exister et fonctionner sans standard préalable (sauf si elle s'impose dictatorialement par une autorité autoproclamée qui fait usage de la contrainte : en mathématique on parlerait juste d'assertions établies mais non démontrées) ! Verdy p (discuter) 20 juillet 2017 à 17:54 (CEST)
- Merci pour le lien. Est-ce que ces deux exemples suffisent à conclure « de nombreux logiciels » ? A-t-on des chiffres sur l’ensemble des logiciels de calendrier / emploi du temps, et sur leur part de marché ? .Chatfeuille.☭., le 15 mars 2010 à 18:21 (CET)
Des définition contradictoires : "évènement"
modifierLes définitions qui apparaissent ici sont issues de documents conçus par l'IETF (The Internet Engineering Task Force) et plus particulièrement ici le concept d'évènement (traduction de EVENT). Ces définitions sont rappelées dans cet article "ICalendar" sont assez contradictoires avec la définition d' "évènement" donnée ici-même dans Wikipédia mais aussi sensiblement avec celles des dictionnaires de langue anglaise.
J'ai abordé la discussion de ce thème par un long commentaire à la rubrique discussion du concept d'"évènement" ici dans Wikipédia. A mon avis les dégâts générés par ces confusions sont déjà considérables, et il conviendrait d'endiguer le phénomène. Le problème est important et n'est pas l’effet d’une simple confusion ni celui d'une traduction imprécise ou abusive.
Je vais chercher à intervenir auprès de l'UITF pour, j'espère faire comprendre mes motivations, constats et points de vue et in fine trouver un remède, au moins de principe.
Il me paraît, compte tenu des glissements de sens, et d'une polysémie souvent "perfide", inévitable d'introduire de nouveaux mots ou des mots composés qui enrichissent la (les) langues. Par exemple, devant la vague actuelle générée par internet et l'action de l'UITF, le concept actuel d' "évènement" pourrait probablement accepter de glisser vers "évènement ponctuel" (j'ai recherché puis finalement choisi le terme de ponctuel car il connote directement le "point" en mathématiques dans l'espace qui est homogène avec le temps et l’espace des nombres réels).
Ce cas n'est pas le seul dans les concepts liés au temps : par exemple la "dérive croisée" entre "to-do", "à-faire" et"tâche" et les confusions qui en résultent privent encore la langue d'un espace de concepts et créent des confusions rendant incommunicables certaines notions pourtant majeures.
Je me permets de reprendre en résumé mon point de vue (exprimé par ailleurs) : les mots, comme éléments de l'expression écrite ou orale, sont interprétables et enrichis dans et par leur contexte. Les noms d' "objets" informatiques ont très souvent un poids beaucoup plus lourd, parce qu’ils sont utilisés sans contexte et de manière très formelle, aussi ils peuvent devenir plus que des boulets, des bombes dans la langue. Ces noms d'objets doivent donc être surveillés avec une attention particulière et soutenue.
J'ai poursuivi ma recherche sur le vocabulaire dans les deux langues de manière plus approfondie. On doit considérer que l'anglais "EVENT" (faux amis bien connu de l ' "évent") est aussi un peu un faux ami d' "évènement" admis comme traduction valide. En effet la définition anglaise quel que soit le dictionnaire est : Definition (Cambridge) : anything that happens, especially something important or unusual sans être conforme à la définition de 'UITF' de l'objet informatique "VEVENT" de iCalendar que je résume ici par "quelque chose qui se passe pendant une certaine durée" est bien éloignée de la définition française (polysémique) dont une synthèse est celle que l'on peux trouver ici (Wikipédia) soit : "Un événement ou évènement est un fait qui survient à un moment donné. Il se caractérise par une transition, voire une rupture, dans le cours des choses, et par son caractère relativement soudain ou fugace".
Le fait fondamental est que l'EVENT anglais s'inscrit potentiellement dans la durée et est donc caractérisé par un segment entre deux "instant" (point dans l'espace du temps) alors que en français il n'est caractérisé que par un seul instant
Comme je l'indique dans la discussion sur "évènement", l'évènement en français est homogène à un "dirac" (contenu dans une durée tendant vers 0 tel que la somme à une valeur finie) alors qu'en anglais on va volontiers vers une collection de "dirac". Il existe donc des liens avec la théorie des « distributions » (voir math.) de Laurent SWARTZ. Le « EVENT » anglais se rapprocherait donc d'une "distribution" (ensemble de dirac) sur une période bien délimitée dans le temps par un début et une fin constituant donc un ensemble d'évènements au sens de base du français. Même pouvant paraître subtile, la confusion est catastrophique, et mène bien évidemment à de nombreuses contradictions. Ainsi nous pourrons lire dans le document en cours de discussion rfc4445
Description: A "VEVENT" calendar component is a grouping of component properties, possibly including "VALARM" calendar components, that represents a scheduled amount of time on a calendar. For example, it can be an activity; such as a one-hourlong, department meeting from 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time on an individual calendar. Hence, the event will appear as an opaque interval in a search for busy time. Alternately, the event can have its Time Transparency
Il y a lieu de conclure qu'une "activity" Définition Cambridge : activity noun (WORK) /ækˈtɪv.ɪ.ti/US pronunciation symbol/-ə.t ̬i/ n [C or U] the work of a group or organization to achieve an aim
dont la traduction française est : "activité" quelque chose que l'on fait.
En conclusion l’UITF introduit l’idée qu’un évènement peut être quelque chose que l'on fait, un travail.
Un autre objet composant du Icalendar est "to-do" Définition Cambridge : to-do noun /təˈduː/ n [S] informal difficulty or trouble, usually which is more than the situation deserves
dont la traduction littérale "à-faire" n'a pas de mot correspondant en français dont la définition qui ne correspond niau dictionnaire anglais ou d’ailleurs anglo-américian mais je pense à l'usage.
Au concept de "to-do" correspond l'objet informatique de Icalendar VTODO
Description: A "VTODO" calendar component is a grouping of component properties and possibly "VALARM" calendar components that represents an action-item or assignment. For example, it can be used to represent an item of work assigned to an individual; such as "turn in travel expense today".
On ne peut que conclure que "VEVENT" peut être un travail tout autant qu'un "VTODO". Bien évidemment il n'y a aucun lien conceptuel direct tant en français qu'en anglais entre EVENT=évènement et "travail"="work".
Le but de mes propos n’est pas une critique des écrits ni du travail de l’UITF, mais de montrer avec quelle aisance on peut s'égarer dans ces concepts.
La question se pose alors du mot français permettant de traduire EVENT correctement, je n'en ai malheureusement pas trouvé de correct, sauf à abandonner l'aspect, à mon sens fondamental, lié à l'unicité de l'instant auquel il est lié. On peut trouver dans le cas d'applications particulières (instanciations du concept) dont "l'évènement médiatique : salons, manifestations etc." un glissement de sens nous rapprochant du concept anglais. Parallèlement on ne trouve pas de concept anglais qui soit une traduction correcte d' "évènement". Le problème est donc ouvert.
Si l'on veut faire quelque chose de clair et net il y a, tel que je le sens, vingt ans de travail. J'ai pourtant des maintenant quelques idées de solutions qui pourraient permettre de prendre une bonne trajectoire :
- Faire admettre in fine par l'académie le glissement de sens avec pour l'ensemble des concepts de physique, informatique (drôle de paradoxe) etc. où le lien à l' "instant" est majeur la forme insistante "évènement ponctuel", « ponctuel » pouvant être omis quand il y a un contexte sans ambigüité.
- Faire admettre du coté anglais le même principe "one time event" ou "o-event" ou encore "instant-event"
- Du coté de l'UITF faire admettre de créer un nouvel objet Icalendar (pour frapper les esprits) le OEVENT ou VOVENT : objet auquel n’est associée qu’une date d’occurrence (même si divers sous-types tels date prévue, souhaitée, objectif etc. caractérisent le « même instant (trad : date-time) »
- En français trouver un mot correct traduction de to-do (à-faire) se construit bien mal, pendant que "quelque chose à faire" est vraiment long et lourd, mais c'est la bonne traduction si l’on oublie le sens de « difficulty or trouble » (on peut aussi penser que "to-do" est une contraction de « something to do », valide et utilisable en anglais pendant que « à-faire » ne l’est pas).
Si l'on crée un tel concept il sera peut être possible de faire figurer dans un calendrier (Icalendar) une livraison, une opération bancaire, une signature d'accord etc...
On pourra par ailleurs inviter les développeurs à traiter les "to-do" et "VOVENT" dans les agendas, sachant que les confusions qui imbriquent VEVENT et TODO semblent faire abandonner TODO (todo disparaît des calendriers développés par Google, Yahoo etc…). Ce fait est une traduction de l'appauvrissement des concepts, aboutissement des confusions de sens. En effet malgré les confusions VEVENT ne décrit jamais un travail ni une tâche même si leur occurrence sous-tend leur existence.
En conclusion nous remarquerons que les concepts de Icalendar sont issu des problèmes de l’informatisation des agendas pendant que la gestion des plannings est liée à la gestion du travail. Dès 1975 des équipes s’occupant de management du temps se posaient le problème des liens entre les concepts liés au planning de projets (tâches, groupes de tâche) et les évènements marquant notamment des faits contractuels.
Trebly (d) 20 octobre 2009 à 14:53 (CEST), modifié assez profondément et complété le 22 octobre 2009 à 23:54 (CEST)
- Bonjour. Il y a plusieurs coquilles dans ton message, dont « UITF » pour « IETF », ce qui est assez gênant. Cordialement. .Chatfeuille.☭., le 15 mars 2010 à 18:21 (CET)
Discussion transférée depuis Wikipédia:Pages à fusionner
L'article .ics ne devrait être qu'une section de l'article iCalendar : le premier est l'extension données aux fichiers respectant le format de données. Ssx`z (discuter) 22 juillet 2016 à 12:25 (CEST)
- Pour Proposant Ssx`z (discuter) 22 juillet 2016 à 12:25 (CEST)
- J'ai mis une redirection. --Nouill 24 juillet 2016 à 15:28 (CEST)