Articles précédents : Articles
- [354] Vente liée de logiciels : l'UFC a besoin de vos témoignages
- [96] DADVSI : les associations du libre réagissent aux amendements du Sénat
- [3] RedHat achète JBoss
- [22] TrollForum 2006 : IBM et Troll
- [2] Le village des associations aux RMLL 2006
- [12] Le droit du logiciel (libre) : état et évolutions
- [2] Enquête sur l'utilisation du logiciel libre dans les collectivités territoriales françaises
- [25] Lancement d'un site communautaire pour le montage vidéo libre
- [11] Sortie de AlternC 0.9.4, plateforme de gestion d'hébergement
- [29] TuxFamily.org devient TuxFree.org
Liens connexes
- L'appel sur le site du SDAE (1268 hits)
- Wiki (1153 hits)
- Règlement de l'appel à commentaires (415 hits)
- Interview de Frank Mordacq (424 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Appel à commentaires sur le référentiel général d'interopérabilité
Posté par Theo (). Modéré le 24 avril 2006.
Organisé autour de trois volets d'interopérabilité (technique, organisationnelle et sémantique), le RGI aborde 16 thèmes (format de documents, gestionnaire d'identités, etc.) et 4 initiatives. Ce site est accompagné d'un wiki public dont voici certaines règles :
- Règle 0025 Interopérabilité technique
Il est RECOMMANDÉ d'utiliser le format Open Document pour les échanges de documents bureautiques semi-structurés (traitement de texte, tableur, présentation). - Règle 0026 Interopérabilité technique
Il est OBLIGATOIRE d'accepter tout document au format Open Document pour les échanges de documents bureautiques semi-structurés (traitement de texte, tableur, présentation). - Règle 0027 Interopérabilité technique
Il est INTERDIT de faire une migration depuis le format bureautique couramment utilisé par une organisation vers un format autre que le format ouvert Open Document. - Règle 0044 Interopérabilité technique
Il est INTERDIT d'utiliser des composants logiciels type ActiveX ou toute autre extension de navigateur (Flash hors animation, VML, etc.) au niveau des IHM Web.
Frank Mordacq, directeur de la DGME, rappelait les objectifs de la modernisation à savoir une démarche de qualité de service auprès des usagers et proposait une nouvelle logique de travail aux agents.
![[fr]](/images/fr.png)
L'appel sur le site du SDAE (1268 hits)-
Wiki (1153 hits)
-
Règlement de l'appel à commentaires (415 hits)
-
Interview de Frank Mordacq (424 hits)
> Lire la dépêche (59 commentaires, moyenne: 4,5).
Codage des caractères ?
J'ai pas encore tout lu mais ... http://www.adae.gouv.fr/wiki/index.php/Interop%C3%A9rabilit%(...)
Il est OBLIGATOIRE d'utiliser la norme ISO 8859-15 Latin 9, pour l'encodage sur un octet des caractères. Règle 0001 Interopérabilité technique
Il me semblait que l'UTF8 était l'avenir ?
Pourquoi un tel choix alors ?
Sinon, il est clair que c'est un grand pas pour l'administration ouverte et accessible à tous.
-
[^]Re: Codage des caractères ?
Posté par vrm (page perso, ) le 24/04/2006 à 09:43. (lien). Évalué à 10.le problème de l'UTF8 c'est que ca marche pas sous wmcoincoin du coup pour mouler ils sont obligé d'utiliser la norme ISO 8859-15 Latin 9. La seule norme garantissant une expérience de mouling de qualité. /o\
-
[^]Re: Codage des caractères ?
Posté par MrLapinot () le 24/04/2006 à 09:43. (lien). Évalué à 9.L'avenir peut-être. Mais là on est en France. Et la commission vise à l'interopérabilité pour les sites français (administration, etc.)
Donc elle évite de proner des options éventuellement non supportées par de vieux clients (je suppose) et préfère un encodage national bien adapté aux besoin décrits (l'administration française ne communiquant que rarement en tchèque ou en japonais, je suppose).
-
[^]Re: Codage des caractères ?
Posté par Sisyphe Plâtrier () le 24/04/2006 à 09:46. (lien). Évalué à 10.Il est OBLIGATOIRE d'utiliser la norme ISO 8859-15 Latin 9, pour l'encodage sur un octet des caractères. Règle 0001 Interopérabilité technique.
Hth.-
[^]Re: Codage des caractères ?
Posté par Marc Poiroud (Jabber id, page perso, ) le 24/04/2006 à 10:24. (lien). Évalué à 1.je te dirais que je sais lire .. mais si j'ai poser la question, c'est pour comprendre, donc avoir une explication concernant le choix de ISO 8859-15 Latin 9 face à l'UTF8 ... donc si tu veux développer un peu ton emphase, on y gagnerais surement en compréhension !
-
[^]Re: Codage des caractères ?
-
[^]Re: Codage des caractères ?
Posté par Flink () le 24/04/2006 à 10:29. (lien). Évalué à 3.Parce que l'UTF-8 est codé sur deux octets. La règle faisait référence au codage sur un seul octet.
Après google/wikipedia est ton ami.-
[^]Re: Codage des caractères ?
-
[^]Re: Codage des caractères ?
Posté par François BOTTIN () le 24/04/2006 à 10:32. (lien). Évalué à 5.Justement, d'après wikipedia, UTF-8 est codé sur un à quatre octets par caractère...
http://fr.wikipedia.org/wiki/Utf-8
Pour le français, les lettres non accentuées sont sur un octet et les lettres accentuées sont sur deux.
-
[^]Re: Codage des caractères ?
Posté par Zenitram (page perso, ) le 24/04/2006 à 10:46. (lien). Évalué à 10.UTF-8 est un codage Multi-octet, basé sur un octet.
ne pas confondre :
- ISO xxx sur un octet
- UTF-8 Multi-octet mais basé sur un octet (un logiciel prévu pour un octet peut le traiter sans probleme, juste l'affichage qui est bizarre)
- Unicode codés sur 4 octets (Windows utilise UTF-16, sur 2 octets)
On considère donc UTF-8 comme un "charset" sur un octet, au meme titre que ISO xxx, mais on le traite a l'afficahge comme du 4 octets.
donc maintenant, la spécification n'est pas claire, car ne fait pas cette difference : comment stocker Unicode? UTF-8? UTF-16? UTF-32? Big Endian ou Little Endian?
Donc faudrait préciser Unicode, par contre je comprend pour avoir de l'inter-operabilité maximum on utilise ISO Latin 9.
(en fait, je l'ai fait maintenant :) )-
[^]Re: Codage des caractères ?
Posté par Sébastien Koechlin () le 24/04/2006 à 11:34. (lien). Évalué à 6.J'ajoute une petite précision.
Unicode n'est pas un mécanisme de codage des caractères, c'est juste une norme qui attribue une valeur numérique (non bornée) à un symbole.
L'UTF-8, UTF-16 dont des mécanismes qui utilisent un codage des caractères unicode de taille variable comme cela a été dit.
Pour un programme, avoir une taille variable n'est vraiment pas pratique, il faut parcourir la chaine depuis le début pour interpréter les octets et retrouver les caractères. Les logiciels utilisent plutot une représentation en taille fixe.
La représentation en taille fixe la plus connue est ASCII, dont est dérivée toute la série des iso-8859-x célèbre, mais qui limitent toujours à 2^7 (127) les caractères en dehors de l'ASCII.
Pour représenter plus de caractère, les deux normes les plus utilisées sont
* UCS2 qui code les caractères sur 2 octets, cette norme ne permet d'utiliser que les caractères unicode dont le code est inférieur à 2^16
* UCS4 qui code les caractères sur 4 octets, limitant cette fois-ci les symboles aux 2^32 premiers. Comme il n'y a pour l'instant aucun caractères unicode au dela, cette norme est pour l'instant exhaustive.
UCS2 est la norme qui dont être utilisée en interne par Java.-
[^]Re: Codage des caractères ?
-
[^]Re: Codage des caractères ?
Posté par Zenitram (page perso, ) le 24/04/2006 à 14:18. (lien). Évalué à 5.Pendant que je tiens un expert ;-)
Sous Java (et Windows aussi), comment sont gérés les caractères Unicode>=65536? Impossible à gérer?
(sous Troll, c'est soit UTF-8, soit UCS4, donc pas de pb ;-) )-
[^]Re: Codage des caractères ?
Posté par François BOTTIN () le 24/04/2006 à 14:31. (lien). Évalué à 5.En ce qui concerne Java, cela est pris en compte depuis le J2SE 5.0 : http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.(...)
Il y est dit qu'à l'origine seuls 16 bits étaient utilisés pas Unicode, donc c'est ce qu'ils ont choisi comme représentation interne. Mais maintenant Unicode accepte des codes plus grands, donc ils ont dû adapter.
-
[^]Re: Codage des caractères ?
Posté par Sébastien Koechlin () le 24/04/2006 à 15:08. (lien). Évalué à 4.Je ne connais pas la réponse à la question parce qu'il s'agit de détails d'implémentation, mais il y a trois solutions, ou familles de solution, plus ou moins couteuses:
* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.
* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.
* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.
Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.
-
[^]Re: Codage des caractères ?
Posté par Sébastien Koechlin () le 24/04/2006 à 15:27. (lien). Évalué à 4.Pas de problème, normalement ;-)
UTF-8 permet de représenter le code d'un caractère jusqu'à 21 bits, ces 21 bits sont répartis dans 4 octets.
Il serait possible d'étendre UTF-8 pour coder jusqu'à 31 bits, mais la norme d'aujourd'hui l'interdit (cela ferai 6 octets pour les caractères de code élevé).
En UTF-16, c'est plus compliqué, parce qu'on fait l'extension sur une plage de non-caractères (qui deviennent alors non-représentable, mais les utilise-t'on si ce sont des non-caractères), il est possible de représenter 20 bits, auquels viennent s'ajouter les 16 bits des caractères ordinaire (à l'exception de la plage des non-caractères).
En UCS-2, on peut représenter 16 bits
En UCS-4 on peut représenter 32 bits
En UTF-32, qui est un sous-ensemble de UCS-4, on peut représenter un peu moins de 21 bits, (de U+0 à U+10FFFF), parce que la norme interdit d'aller plus loin.
Finalement nous n'avons aucun mécanisme qui permettent de représenter un caractère de code arbitraire, quelque soit les extensions que nous feront à la norme Unicode si elle évolue encore.
-
-
[^]Re: Codage des caractères ?
Posté par aedrin () le 24/04/2006 à 15:53. (lien). Évalué à 4.Pour un programme, avoir une taille variable n'est vraiment pas pratique, il faut parcourir la chaine depuis le début pour interpréter les octets et retrouver les caractères. Les logiciels utilisent plutot une représentation en taille fixe.
Faux. cf http://www.uzine.net/article1785.html (vers la fin de l'article) :
Remarque : le « masque » 10xxxxxx du dernier octet permet ainsi de savoir, à n’importe quel endroit de la suite de nombres qui définit la chaîne, si l’on est sur le début d’un caractère UTF-8 ou au milieu : une fonction qui analyse un flux de données UTF-8 saura donc toujours où elle en est, malgré la longueur variable des caractères : on dit que c’est un format de données auto-synchronisé.
Par contre c'est vrai que c'est pas pratique, mais pour d'autres raisons (par exemple, tout simplement obtenir la taille d'une séquence de caractères).
-
-
-
-
-
-
[^]Re: Codage des caractères ?
Posté par ccomb (Jabber id, page perso, ) le 24/04/2006 à 10:25. (lien). Évalué à 1.L'UTF-8, l'avenir ?? J'ai l'impression que c'est plutôt le présent, non ?
-
[^]Re: Codage des caractères ?
Posté par Maillequeule () le 24/04/2006 à 10:39. (lien). Évalué à 10.Absolument, c'est plutôt le présent !
-
[^]Re: Codage des caractères ?
Posté par Zenitram (page perso, ) le 24/04/2006 à 10:48. (lien). Évalué à 2.Le présent?
Combien de fichiers as-tu en UTF-8?
Pas beaucoup...
Meme tes fichiers de config sous pas mal de distrib Troll, on des encodage en latin9 dès qu'il y a des accents...-
[^]Re: Codage des caractères ?
Posté par Aldoo () le 24/04/2006 à 12:20. (lien). Évalué à 5.Oui c'est le présent, si tu fais le bon choix.
J'ai toujours qques problèmes avec des pages de man pas mises à jour, mais globalement mon système est UTF-8. J'ai aussi des fichiers en ISO-8859, mais le système se débrouille pour passer de l'un à l'autre, la plupart du temps sans qu'on ne se rende compte de rien.
La plupart des problèmes proviennent plutôt des mails, pages web, et autres données d'origine externe, qui soit oublient de préciser le charset et que je lis donc par défaut en UTF-8 alors qu'ils étaient codés en ISO, soit signalent un charset mais en utilisent un autre.
-
[^]Re: Codage des caractères ?
Posté par Zakath (page perso, ) le 24/04/2006 à 12:21. (lien). Évalué à 2.Bah déjà, tout fichier de config un tant soit peu sérieux sera entièrement ascii. Et ensuite, de plus en plus de systèmes, à commencer par le mien, sont tout unicode. Je ne sais pas ce qu'il en est des autres distrib', mais sous gentoo, c'est très facile de migrer.
-
[^]Re: Codage des caractères ?
-
-
-
[^]Re: Codage des caractères ?
Posté par herodiade () le 24/04/2006 à 11:07. (lien). Évalué à 10.La règle complète dit:
* Il est OBLIGATOIRE d'utiliser la norme ISO 8859-15 Latin 9, pour l'encodage sur un octet des caractères. Règle 0001 Interopérabilité technique
* Il est OBLIGATOIRE d'utiliser UNICODE v4.1.0, pour l'encodage multi-octet des caractères. Règle 0002 Interopérabilité technique
Autrement dit : pour des caractères latins, il faut utiliser soit ISO 8859-15, soit UNICODE (qui est un surensemble d'UTF-8).
Bref, UTF-8 est ok. Formellement: sauf si on l'utilise pour encoder de l'ASCII pur (dans ce cas, UTF-8 n'utilise qu'un seul octet) ; mais dans ce cas il n'y a pas de différence d'encodage avec Latin9 donc on peut dire que le document est encodé en ISO 8859-15 autant qu'il est UNICODE/UTF-8, et on reste dans les prescriptions.
Si on voulais chipoter un peu, on pourrai plutôt noter que la spécification ne précise pas OBLIGATOIRE ... "pour les documents destiné à l'échange", ou n'indique pas que ASCII est OK, mais je pense que c'est implicite (vu que le document parle d'intéropérabilité).
Car de nombreux logiciels, libres ou pas, (en particulier les logiciels serveurs etc.) utilisent ASCII pour le traitement de certaines chaines, en interne (eg. envoi/reception d'une requette HTTP, negociation SMTP ou DNS, fichiers de confs, fichiers de code source pour certains languages interprétés, traitement des arguments en ligne de commande ...). Certes, générer du ASCII c'est aussi générer du ISO 8859-15 (qui est un surrensemble d'ASCII), mais en retour ces logiciels ne peuvent accépter n'importe quelle chaine ISO 8859-15 (et ne sont donc pas pleinement compatibles avec la spec).
[+] Interdit d'interdire
Regle numéro 1: Il est interdit d'interdire.
Je pense que ces interdictions montrent une image sectaire et absolument pas pragmatique de cette initiative. La règle 27 est un exmple typique, si le document doit etre diffusé à quelqu'un qui n'utilise pas oo pourquoi le lui imposer ?
Je pense qu'il faudrait d'abord convaincre du bien fondé de ces règles, qui seraient alors très largement suivi.
D'autre part, l'emploi de ces termes "interdiction" est incompatible avec l'interview de Mr Mordacq qui déclare "notre rôle n’est pas coercitif".. et une interdiction sans coercition ce n'est pas une interdiction mais une recommandation.
-
[^]Re: Interdit d'interdire
Posté par atlexx () le 24/04/2006 à 10:47. (lien). Évalué à 10.OO n'est pas le seul logiciel a utiliser le format openDocument. il n'est jamais fait mention d'un logiciel. c'est un point important.
La formulation est un peu abrupte, mais est sans equivoque. on sait pertinament que lorsque l'on ouvre la voi pour un exception, elle devient souvent la règle.
-
[^]Re: Interdit d'interdire
Posté par Zenitram (page perso, ) le 24/04/2006 à 10:52. (lien). Évalué à 3.Regle numéro 1: Il est interdit d'interdire.
OK, ou habites-tu?
Comme tu n'aime pas les interdictions, tu ne verras aucun inconvénient que je vienne chez toi et te voles tout, en plus de te tuer.
comme tu veux rien d'interdit, ca ne me serait pas interdit, donc je ne me génerai pas.
Tout ca pour dire que pour faire respecter une démocratie, il y a des choses à interdire...
si le document doit etre diffusé à quelqu'un qui n'utilise pas oo pourquoi le lui imposer ?
Et que vient faire OpenOffice dans l'histoire???
OpenDocument est une norme, que meme MS peut implémenter dans MS office, ce n'est pas limité a Oo, donc si tu ne peux lire le format, c'est uniquement par la volonté de l'éditeur de ton traitement de texte
Ils n'imposent aucun logiciels, et toutes les normes obligatoires sont libre de droits, n'importe qui peut les implémenter dans 100% des logiciels sans aucun cout financier en royalties...-
[+] [^]Re: Interdit d'interdire
Posté par renoo () le 24/04/2006 à 11:34. (lien). Évalué à -10.Interdit d'interdire c'est un vieux slogan mais apparement cela te dépasse. En l'occurence dans une démocratie ce n'est pas à n'importe qui de décider des interdictions. Je trouve que ce vocabulaire est déplacé et trop fort.
Bon alors la question qui lit correctement OpenDocument ? puisque cela n'impose pas de logiciel.-
[^]Re: Interdit d'interdire
Posté par Mathieu Stumpf (page perso, ) le 24/04/2006 à 14:20. (lien). Évalué à 7.http://fr.wikipedia.org/wiki/Opendocument#Applications_prena(...)
Voila, tiens d'ailleurs je vois que scribus fait de l'import! Ça existe l'équivalent genre importer du word dans adobe chez-pas-quoi?
-
-
-
[^]Re: Interdit d'interdire
Posté par Colin Leroy (page perso, ) le 24/04/2006 à 11:17. (lien). Évalué à 10.OBLIGATOIRE, INTERDIT, RECOMMANDÉ me semblent être une traduction presque texto des "MUST, SHOULD, MAY" et leurs négatifs des RFCs.
Les specs de standards doivent être très directives si leur(s) auteur(s) veut bien se faire comprendre, et que les développeurs d'applications implémentant lesdits standards n'aient pas de latitude pour interpréter comme ils le sentent...-
[^]Re: Interdit d'interdire
Posté par desertpingouin () le 24/04/2006 à 11:40. (lien). Évalué à 8.Nous avons ici un document de travail qui vise à produire des normes. Des phrases du style "il serait peut-être préférable..." ou "le choix de logiciels non compatible apparaitrait comme peu judicieux" risque de laisser beaucoup de flou non ? Evidemment que ces termes sont "secs" mais ils sont indispensables.
Par ailleurs, c'est un style typique de documents venant de l'administration publique, c'est leur marque de fabrique.
-
-
[^]Re: Interdit d'interdire
Posté par herodiade () le 24/04/2006 à 11:29. (lien). Évalué à 10.si le document doit etre diffusé à quelqu'un qui n'utilise pas oo pourquoi le lui imposer ?
Je crois que tu es mal renseigné et que tu a mal lu.
OpenDocument est une spécification ouverte et qu'on peut librement implémenter (Microsoft et Corel peuvent le faire, s'ils souhaitent que leurs suites bureautiques répondent aux spécifications).
Par ailleur OpenDocument n'impose nullement l'utilisation du logiciel OpenOffice.org, les applications compatibles (libres ou propriétaires) sont maintenant très nombreuses, cf. une liste de ces applications ici: http://en.wikipedia.org/wiki/List_of_applications_supporting(...)
Au passage, c'est assez fascinant, pour un standard normalisé il y a moins d'un an (Mai 2005): on a déjà 8 traitements de texte, 6 tableurs, ... compatibles !
Et c'est justement là un avantage, en terme d'interopérabilité, d'utiliser un format ouvert et libre: celà contribue à nous (et nos correspondants) rendre plus indépendants, moins liés à un éditeur de logiciel précis (bref, l'inverse de ce que tu dit).-
[+] [^]Re: Interdit d'interdire
Posté par renoo () le 24/04/2006 à 11:48. (lien). Évalué à -7."Et c'est justement là un avantage, en terme d'interopérabilité, d'utiliser un format ouvert et libre: celà contribue à nous (et nos correspondants) rendre plus indépendants, moins liés à un éditeur de logiciel précis (bref, l'inverse de ce que tu dit)."
Je partage tout à fait le soucis d'interopérabilité ; je conteste les moyens (interdiction bureaucratique ?) de les obtenir. Encourager l'usage des formats ouverts d'accord ; interdire tout ce qui n'est pas opendocument pas d'accord. L'interdiction va radicaliser les positions et je ne suis pas sur que cela favorisera in-fine l'usage des formats ouverts et libres.
Sur les très nombreuses applications qui lisent le opendocument, il manque des applications importantes AppleWorks, WordPerfect, Office, FrameMaker... si on raisonne en part d'usage, je pense que 90% des utilisateurs ne peuvent pas lire l'opendocument avec les logiciels qu'ils utilisent courrament. Penses tu que cela va réelement favoriser les échanges avec les usagers des services publics ? Pourquoi interdire -regle 27- les échanges vers les vieux formats ouverts et libres (.txt, .rtf...) ?-
[^]Re: Interdit d'interdire
-
[^]Re: Interdit d'interdire
Posté par Pierre Tramonson () le 24/04/2006 à 14:29. (lien). Évalué à 4.Parce que RTF sent le moisi ?
-
[^]Re: Interdit d'interdire
-
-
-
-
[^]Re: Interdit d'interdire
Posté par herodiade () le 24/04/2006 à 12:18. (lien). Évalué à 9.si le document doit etre diffusé à quelqu'un qui n'utilise pas oo pourquoi le lui imposer ?
Oh et j'oubliai, dans ma réponse précédente (s/oo/OpenDocument/):
- La spécification n'impose pas OD dans ce cas (diffusion) : il est seulement recommandé (pas obligatoire) d'envoyer ses documents en OD. Elle impose seulement d'accepter les docs OD. Celà permet de dire: "on n'exige de nos correspondant l'utilisation de Microsoft Word/Excel/..." ou encore: "les correspondants de l'administration peuvent utiliser des logiciels libres et gratuits pour nous envoyer des docs, s'ils le souhaitent", ce qui est la moindre des choses.
- Dans le cas (probablement fréquent) où un l'on ne sait pas quel logiciel ou quelle version du logiciel utilise le(s) destinataire(s), recommander la diffusion des documents au format OpenDocument laisse, à l'inverse de ce que tu dit, un grand choix au destinataire (actuellement, moins d'un an après qu'OASIS ai validé le format, pas moins de 8 traitements de textes et 6 tableurs différents etc.). À l'inverse, le nouveau format (OpenXML) des documents générés par MS Office n'est a ma connaissance pleinement supporté que par les versions récentes de la suite bureautique de Microsoft.
- Les documents générés par nos administrations ne sont pas forcément toujours seulement destinés à un utilisateur précis ; en particulier il peut y avoir des contraintes d'archivage, traitements automatisés (indexation/recherche etc.) au delà de ce qu'à prévu l'éditeur du traitement de texte/tableur/..., et celà n'est vraiment pleinement possible qu'avec un format dont les specs sont ouvertes et librement implémentables (vs. contraintes fonctionnels imposées par les choix d'un éditeur de logiciels).
- Dans une optique de reduction des dépenses, certaines administrations pourraient choisir d'utiliser des logiciels libres et gratuits pour la bureautique (les suites bureautiques propriétaires sont souvent très chères !). En fait, la gendarmerie à déjà fait ce choix. Il est absolument légitime sinon de faciliter, du moins de rendre possible les échanges avec les institutions ayant pris une telle initiative.
- La DGME a certainement pensé à la perenité de ses archives, que seul un format ouvert et libre peut assurer. Un format fermé (ou non documenté) vérouillé (brevets) par un éditeur peut n'être plus supporté dans quelques années ou décennies (cout de la maintenance du logiciel, stratégie pour forcer les utilisateurs à mettre à jour, disparition de l'éditeur ou de son produit, changement des plateformes supportés ...). En utilisant un format ouvert et libre, l'administration se réserve la possibilité de développer ou maintenir des logiciels compatibles avec ses archives et ses choix du moment (plateformes, besoins fonctionnels etc.).
- Dans tout les cas, il y va de la souveraineté de l'État concernant la maîtrise de ses documents et de son SI. Un format propriétaire et fermé laisse le SI / l'acces aux documents sous le contrôle d'un éditeur précis et de ses décisions, stratégies ... (et de celles de l'État où cet éditeur est basé).-
[+] [^]Re: Interdit d'interdire
Posté par renoo () le 24/04/2006 à 12:33. (lien). Évalué à -3.- Dans le cas (probablement fréquent) où un l'on ne sait pas quel logiciel ou quelle version du logiciel utilise le(s) destinataire(s), recommander la diffusion des documents au format OpenDocument laisse, à l'inverse de ce que tu dit, un grand choix au destinataire (actuellement, moins d'un an après qu'OASIS ai validé le format, pas moins de 8 traitements de textes et 6 tableurs différents etc.)...
Je pense que le .txt/.rtf ou meme le .pdf est beaucoup plus lisible par tous que le open-document. Prendre un format qui est normalisé depuis un an et prétendre que les usagers doivent pouvoir le lire parceque 8 traitements de texte le lisent ne me semble pas aller dans le sens d'un meilleur service aux usagers... maintenant ici il ne s'agit que de recommandations donc elles sont transgressables avec des bonnes raisons et peut etre qu'en interne si les différents services se mettent d'accord l'opendocument est interessant.-
[^]Re: Interdit d'interdire
Posté par Yth (Jabber id, ) le 24/04/2006 à 14:31. (lien). Évalué à 3.Pourquoi tu ne veux pas comprendre que la seule obligation ici est de NE PAS refuser un document sous prétexte qu'il est au format OpenDocument ?
Rien n'est imposé en interne, rien n'est imposé concernant ce qu'on envoie aux autres.
N'est imposé que le fait que si quelqu'un t'envoie un document au format OpenDocument, le destinataire DOIT l'accepter et se démerder pour le lire, ce qui est aisé sachant que nombre de logiciels libres (ou pas) savent le faire.
C'est pas plus compliqué que de lire du pdf...
Yth.
-
[^]Re: Interdit d'interdire
-
-
-
[^]Re: Interdit d'interdire
Posté par Tom Debruyne (page perso, ) le 24/04/2006 à 22:13. (lien). Évalué à 4.L'appel à commentaire est la traduction française de RFC (request for comment), tu peux me donner un RFC qui cherche a faire de la promotion en douceur sans froisser les utilisateurs?
J'imagine ta colère lorsque ton système te donne des messages du genre:
rm: cannot remove `clientlog.txt': Permission denied
"Permission denied"? De quel droit? Il devrait plutôt dire:
rm: cannot remove `clientlog.txt': this file is a bit owned by an other user (not that he paid for it, but he kind of write it, so, you understand...), it would be nice of you not to erase it. But since you are a good person, I trust that if you want to remove it, you have a good reason to do so and I will allow you, but please don't do that too often.
;-)
Tom
Formats son et video : MP3 ?! et le Ogg ??
Dans la partie formats son et vidéo on peut voir ça :
Il est RECOMMANDÉ d'utiliser la norme MPEG-1/2 Audio Layer 3 (dite MP3) pour diffuser et sauvegarder des séquences sonores. Règle 0012 Interopérabilité technique
Je ne suis pas spécialiste de la question, mais ne serait-il pas préférable de conseiller le Ogg ?
Si oui, il serait interessant de le signaler sur le wiki, mais n'étant aps sur de moi je ne l'ai pas fait.
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par briaeros007 () le 24/04/2006 à 12:22. (lien). Évalué à 6.amha , si, tant du point de vue royalities que du point de vue technique .
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par herodiade () le 24/04/2006 à 12:45. (lien). Évalué à 6.Oui c'est un peu étrange, sachant que MP3 est breveté et que le propriétaire du brevet impose le paiment d'une licence pour l'implémentation. Dans le même ordre d'idées, il y a aussi:
- "Il est RECOMMANDÉ d'utiliser le format " GIF animé " pour les animations graphiques simples et/ou de courte durée". Pourquoi pas PNG (qui est par ailleur recommandé pour les images "statiques", et surtout qui n'est pas breveté) ?
- "Il est RECOMMANDÉ d'utiliser Flash v7.2 ou Flash v8 pour les animations graphiques complexes et/ou de plus longue durée". Pourquoi pas SVG ?
En plus cette règle me semble incompatible avec la règle d'IHM: "Il est INTERDIT d'utiliser des composants logiciels type ActiveX ou toute autre extension de navigateur (Flash hors animation, VML, etc.) au niveau des IHM Web. Règle 0044 Interopérabilité technique". Bizzare, j'ai du mal comprendre un truc.
- MPEG-2 / MPEG-4 pour les conataineurs vidéo (et codec, dans le cas de MPEG-2): pourquoi pas Théora, Matroska ou Vorbis (qui sont plus performants et libres/ouverts si je ne m'abuse) ?
- MPEG-4 pour les "séquences vidéo haute définition.": à quel moment est-on "haute définition" ? et pourquoi aucun codec n'est préconisé ? (eg. MPEG-4 avec DivX ? ou XviD ? ou H.323 ? AAC ? MP3 ? ...)
- Pourquoi ne rien indiquer (eg. XHTML v1.1 + CSSv2) pour la "présentation en ligne de documents semi-structurés" ? D'ailleur, leur wiki est "XHTML 1 Transitional" (et pas HTML 4.01, comme ils le recommandent pour le web: ils devraient être plus souples sur ce point je trouve, et recommander au choix HTML 4.01 ou XHTML v1 ou v1.1).-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Sébastien Koechlin () le 24/04/2006 à 12:54. (lien). Évalué à 6.PNG ne permet pas de représenter des animations, pour cela il faut utiliser le MNG dont l'implémentation est nettement moins universelle.
Concernant SVG, j'espère bien que l'on va y venir; mais aujourd'hui, les implémentations ne permettent pas vraiment de l'utiliser.
Les deux grandes implémentations à ma connaissance sont Mozilla Firefox sur des versions franchement récentes, et un plugin pour Internet Explorer. Qu'en est-il des autres navigateur. De plus, on parle ici d'animation, l'animation se fait par l'utilisation de javascript sur l'arbre XML du SVG, les résultats sont franchement déconcernants et les deux implémentations sont très divergentes.
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Mithfindel (page perso, ) le 24/04/2006 à 13:03. (lien). Évalué à 2.Pourquoi pas PNG [...] ?
Je ne suis peut être pas très au courant mais je connais peu (voire pas, à part le Gimp) de logiciels qui sache interpréter le MNG.
Pourquoi pas SVG ?
Parce que c'est "facile" de produire une "video" en Flash (même avec des outils libres) alors que très peu (voire pas, encore une fois) d'implémentations libres de SVG supportent l'animation (à mon grand dam). S'il faut passer par le plugin SVG Adobe et son API DOM non standard...
Et puis s'il y a consultation et appel à commentaires, c'est sans doute pour permettre à tout le monde de s'exprimer et donner des raisons pour l'adoption de telle ou telle technologie :)
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Nicolas Deveaud (page perso, ) le 24/04/2006 à 13:20. (lien). Évalué à 1.Les autres l'on déjà dis, mais peut-être pas tout à fait de la même manière.
Je parlais du MP3/Ogg car le Ogg est quand même assez largement diffusé (on trouve des balladeurs qui lisent du Ogg etc....
Donc le MP3 n'a pas de raison d'être préféré au Ogg.
Concernant le GIF/MNG ou le Flash/SVG, la problèmatique n'est pas la même étant donné que les formats "libre" ne sont pas très diffusés.
Evidemment il serait mieux pour tout le monde que le SVG soit préféré aux Flash, et évidement le MNG devrait être utilisé de préférence au GIF. Mais actuellement en recommendant des format de ce genre, on peut être sur que personne ne suivra ces recommendations (ce qui n'est pas le cas avec le Ogg qui peut être assez facilement lu). Donc je trouve qu'il est normal dans ce cas de se tourner plutôt vers la solution la "moins pire" en attendant qu'une vraie solution arrive.
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Brice Carpentier (Jabber id, page perso, ) le 24/04/2006 à 14:21. (lien). Évalué à 7.
- "Il est RECOMMANDÉ d'utiliser Flash v7.2 ou Flash v8 pour les animations graphiques complexes et/ou de plus longue durée". Pourquoi pas SVG ?
En plus cette règle me semble incompatible avec la règle d'IHM: "Il est INTERDIT d'utiliser des composants logiciels type ActiveX ou toute autre extension de navigateur (Flash hors animation, VML, etc.) au niveau des IHM Web. Règle 0044 Interopérabilité technique". Bizzare, j'ai du mal comprendre un truc.
Oui, tu n'as sans doute pas compris que les bouts de phrase suivant "pour les animations graphiques complexes et/ou de plus longue durée" et "au niveau des IHM Web" ne sont pas identiques.
En gros, ce que je comprends de la règle, c'est que si tu veux faire une animation, il t'est recommandé d'utiliser Flash. Si on parle d'une application web avec une ihm complexe, tu ne dois pas utiliser Flash. Il s'agit de deux champs d'action différent.
-
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Zenitram (page perso, ) le 24/04/2006 à 14:23. (lien). Évalué à 1.C'est le problemes de l'inter-opérabilité : brevet contre diffusion.
Qui connait OGG : 100 fois moins de personnes que le MP3.
Donc je les comprend d'avoir choisi MP3 dans ce cas, comme ils choisissent MPEG-4 pour la vidéo (et pour la vidéo, tu proposes quoi? Pas Theora car pas encore très stable, bref... il y a rien, donc voila, faut bien payer au groupe MPEG dans tous les cas... En attendant dans quelques années que tout ca se déquante.)-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Nicolas Deveaud (page perso, ) le 24/04/2006 à 14:52. (lien). Évalué à 3.Mais le Ogg est déjà bien répandu, et surtout il est lisible par beaucoup de players.
Donc effectivement comme je le disais un peu plus haut, il est compréhensible de favoriser le Gif animé au MNG, ou le flash au SVG. Mais pour le Ogg, c'est moins compréhenssible car le Ogg est très facilement utilisable il me semble.
(enfin en tout cas le débat à été lancé sur le wiki en question.... on verra ce que ça donne)-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par farvardin (page perso, ) le 24/04/2006 à 22:57. (lien). Évalué à 2.il me semble que sous windows winamp (les gens utilisent encore ce truc ou alors ils sont tous passés à w media player ?) peut lire les ogg/vorbis avec sa version de base
-
-
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
-
[^]Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par atlexx () le 26/04/2006 à 09:27. (lien). Évalué à 1.cela concerne essenciellement la france... donc pour l'instant le problème des brevets ne se posent pas il me semble!
cela dit, il est vrai que le ratio d'utilisation de ogg/mp3 ne doit pas être moins bon que celui OpenDocument/MSOffice . Le premier pas OpenDocument aurai pu être suivi ...
Discuter des règles, c'est bien mais sur le Wiki, c'est mieux
Je tenais juste à vous dire que vos remarques sont toutes plus ou moins pertinentes. Malheureusement, je crains fort que les auteurs de cette RGI vont venir lire vos remarques ici. Vous devriez donc faire part de vos idées toutes plus intéressantes les unes que les autres, sur le wiki du RGI !
J'ai déjà débattu des questions relatives à l'OGG, MNG, Flash etc. À vous de rajouter vos idées / de compléter :)
L'administration, ça avance vraiment à un rhythme de sénateurs...
Voilà le message que j'ai laissé sur le forum du sénat, il y a ..... presque 7 ans !!!
http://www.senat.fr/Vforum/cgi-bin/Vforum-1.6.cgi?action=lir(...)
Au moins, cette ordonnance a été mise à jour, on est passé de l'iso-8859-1 à iso-8859-15 ;o)
RDV dans 7 ans... a ce moment là l'UTF-8 aura le vent en poupe...
Wiki est mort...
Les contributeurs l'ont tué ? Bref, quand je veux aller sur le wiki, j'atterris sur une page blanche. Normal ?
-
[^]Re: Wiki est mort...
Posté par Maillequeule () le 24/04/2006 à 18:44. (lien). Évalué à 5.Ils ont enfin fini par se rendre compte que le plus simple pour l'interopérabilité, ca reste l'absence de contenu.
-
[^]Re: Wiki est mort...
Posté par Mathieu Stumpf (page perso, ) le 25/04/2006 à 12:38. (lien). Évalué à 5.Peut être qu'ils ont fermé quand ils vont vu que des gens commencais à participer, chose à laquelle il ne s'attendaient peut être pas...?
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.