Journal : "OOXML is a superb standard" qui a dit ca a votre avis?

Posté par Albert () le 11 septembre 2007
0
Dire une betise aussi grosse c'est bien demontre qu'il est bien aveugle par tout ce qui sort de chez Redmond. Il a toujours eu une admiration sans limite pour les technos microsoftienne (Corba et son desastre dans Gnome par exemple), C# et tout les problemes de brevets (que lui meme admet), silverlight et maintenant microsoft openXML....

Oui oui on parle de l'incomparable, de l'unique Miguel de Icaza.

Il a sorti quelques perles de toutes beautes recemment. Ca fait longtemps qu'il defend microsoft openxml, c'est lui qui a dit que les 6000 pages de microsoft openxml c'etait la meme chose que 600 pages pour ODF. Son raisonnement etant que si tu rajoutais la definition des normes reutilisaient par ODF cela arrivait a un truc comme 5000 pages. En gros pour lui le SVG, openformula (qu'il a reclame a grand cris...), les dates, les unites cela doit etre redefini (avec des bugs) par toutes nouvelles normes...

Enfin voici les deux plus belles phrases:

OOXML is a superb standard


ce qui se traduit par:

OOXML est un magnifique standard


Il a un esprit critique absolument fabuleux... Enfin la raison pour laquelle il dit ca c'est que c'est plus simple de traduire des documents microsoft office (format binaire) dans microsoft openxml... Le coup de l'interoperabilite et de perennite c'est pas tres important.

et surtout, en reponse a la question si silverlight n'a pas de probleme de brevet:

Not as long as you get/download Moonlight from Novell which will include patent coverage.


ce qui se traduit par:

Non pas de probleme (ndt: avec les brevets) tant que vous obtenez/downloadez Moonlight a partir de Novell qui fournira une couverture (ndt: legale) incluant les brevets


En resume, Moonlight (la version silverlight developpe par de Icaza et Novell) c'est un logiciel qui ne risque rien uniquement si vous le recuperez depuis chez Novell. Ce qui veut dire qu'il ne peut pas etre inclu dans aucune autre distribution. C'est un certain point de vue (tres microsoftien) sur le logiciel libre je trouve. Je trouve ca assez ironique surtout en pensant qu'il a lance le projet Gnome parceque KDE n'etait pas libre.

Enfin en disant cela il admet bien que C# est blinde de brevet et que mono en violent pas mal de facon connu.

oups j'ai failli oublier le lien:

http://groups.google.com/group/tiraniaorg-blog-comments/brow(...)

> Lire le journal (95 commentaires, moyenne: 3,2).  

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.

Hmm

Posté par gnumdk (page perso, ) le 11/09/2007 à 13:14. (lien). Évalué à 10.

>pour les technos microsoftienne (Corba et son desastre dans Gnome par
>exemple)

En quoi Corba est une techno microsoftienne?

  • [+] [^]Re: Hmm

    Posté par Albert () le 11/09/2007 à 13:31. (lien). Évalué à -1.

    C'est peut etre pas Corba ... il y a un protocole de com derive de microsoft (desole c'est pas mon domaine ca) qu'il a pousse a mort dans gnome et qui a du etre abandonne tellement c'etait lourd a mettre en place. Pendant ce temps KDE avait mis en place dcop (qui a evolue en dbus) et qui faisait la meme chose mais de facon simple et efficace.

    • [^]Re: Hmm

      Posté par Pat _ () le 11/09/2007 à 14:23. (lien). Évalué à 5.

      C'est plutot (et pas Mickey), que CORBA était (est) un concurrent du microsoftien DCOM, et ce qui avait provoqué pas mal de débats à l'époque c'est l'implémentation bonobo qui a été développée pour Gnome alors que d'autres existaient. Pas directement de crosoft dans le troll, donc.

    • [^]Re: Hmm

      Posté par Antoine () le 11/09/2007 à 14:54. (lien). Évalué à 8.

      (desole c'est pas mon domaine ca)

      C'est surtout de la mauvaise foi absolument minable vu que tu avais déjà sorti cet argument (Corba == Microsoft) et qu'on t'avait déjà répondu que c'était faux.

Esprit critique, quand tu nous tiens ...

Posté par Thomas Douillard () le 11/09/2007 à 13:18. (lien). Évalué à 10.

Il a un esprit critique absolument fabuleux


C'est dangereux l'invocation de l'esprit critique. On pourrait s'intéresser au tien après.

  • [^]Re: Esprit critique, quand tu nous tiens ...

    Posté par Albert () le 11/09/2007 à 13:32. (lien). Évalué à 9.

    et doucement toi, je suis francais. Donc j'ai le droit de critiquer cela fait parti de nos caracteristiques nationales! :)

    • [^]Re: Esprit critique, quand tu nous tiens ...

      Posté par dark_star () le 11/09/2007 à 14:05. (lien). Évalué à 7.

      tiens c'est marrant, avant OOXML je ne connaissais pas ton pseudo, maintenant hop je sais que c'est un coup d'Albert ! en 2 phrases lu

      rien de mechant hein ! c'est juste que ton pseudo rejoins la faune influente de linuxfr, pbpg, etc...

      oui je vais faire un blog

      • [^]Re: Esprit critique, quand tu nous tiens ...

        Posté par briaeros007 () le 11/09/2007 à 14:55. (lien). Évalué à 3.

        enfin albert vs pbpg c'était connu bien avant ooxml

        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
      • [^]Re: Esprit critique, quand tu nous tiens ...

        Posté par Bozo le Clown () le 11/09/2007 à 19:19. (lien). Évalué à 5.

        Non !
        Ca doit doit être un usurpateur parce que le vrai Albert a pris congé de DLFP pour une période indéterminée et ne s'intéresse plus à OOXML
        http://linuxfr.org/comments/864368.html#864368

    • [+] [^]Re: Esprit critique, quand tu nous tiens ...

      Posté par beagf (page perso, ) le 12/09/2007 à 15:04. (lien). Évalué à -2.

      je suis francais

      Vu ton orthographe, on est en droit de se poser des questions à ce sujet...

c'est bô l'amour :-)

Posté par laurent carlier () le 11/09/2007 à 13:31. (lien). Évalué à 1.

http://blogs.gnome.org/iain/2007/09/11/time-for-a-good-ol-fa(...)
http://www.cafepress.com/miggysellout

sympa un T-shirt pour chien :-)

-->[]

ATTENTION

Posté par alexissoft (Jabber id, page perso, ) le 11/09/2007 à 14:05. (lien). Évalué à 2.

PbPg va rappliquer sous très peu !

  • [^]Re: ATTENTION

    Posté par GCN (Jabber id, page perso, ) le 11/09/2007 à 14:14. (lien). Évalué à 2.

    Mais nan... Il est parti en vacances à Hawaii \o/ !

    --> http://linuxfr.org/comments/864736.html#864736

    --
    The UNIX way of sex:
    date;cd ~;gunzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
    • [^]Re: ATTENTION

      Posté par laurent carlier () le 11/09/2007 à 14:32. (lien). Évalué à 6.

      Certainement un de ces fameux séminaires dont les entreprises ont le secret.

      On a plus facilement 100% de participants à Hawaï, qu'a Nancy :-)

      • [^]Re: ATTENTION

        Posté par Rémi Pannequin (Jabber id, ) le 11/09/2007 à 18:47. (lien). Évalué à 2.

        « On a plus facilement 100% de participants à Hawaï, qu'a Nancy :-) »

        Sur les listes, oui ! Dans les salles, j'ai comme un doute...

        Pi c'est très bô Nancy d'abord. « Nancy au printemps c'est presque le midi... » (Joe Dassin). Na ! même pas ironique...

        --
        Qui invente, qui réinvente, quelle importance ? (Yakari, tome 16)
      • [^]Re: ATTENTION

        Posté par Sylvain Sauvage () le 11/09/2007 à 18:57. (lien). Évalué à 8.

        On a plus facilement 100% de participants à Hawaï, qu'a Nancy :-)

        Ça dépend : elle a combien de places Nancy ? (Daniella, on pouvait y aller à trois…)

  • [^]Re: ATTENTION

    Posté par IsNotGood () le 11/09/2007 à 16:18. (lien). Évalué à 5.

    L'avantage avec Miguel de Icaza, est que s'il y a un problème de brevet, il le dit.
    Donc évitez Moonlight.

    • [^]Re: ATTENTION

      Posté par mats (page perso, ) le 11/09/2007 à 16:58. (lien). Évalué à 4.

      Ça, je pense de plus en plus que ça va être difficile, surtout en lisant cette annonce :
      http://tirania.org/blog/archive/2007/Sep-05.html
      En gros, pour ceux qui n'ont pas le temps de lire, ça dit :
      - que Microsoft rend accessible l'ensemble des outils permettant de tester une implémentation des spécifications de Silverlight ;
      - que Microsoft rend accessible l'ensemble des spécifications de Silverlight ;
      - que Microsoft rend accessible les codecs audio et video pour qu'ils soient utilisés par Moonlight (les plateformes supportées sont x86 et x86_64, pour le reste, il faudra rester avec ffmpeg qui a la mauvaise idée d'avoir une licence pas cool pour le commerce :-) ;
      - ...
      donc qu'il existe une réelle collaboration entre Microsoft et Novell.

      En bref, Silverlight va nous être imposé aux forceps (quand on connaît la force commerciale du géant) et c'est même totalement assumé :
      « To me, Moonlight is of crucial importance because I believe that Microsoft will be successful in getting Silverlight deployed in many sites, and as a Linux desktop user (unlike some outraged open source advocates that stick to OSX :-) I want to make sure that I have access to the Silverlight content from my Linux box. » (http://tirania.org/blog/archive/2007/Sep-07.html )

      Voilà

mouais faudrait pas pousser

Posté par nazcafan () le 11/09/2007 à 14:24. (lien). Évalué à 10.

Miguel de Icaza, si je me souviens bien, c'est aussi le mec qui a rendu nautilus et gnome-terminal utilisables, et ça, l'air de rien, c'est quand même quelque chose de très positif pour gnome.

Après, c'est vrai que je suis particulièrement dubitatif concernant certaines de ses prises de positions, mais de là à le peindre en grand guignol, c'est un peu facile. Personnellement, je trouve que ses affirmations sur son blog (au sujet d'OOXML) sont presque gratuites (il ne cite pas grand chose pour soutenir ses dires) mais force est de reconnaître que je n'ai pas la moindre compétence pour lire une spécification de ce type (une fois, j'ai dû consulter les draft papers du C++, et c'était moyen drôle). Finalement mon opinion (très défavorable) sur ce format ne s'est elle pas faite parce que je lis /. et dlfp ?

J'avoue que ma position sur ce sujet est un peu subjective, parce que j'ai lu les critiques faites par les entités du genre no-ooxml (qui s'appuient effectivement sur des arguments techniques), mais ai-je fait l'effort de rechercher des réponses techniques à ces critiques ? non ! Donc finalement, je n'ai vu la question que d'un seul point de vue.

De là à dire que ces réponses existent, c'est autre chose. Donc si quelqu'un pouvait jouer le rôle de l'avocat du diable (non, pas PBPG, avec lui ça finit toujours en guerre des tranchées contre Albert) et m'expliquer posément les aspects techniques positifs de OOXML, je serais ravi de l'écouter.

  • [^]Re: mouais faudrait pas pousser

    Posté par phytos () le 11/09/2007 à 14:38. (lien). Évalué à 10.

    Miguel de Icaza, si je me souviens bien, c'est aussi le mec qui a rendu nautilus et gnome-terminal utilisables, et ça, l'air de rien, c'est quand même quelque chose de très positif pour gnome.

    Il aurait pu rendre le reste de gnome utilisable aussi... ;)

    • [^]Re: mouais faudrait pas pousser

      Posté par IsNotGood () le 11/09/2007 à 16:22. (lien). Évalué à 1.

      > Il aurait pu rendre le reste de gnome utilisable aussi... ;)

      C'était pour Gnome 2.0. Et il a quitté Gnome depuis Gnome 1.4. Aujourd'hui (et depuis de nombreuses années) son influence dans Gnome est quasi nulle (à part son lobbying pro-C#).

  • [^]Re: mouais faudrait pas pousser

    Posté par IsNotGood () le 11/09/2007 à 16:19. (lien). Évalué à 2.

    > Après, c'est vrai que je suis particulièrement dubitatif concernant certaines de ses prises de positions

    On trouvera peut-être une explication dans son compte en banque...

  • [^]Re: mouais faudrait pas pousser

    Posté par benoar (Jabber id, ) le 12/09/2007 à 01:03. (lien). Évalué à 7.

    Les explications de pbpg et ses liens sont parfois intréressants quand on prend la peine de les lire (et d'éviter les commentaires ou il troll trop ...)
    Je pense qu'avec ce qu'il a exposé ici, il y a de quoi se faire une bonne idée (oui c'est long à lire 300 commentaires par news, mais déjà prend les commentaires de pbpg à plus de 0 (oui, yen a pas beaucoup) et tu pourra voir quelques trucs intéressants)

Je suis mauvaise langue...

Posté par windu.2b (Jabber id, page perso, ) le 11/09/2007 à 14:43. (lien). Évalué à 9.

"Oui oui on parle de l'incomparable, de l'unique Miguel de Icaza."

Avant de lire cette phrase, jai cru que tu faisais une dépêche sur PBPG!
Comme quoi...

:-p

  • [^]Re: Je suis mauvaise langue...

    Posté par laurent carlier () le 11/09/2007 à 14:50. (lien). Évalué à 8.

    C'est peut-être la même personne ..... PBPG c'est Miguel de Icaza !

Mon avis ca fait longtemps

Posté par TImaniac (page perso, ) le 11/09/2007 à 15:13. (lien). Évalué à 2.

Le coup de l'interoperabilite et de perennite c'est pas tres important.
Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML : être interopérable avec la principale suite du marché et apporter une "certaine" pérénité aux documents historiquement créé avec un format binaire alacon.

En cela OOXML est superbe : il autorise la traduction de vieux documents depuis un format non sûr vers quelque chose de plus pérenne dans le temps.

OOXML n'a pas le même but qu'ODF, non seulement ca justifie bon nombre de ses défauts (sans les excuser), mais sa justifie son existence et quelque part le fait qu'il ne fait pas double emploi avec ODF.

D'ailleur c'est rigolo de constater que niveau interopérabilité, il est beaucoup plus facile d'implémenter OOXML que ODF, tout simplement parcque OOXML se base sur l'existant qui est bien souvent déjà implémenté. C'est pas moi qui le dit, ni MDI, c'est un développeur de Gnumeric.

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the(...)

En résumé : il y a 2 problématiques dans le support d'un format 'externe' : lire et interpréter le contenu d'une part, et le convertir dans le format natif de l'outil. OOXML cherche à résoudre le premier point : la lecture et l'interprétation sont largement facilité par l'utilisation de technos connues (XML + nombreux outils existant). En conservant la sémantique des vieux documents, il permet aux outils ayant déjà implémentés la conversion vers leur format natif de récupérer une bonne partie du code existant. ODF oblige à repartir "from scratch" en se basant sur la sémantique orientée OOo.

Donc d'un point de vue interopérabilité, si on parle de l'existant, OOXML a tout à fait sa place.

Alors oui, sinon le format a pleins de trucs "crades" qu'on aimerait plus voir, mais ils ont une raison d'être, et heuresement c'est en cela différent de l'ODF, l'OOXML a une raison d'exister : être crade mais dans un but valable : l'interopérabilité.

C'est pas l'avenir, mais une bonne transition.

Pour ce qui est de l'interopérabilité au sens monde des bisounours où on a un format unique Office lisible nativement par tous les outils sans problème, c'est un saint graal inaccessible, les formats Office étant par définition la représentation sous forme de données d'un ensemble de fonctionnalités, à moins de contraindre toutes les suites à avoir exactement les mêmes fonctionnalités et comportement...
Suffit de constater toutes les difficultés autour de l'ODF : tout le monde veut y ajouter ses modifs qui l'arrangerait dans sa suite, et personne ne veut d'un truc qu'il ne peut pas supporter. Au final statu-quo, on s'éloignera jamais vraiment de l'implémentation de référence OOo.

Alors un joli format qui au final ne sera vraiment interopérable qu'avec lui même ou un format crade qui permet d'assurer un minimum d'avenir à des milliards de documents existant...

et surtout, en reponse a la question si silverlight n'a pas de probleme de brevet: Not as long as you get/download Moonlight from Novell which will include patent coverage.
Oui, Novell offre une couverture juridique à ceux qui télécharge Moonlight depuis leur serveur. Et ? Protéger des utilisateurs contre un système de merde c'est mal ? Si ca te plaît pas, tu fais comme pour tous les autres softs libre que tu télécharges tous les jours sur sourceforge où ton repository deb/rpm : tu ne demandes pas de protection à Novell le jour où telle ou telle boîte t'attaque : ils t'offrent une protection, t'es pas obligé de l'utiliser.
C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est dangereux à utiliser sans la protection : tous les autres softs libres violent une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.

Alors oui, chercher à démolir l'OOXML auprès de l'ISO comme le fait IBM est ridicule, quand avant un format prétendu "universelle et interopérable" comme l'ODF a été normalisé alors qu'il n'était pertinemment pas implémentable dans la principale suite Office du marché.
Si l'ODF a le droit d'exister en tant que norme ISO (ce qui est largement compréhensible pour un tas de raison), l'OOXML a également le droit de l'être puisqu'il bouche largement des lacunes de l'ODF.

Après il faut utiliser le processus de l'ISO pour profiter d'une révision du format OOXML et l'améliorer là où ca peut l'être, sans chercher à singer OOo. En cela la proposition de l'AFNOR me paraît tout à fait pertinente : séparer ce qui est le coeur du format et les spécificités à l'interopérabilité avec l'existant.

  • [^]Re: Mon avis ca fait longtemps

    Posté par TImaniac (page perso, ) le 11/09/2007 à 15:25. (lien). Évalué à 2.

    Je corrige ma formulation :
    C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est dangereux à utiliser sans la protection : tous les autres softs libres violent une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.


    -->

    C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est plus dangereux que les autres softs à utiliser sans la protection : tous les autres softs libres violent potentiellement une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.

  • [^]Re: Mon avis ca fait longtemps

    Posté par Gilles G. () le 11/09/2007 à 16:24. (lien). Évalué à 10.

    Si l'ODF a le droit d'exister en tant que norme ISO (ce qui est largement compréhensible pour un tas de raison), l'OOXML a également le droit de l'être puisqu'il bouche largement des lacunes de l'ODF.

    Mais bien sur. En réfléchissant comme ça , on va normaliser tous les formats tant qu'on y est.

    Tu penses ce que tu veux du format OOXML, bien ou mal. Mais ce format n'est pas une norme.

    Une norme ne dit pas: "Un extincteur qui respecte la norme ISO312 est fabriqué suivant le procédé non documenté de la société TRUC."

    Une norme de sécurité sur les voitures ne redéfinit pas les normes sur les pneus.

    Une norme est rédigée suivant un processus ouvert au différents acteurs du marché.

    C'est pourtant simple à comprendre non? OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.

    • [^]Re: Mon avis ca fait longtemps

      Posté par TImaniac (page perso, ) le 11/09/2007 à 16:39. (lien). Évalué à 0.

      Oui, t'as raison en théorie.
      Dans la pratique, l'ODF a été normalisé dans sa V1 sans OpenFormula, ce qui revient à ta réflexion :
      " "Un extincteur qui respecte la norme ISO312 est fabriqué suivant le procédé non documenté de la société TRUC."
      En fait c'était encore pire, c'était : pour respecter la norme ISO312, il faut y mettre... ce que vous voulez on a oublié de le préciser.
      Concrêtement, le processus de normalisation de l'ODF a été laxiste parcque tous les partis étaient d'accord pour accepter son passage ISO, même MS.

      Une norme est rédigée suivant un processus ouvert au différents acteurs du marché.
      Bah que je sache, l'ODF et l'OOXML suivent le même parcours à l'ISO, avec les mêmes acteurs potentiels. Tous peuvent participer à l'amélioration du format. Comme ils pouvaient d'ailleur également le faire à l'ECMA ou à l'OASIS auparavant.
      Mais bon là c'est pareil, c'est la thoérie. Dans la pratique c'est uniquement un rapport de force et d'influence des plus grosses boîtes.

      OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.
      Partant de là, l'ODF n'aurait jamais dû être normalisé, et je suis prêt à parier qu'une floppée de trucs standardisés à l'ISO ont dû avoir les mêmes entorses.

      Cela dis, ca n'empêche pas de chercher à améliorer l'OOXML là où il est critiquer, du moment qu'il ne pert pas son intérêt premier : l'interopérabilité avec l'existant, ce que n'offre pas l'ODF.

      • [^]Re: Mon avis ca fait longtemps

        Posté par Gilles G. () le 11/09/2007 à 17:22. (lien). Évalué à 6.

        En fait c'était encore pire, c'était : pour respecter la norme ISO312, il faut y mettre... ce que vous voulez on a oublié de le préciser.

        Ça n'a donc rien à voir, il y a une différence entre
        * ne pas préciser comment faire par oubli (ça a été corrigé dans les versions suivantes)
        * préciser que la façon de faire _est_ non documentée. Il ne s'agit pas d'une omission, c'est intentionnel.

        Bah que je sache, l'ODF et l'OOXML suivent le même parcours à l'ISO, avec les mêmes acteurs potentiels. Tous peuvent participer à l'amélioration du format. Comme ils pouvaient d'ailleur également le faire à l'ECMA ou à l'OASIS auparavant.

        Tu sais mal.
        Microsoft essaie de faire passer OOXML en procédure fast-track, ce qui implique que les éventuelles contestations soient formulées dans un délai d'un mois (pour une norme de 6000 pages).
        C'est donc bien une tentative d'élimination des autres acteurs du marché.

        >OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.
        Partant de là, l'ODF n'aurait jamais dû être normalisé, et je suis prêt à parier qu'une floppée de trucs standardisés à l'ISO ont dû avoir les mêmes entorses.

        Tu peux m'expliquer ton raisonnement, j'ai du mal à comprendre. Je te dis que OOXML ne peux pas être normalisé parce qu'il réinvente la roue, qu'il y a des éléments non documentés, et que le processus n'est pas ouvert, et tu me dis: "Partant de là, l'ODF n'aurait jamais dû être normalisé"
        ????

        Cela dis, ca n'empêche pas de chercher à améliorer l'OOXML là où il est critiquer, du moment qu'il ne pert pas son intérêt premier : l'interopérabilité avec l'existant, ce que n'offre pas l'ODF.

        OK.
        Mais OOXML n'est pas une norme.

        • [+] [^]Re: Mon avis ca fait longtemps

          Posté par TImaniac (page perso, ) le 11/09/2007 à 20:39. (lien). Évalué à -2.

          * ne pas préciser comment faire par oubli (ça a été corrigé dans les versions suivantes)
          * préciser que la façon de faire _est_ non documentée. Il ne s'agit pas d'une omission, c'est intentionnel.

          Le résultat est le même : c'est pas implémentable. Et c'est quelle ligne dans la doc OOXML qu'il est écrit que tel ou tel truc doit être utilisé et que c'est explicitement dis que ce n'était pas documenté ?
          Ensuite OpenFormula n'était pas un vrai "oubli", c'était "on sait, mais on verra plus tard, pas le temps, faut le logo ISO au plus vite avant MS". Bref pareil, voir pire, le but n'est même pas le support d'un vieux truc non documenté par soucis de compatibilité, c'est un but purement marketing, on se dépêche pour avoir le logo avant le concurrent. Ca en dit long sur l'envie d'être interopérable avec le dis concurrent au passage.

          Mais prenons un exemple plus parlant : ODF fait explicitement référence à la possibilité d'intégrer une applet Java. C'est pas normalisé, c'est pas à l'ISO. Tu vas me dire c'est quand même documenté, spécifié. Oui et ? L'implémentation de Java dépend d'une foultitude d'autres normes, ne serais-ce que, au pif, MPEG-4. Ensuite cette référence à Java aurait pu au moins avoir le bon goût de faire référence à la spec Java publiée par Sun, pour au moins savoir quelle version implémenter. Enfin si y'a également une vague référence à JDBC en bas du document, à noter que c'est dans un autre contexte que l'intégration d'Applet Java.

          L'ODF est-il intégralement implémentable dans ces conditions autrement que par Sun ?

          On gueule après MS qui fait référence à des formats non standard alors qu'à l'ISO il existe des équivalent normalisés, et qu'un format ISO devrait faire référence à d'autres normes ISO plutôt que réinventer la roue : ben pourquoi l'ODF ne fait pas référence à la norme ISO du CLR/C# ?
          Bizzarement personne n'a rien trouvé à redire au moment du processus de normalisation ISO. Par contre le moindre détail similaire dans OOXML est décrit comme un scandale.

          De la même manière dans l'ODF il est fait mention de JavaScript comme langage de script possible (à noter que la porte est laissé ouverte à n'importe quoi comme langage de script, avis aux implémenteurs du format qui vont s'arracher les cheveux si demain quelqu'un choisi autre chose que ce fait Sun) : aucune référence à la norme ECMA, et encore moins à la version qui serait bon d'utiliser.

          Autre constat rigolo, on gueule après MS qui propose de faire référence à des trucs non documentés et des blobs binaires, notamment parcqu'il est possible d'intégrer des composants externe style OLE.... ben la norme ODF autorise l'inclusion de composant OLE.

          Microsoft essaie de faire passer OOXML en procédure fast-track, ce qui implique que les éventuelles contestations soient formulées dans un délai d'un mois (pour une norme de 6000 pages).
          C'est donc bien une tentative d'élimination des autres acteurs du marché.

          Oui MS tente le fast-track. Et ? C'est pas tant pour éliminer les autres acteurs du marché, s'ils avaient voulu faire ca, ils seraient pas passé par l'ECMA avant. Le fast-track, c'est pour avoir l'ISO le plus vite possible, étant donné qu'il y a un intérêt commercial à avoir le label "ISO". Ca n'élimine pas les autres acteurs, au contraire, cela leur fait prendre des risques supplémentaires, la preuve en est la rébellions de certains acteurs (IBM par exemple) qui pousse à un vote négatif.
          Quand à l'ECMA, pourquoi Sun & IBM sont pas allez y faire un tour ? Personne ne les en a empêché que je sache. Non la réalité c'est qu'ils en avaient rien à battre, leur seul intérêt, c'est que l'ODF soit le seul a avoir le logo ISO pour mieux le vendre en tant que caution auprès des grands organismes.

          , qu'il y a des éléments non documentés, et que le processus n'est pas ouvert, et tu me dis: "Partant de là, l'ODF n'aurait jamais dû être normalisé"

          Bah ODF y'a des éléments qui n'étaient pas documenté (cf exemples plus haut), et le processus était aussi "ouvert" que celui de l'OOXML : à savoir viendez tous, faites 2 ou 3 modifs du moment que c'est compatible avec notre produit ; faites parler Sun avec OOo d'un côté, MS avec MS Office de l'autre, c'est kif kif bourriquot la même sitatution : MS s'en est rendu compte et à claquer la porte de l'OASIS, de l'autre côté Sun s'attendait au même comportement est a même pas été voir ce qui se passait à l'ECMA.

          Tout ca pour dire que pour moi ODF n'est pas plus ou moins respectable que l'OOXML, les 2 ont leurs raisons d'êtres, ont beaucoup de défauts en commun, ont suivit un processus de normalisation à peu prêt similaire... Ah non, pour l'ODF il n'y a pas eu une bande blogger anti-MS à FUDer en permanence. Et c'est ce qu'essai de dire MDI, qui lui a le mérite d'être un développeur ayant déjà touché au domaine à travers le développement de Gnumeric.

          • [^]Re: Mon avis ca fait longtemps

            Posté par ndesmoul () le 12/09/2007 à 08:42. (lien). Évalué à 4.

            Oui MS tente le fast-track. Et ? C'est pas tant pour éliminer les autres acteurs du marché, s'ils avaient voulu faire ca, ils seraient pas passé par l'ECMA avant. Le fast-track, c'est pour avoir l'ISO le plus vite possible, étant donné qu'il y a un intérêt commercial à avoir le label "ISO". Ca n'élimine pas les autres acteurs, au contraire, cela leur fait prendre des risques supplémentaires, la preuve en est la rébellions de certains acteurs (IBM par exemple) qui pousse à un vote négatif.


            En même temps la procédure fastrack ne peut être mise en oeuvre que si la proposition est normalisée ailleurs. Le plus facile est de passer par l'ECMA qui accepte des propositions d'industriels selon un processus sans doute beaucoup moins contraignant que d'autres organismes de standardisation. Donc pour passer en fasttrack à l'ISO le passage par l'ECMA était pour MS la meilleure stratégie.

            D'autre part il me semble qu'IBM (et SUN?) ont participé au vote à l'ECMA sur OpenXML. IBM a voté contre (SUN je sais pas).

            Le problème avec l'ECMA c'est que les propositions ne sont pas examinées avec autant d'intensité qu'à l'ISO. La proposition n'a guère été modifiée lors de son passage à l'ECMA. Pourtant il est maintenant évident après le vote à l'ISO que la proposition en l'état pose problème et qu'elle devra être remaniée.

  • [^]Re: Mon avis ca fait longtemps

    Posté par IsNotGood () le 11/09/2007 à 16:39. (lien). Évalué à 6.

    > Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML

    Le classique argument à la con. Étant donné ce que veut faire MS de OOXML, cette "interopérabilité et périnnité" ala MS, MS peut l'avoir sans labélisation ISO, sans XML, sans spèc, etc...
    MS le fait très bien depuis des années. Et c'est encore ce que va faire MS, sauf que cette fois il y a la doc (mal foutue, compliqué, partiellement documenté, etc...). En passant, il n'y a que la version actuelle de OOXML qui ne pose pas de problème de brevet (et encore, ce n'est pas claire). Il n'y a aucune garantie pour les versions suivantes (contrairement à ODF).

    MS veut l'intéropérabilité avec MS. MS veut la pérennité de son monopole sur les suites bureautique et sur le format de document des suites bureautiques.

    > Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML

    Pas de problème, au moins 95 % des documents MS-Office sont importables dans ODF. Et avec ODF il y a une meilleur intéropérabilité, pas de dépendance envers une société, pas de problème de brevet, le format est bien foutu et s'assimile bien plus facilement que OOXML (ce qui garantit son ouverture à plusieurs sociétés), etc...

    Bref, pour 95 % des documents MS, ODF est un meilleur choix.

    • [+] [^]Re: Mon avis ca fait longtemps

      Posté par TImaniac (page perso, ) le 11/09/2007 à 18:36. (lien). Évalué à -1.

      sauf que cette fois il y a la doc (mal foutue, compliqué, partiellement documenté, etc...).
      Un coup la doc est trop longue, un coup il manque des trucs, un autre coup elle est compliquée, bla bla bla.
      Y'a sûrement du vrai dans ce que tu dis, mais pourquoi personne ne se plonge dans le foutu format ODF pour vraiment comparer ? Tout ce qu'on a, c'est une bande de geek libriste anti-MS qui répètes les arguments de 2 ou 3 personnes qui ont regarder avec une impartialité toute relative un seul format, le format à abattre : OOXML.
      Ils auraient fait le même boulot sur l'ODF, on aurait pas vu des choses aussi absurde que l'absence d'OpenFormula dans la V1.
      La vérité c'est qu'il y a une véritable campagne de dénigrement, et même si beaucoup de critiques techniques sont valables, elles ne justifient que rarement à elle seul la non-acceptation à l'ISO, sinon l'ODF n'aurait jamais dû passé. Par contre je le répète, ca peut être une bonne base pour améliorer l'OOXML.

      De plus dans la vraie vie, je l'ai déjà dis plus haut, les développeurs constatent quoi :
      - ODF est plus difficile à implémenter que OOXML, parcqu'OOXML se base sur des concepts largement connus (ca fait longtemps qu'on cherche à importer/exporter les .doc & co).
      - l'ODF qui existe déjà depuis un bon moment, et aucune suite bureautique n'offre de support acceptable en dehors de OOo.

      Bref, l'ODF n'a toujours pas atteind son objectif (enfin si, l'objectif profond était juste pour SUN d'avoir le logo commercial ISO, tout comme MS avec OOXML d'ailleur), y'a que les barbus pour y croire.

      Allez bonne soirée, ce post sera de toute façon moinsser, je constate que le niveau des possibilités de discussion sur ce site ne se sont pas améliorer depuis la dernière fois.

      • [+] [^]Re: Mon avis ca fait longtemps

        Posté par TImaniac (page perso, ) le 11/09/2007 à 21:07. (lien). Évalué à -3.

        Tiens tant que j'y suis, je continuais à lire en diagonal la norme ODF pour voir toutes les énormités qui s'y trouve, je suis tombé sur les formats d'images :
        D'après les exemples proposés, on peut inclure des images .gif. Pourquoi gif ? Pourquoi ne pas faire référence explicitement à la norme ISO du format PNG largement implémenté et bien plus performant ?
        Plus loin je vois une référence à un JPG... mais où est la liste exhaustive de tous les formats d'images à implémenter ? Je peux utiliser n'importe quoi ? Non je suppose que là encore, la référence c'est OOo, c'est comme pour OpenFormula : z'avez qu'à regarder ce que fait le soft de référence.
        Attention, là encore je ne dis pas que OOXML est mieux sur ce point, mais je cherche à attirer l'attention sur le fait que l'ISO normalise des trucs qui théoriquement ne devrait pas l'être, comme l'ODF, et des trucs gros comme ca que je trouve en 5 minutes. Pas des détails qui plus est. Donc faire chier l'OOXML pour son manque de documentation (et quand on voit les chipotages des critiques techniques, on se pose des questions), je trouve ca vraiment pitoyable, pour MS et SUN encore je comprend, y'a une raison commercial, pour le libre, c'est de l'anti-MS primaire.

  • [^]Re: Mon avis ca fait longtemps

    Posté par Zenitram (page perso, ) le 11/09/2007 à 16:51. (lien). Évalué à 9.

    En cela OOXML est superbe : il autorise la traduction de vieux documents depuis un format non sûr vers quelque chose de plus pérenne dans le temps.

    Plus pérenne???
    Dis-moi comment.
    Car OOXML, c'est une peinture XML autour de blocs binaires non documentés : on documente un peu l'enveloppe, et les gens disent "super, c'est plus pérenne"
    Sauf qu'on s'en fou de l'enveloppe si le contenu est toujours à la sauce MS, et que MS.

    OOXML est autant pérenne que le vieux .doc, jamais "plus" pérenne : seul MS peut le lire, et dépend donc de la pérennité de MS.
    Autant garder les vieux .doc dans ce cas, autant normaliser les vieux .doc avec ton argumentation. Et autant normaliser MS Windows, pour la pérennité aussi. Ton argumentation ne tient pas une seule seconde, je ne comprend pas que tu puisses te sentir bien avec ce mensonge ne toi.

    • [^]Re: Mon avis ca fait longtemps

      Posté par TImaniac (page perso, ) le 11/09/2007 à 18:26. (lien). Évalué à 1.

      Car OOXML, c'est une peinture XML autour de blocs binaires non documentés
      Affirmation gratuite de quelqu'un qui n'a ni lu les specs, ni utilisé concrêtement le dis format.
      Dans la vraie vie, je me suis amusé à tester certains export doc vers docx, dans la plupart des scénarios il n'y a pas le moindre bloc binaire dans le document XML généré.
      Bon après c'est ma petite expérience sur des documents pas forcement représentatif (je me suis pas amusé avec des trucs style OLE), le fait est qu'il y a des situations où ton affirmation n'est pas vérifiée.

      Après si tu prends un document ODF, tu peux très bien inclure dedans un bout de Java, tu peux aussi considérer cela comme un blob binaire (pas spécialement standardisé à l'ISO au passage, et qui a sa propose spécification qui évolue de manière entièrement désynchronisé avec ODF).

      Sauf qu'on s'en fou de l'enveloppe si le contenu est toujours à la sauce MS, et que MS.
      Et le format ODF qui est à la sauce Sun, c'est pas pareil ? Non bien sûr, Sun c'est le gentil, MS c'est le vilain. Argument de poids ca.

      seul MS peut le lire, et dépend donc de la pérennité de MS.
      Faut pas abuser, comme je l'ai dis c'est du XML, et faut pas être abruti pour comprendre la structure du document avec un éditeur de texte lambda, même sans la doc de référence. Donc même si certaines parties sont peut être mal documentées et difficilement implémentable, la plus grande partie d'un document "standard" est largement interprétable et exportable vers un autre outil que celui de MS. Bref, même si la pérénité de l'intégralité des documents n'est sans doute pas assurée sans le support de MS, c'est quand même mieux que le vieux .doc pas documenté, quoique t'en dise.
      Ensuite la structure même XML du document permet de "récupérer" un document corrompu (erreur lors de l'écriture sur disque), avec n'importe quel éditeur de texte. Même d'un point de vue technique, les documents sont en soit plus pérenne qu'un .doc binaire.

      autant normaliser les vieux .doc avec ton argumentation.
      Ca aurait supposé un minimum de doc, ce qui aurait effectivement déjà été une grande avancée.

      Et autant normaliser MS Windows, pour la pérennité aussi.
      Si normaliser veut dire documenter obligatoirement, là encore ca ne peut être que bénéfique, même si ca veut rien dire "normaliser" un OS. Enfin bon comme toute comparaison, celle ci est plus que douteuse, on parle d'un format de données, et de la pérénité des informations représentées, pas d'un OS.

  • [^]Re: Mon avis ca fait longtemps

    Posté par Bozo le Clown () le 11/09/2007 à 19:34. (lien). Évalué à 6.


    Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML : être interopérable avec la principale suite du marché et apporter une "certaine" pérénité aux documents historiquement créé avec un format binaire alacon.

    Moi aussi je pensais comme toi jusqu'à ce que je découvre la diférence entre "interopérabilité" et "compatibilité'.

    ...
    Il convient de distinguer 'interopérabilité et 'compatibilité'. Pour être simple, on peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble et interopérabilité quand on sait pourquoi et comment ils peuvent fonctionner ensemble. Autrement dit, on ne peut parler d'interopérabilité d'un produit ou d'un système que si on en connaît intégralement toutes ses interfaces.
    ...

    http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
    Les 10% d'applications qui ne pourront jamais lire l'OOXML font de ce format un format de compatibilité mais pas d'interopérabilité.

    Il s'agit peut-être d'un standard mais pas d'une norme

    ...

    En langue française, il n'y a pas équivalence entre un standard et une norme. Une norme résulte d'un processus de normalisation effectué dans le cadre d'un organisme public. Un standard peut être défini par n'importe quel organisme privé (produit standard), puis devenir une norme.
    ...

    Un produit standard n'implique pas que ses interfaces soient connues. Quand elles le sont entièrement, on peut parler d'interopérabilité.
    ...

    http://fr.wikipedia.org/wiki/Standard

    • [^]Re: Mon avis ca fait longtemps

      Posté par Éric (Jabber id, page perso, ) le 11/09/2007 à 20:56. (lien). Évalué à 2.

      Étonnante affirmation. Mais en même temps pas vraiment quand on y réfléchit. Wikipedia est majoritairement contrôlée par des informaticiens et les sujets qui tiennent à coeur à cette catégorie reflètent souvent leur opinion.
      Wikipedia est un très beau projet et c'est un très bon moyen de s'informer et de ce documenter. Par contre c'est le dernier endroit où il faut aller chercher des définitions. Surtout des définitions de mots pris d'assaut par la communauté informatique comme "norme", "standard", "brevet", "droit d'auteur", etc.

      Prenons des sources un peu moins biaisées pour ce genre d'exercices, des dictionnaires.

      "Standard" n'apparait ni dans le Littré ni dans l'Académie française. On le trouve tout de même dans le portail lexical de l'atilf/cnrs. On y lit

      Modèle, norme de fabrication à suivre dans la réalisation de produits en série; ce qui est conforme à la norme.

      Difficile de dissocier ensuite "norme" de "standard" vu qu'on définit un standard comme quelque chose de conforme à la norme ou comme une norme de fabrication.

      Cherchons plus loin. "Norme" apparaît lui dans le dico de l'Académie française. On y lit :
      Type, état, comportement qui peut être pris pour référence ; modèle, principe directeur qu'on tire de l'observation du plus grand nombre


      Et là c'est clair : Non une norme n'est pas forcément édictées par un organisme public, il n'en est nulle part mention. Mais ça va même plus loin, la norme n'est même pas forcément édictée ou documentée tout court. Un comportement directeur *observé* chez le plus grand nombre est qualifiable de norme.

      Les informaticiens ont fait évoluer le terme pour leurs propres intérêts. La première étape c'est de dissocier ce qu'ils (nous) appellent "standard de fait" de la "norme documentée" -- alors que la définition de "norme" est justement celles qu'ils attribuent au "standard de fait" -- afin de nier le terme aux formats/logiciels en quasi monopole. Plus récemment on trouve l'idée qu'une norme est forcément publique, je n'ai cependant vu cette idée que pour disqualifier OOXML, jamais dans un autre débat.

      Il va falloir se faire une raison. Je ne parle pas de se faire une raison vis à vis de OOXML. Je parle d'apporter de vrais arguments contre OOXML, il y en a bien assez sans tenter des pirouettes de vocabulaire pour détourner les termes à notre avantage.

      • [^]Re: Mon avis ca fait longtemps

        Posté par Bozo le Clown () le 11/09/2007 à 21:09. (lien). Évalué à 3.

        Et pour "interopérabilité" vs "compatibilté" tu peux apporter des contradictions identiques.

        La question serait alors : Un format se doit-il d'être seulement "compatible" ou "intéropérable" pour être validé par un organisme de normalisation ?

        Sinon je ne cherche pas à "disqualifier" OOXML sur une pirouette de vocabulaire mais simplement à mieux comprendre ce à quoi correspond un standard/norme et partant de là si OOXML peut s'y conformer.
        Et plus d'un m'en est témoin ici.

        • [^]Re: Mon avis ca fait longtemps

          Posté par Éric (Jabber id, page perso, ) le 11/09/2007 à 21:18. (lien). Évalué à 2.

          Désolé de m'être emporté.

          Le fond vaut à mon avis fortement d'être signalé. La forme un peu agressive que je regrette juste après coup (comme à chaque fois) vient probablement du fait de wikipedia. Je m'énerve à chaque fois que je vois que ma communauté (le libre) en fait un outil de propagande et/ou y casse trop souvent l'objectivité et le NPOV. Enfin, j'ai réagit là bas aussi.

          • [^]Re: Mon avis ca fait longtemps

            Posté par Bozo le Clown () le 11/09/2007 à 21:38. (lien). Évalué à 2.

            Pas d'offense.

            Moi aussi, j'ai eu un doute en lisant "En langue française"

            Mais ma question reste valable.
            Dans un autre thread, il y eu des [litote]échanges[/litote] sur le fait que certaine parties de OOXML faisaient référence à des formats propriétaires et disqualifiaient de ce fait OOXML en tant que norme.
            Je pose la question à la cantonade:
            Y a t'il des critères précis d'acceptation à l'ISO qui mentionnent quels sont les mécanisme d'extensions acceptables ou est-ce du domaine de l'arbitraire ?

            Timaniac y fait aussi allusion avec ODF et Java.

  • [^]Re: Mon avis ca fait longtemps

    Posté par Albert () le 11/09/2007 à 21:40. (lien). Évalué à 1.

    ca faisait longtemps que l'on t'avait pas vu mais bon c'est vrai que la j'ai attaque ton idole de Icaza puis ton pote pbpg etant parti en vacances il faut bien Bozo_leclown et toi pour prendre le relais et jouer a Don Quichotte.

    C'est assez rigolo de voir exactement les memes arguments (faux) et les memes techniques dans vos messages que ceux donne et utilise par pbpg :)

    Ah vivement des voitures aux roues carres pour redefinir une nouvelle norme!!! Cela sera plus pratique pour descendre les escaliers. Imagine donc la scene dans un des film avec Bournes ou la mini descend les escaliers de montmartre tout en douceurs.

    • [^]Re: Mon avis ca fait longtemps

      Posté par TImaniac (page perso, ) le 11/09/2007 à 22:21. (lien). Évalué à 2.

      Tu veux pas essayer d'argumenter plutôt que de poser des affirmations gratuites et chercher à dénigrer les propos de l'autre en tentant de l'humour à 2 balles ?

      Implémenter entièrement ODF suppose d'implémenter Java par exemple plutôt que de réutiliser les normes ISO qui existent (bah oué CLR/C# c'est ISO) : ca te choque pas ?

      Gueuler après l'OOXML qui propose l'inclusion de blob binaire, notamment les composants OLE, quand l'ODF propose également d'inclure des composants OLE, ca te choque pas que la critique n'aille que dans un sens ?

      ODF oublie de préciser les formats d'images qui doivent être supportés, on peut en déduire d'après les exemples de la norme ODF qu'il doit être possible d'inclure les formats JPG et GIF (alors que pour ce dernier y'a PNG qui est norme ISO) : où s'arrête-t-on dans le support des formats ? Un format d'image qui n'est pas utilisé par OOo mais par une autre suite est considéré comme un blob binaire ? Pourtant ca respecte bien la norme qui "oublie" de proposer une liste finie de formats à utiliser. Ca te choque pas ?

      L'ODF propose d'inclure des scripts qui peuvent là encore être "par exemple" en Javascript... ca suppose encore implémenter ce langage si on veut supporter intégralement un document pondu par OOo ? Et si j'utilise un autre format de script, à priori l'ODF ne m'en empêche pas, comme pour les images non ? Ca te choque pas d'un point de vue interopérabilité ?

      Ca te choque pas que tout ca soit passer comme une lettre à la poste à l'ISO ? Tu trouves que c'est des "détails" ? Tu trouves normal que l'ISO est accepté sans bronché qu'un format de feuille de calcul ne propose pas dans la V1 de documentation sur comment écrire... les formules? (corrigé avec OpenFormula dans la V1.1) ?

      Dernier point : ca te choque pas que j'ai trouvé la plupart de ces "énormités" en lisant en diagonale les specs d'ODF ? Que vais-je trouver si je lis toute la norme ?

      Si rien de tout ca ne te choque (ce qui ne m'étonnerait pas vu comment ton objectivité et ta haine viscérale de MS t'ouvre l'esprit), je vois même pas ce que trouves à redire sur l'OOXML, il est au moins aussi "magnifique" qu'ODF.

      • [^]Re: Mon avis ca fait longtemps

        Posté par Albert () le 12/09/2007 à 02:36. (lien). Évalué à 2.

        Implémenter entièrement ODF suppose d'implémenter Java par exemple plutôt que de réutiliser les normes ISO qui existent (bah oué CLR/C# c'est ISO) : ca te choque pas ?

        C# 1.0 est passe en fast-track a l'ISO en effet. Pourquoi ne pas l'utiliser dans ODF? Peut etre que le fait que C# 2.0 et C# 3.0 ne sont pas ISO, casse la compatibilite avec la norme ISO.

        Pourquoi Java plutot que C# 1.0? A mon avis pour 2 raisons, la premiere c'est que Microsoft a refuse de faire partie du comite definissant ODF, ca aide pas a pousser ses technos, la deuxieme c'est que C# 1.0 n'etait pas mure (vu les changement avec les versions suivantes c'est assez evident.

        Enfin bon tu me montres les manques dans la doc de Java STP. Parceque bon les VML et autre joyeusete ca manque "legerement" de doc. De meme pour javascript, la doc est la ou pas?

        Ca te choque pas que tout ca soit passer comme une lettre à la poste à l'ISO ? Tu trouves que c'est des "détails" ? Tu trouves normal que l'ISO est accepté sans bronché qu'un format de feuille de calcul ne propose pas dans la V1 de documentation sur comment écrire... les formules? (corrigé avec OpenFormula dans la V1.1) ?

        Ah non non il est pas passe comme une lettre a la poste, il est carrement passe a l'unanimite et pas en fast-track.

        Si Microsoft avait des commentaires a faire sur le format ODF ils avaient qu'a le faire avant de voter.

        Un peu comme l'on fait les personnes qui ne voulaient pas du format en l'etat microsoft openxml. Si toutes les corrections demandes sont mises en place pour fevrier, je ne vois pas pourquoi le format ne passerait pas la norme ISO. Le seul probleme c'est que je vois assez mal Microsoft faire evoluer son format de facon a respecter cela car il faudrait mettre a jour tous les Microsoft Office 12 vendu.

        Cela me ferait bien chier d'avoir 2 formats totalement redondant de format office mais si microsoft openxml est change suffisemment, c'est a dire que d'autre personnes que Microsoft puisse l'implementer je n'aurai pas grand chose a dire. En attendant la proposition de norme tel que presente n'etait pas en etat pour etre une norme ISO.

        • [+] [^]Re: Mon avis ca fait longtemps

          Posté par TImaniac (page perso, ) le 12/09/2007 à 07:23. (lien). Évalué à -1.

          ? Peut etre que le fait que C# 2.0 et C# 3.0 ne sont pas ISO, casse la compatibilite avec la norme ISO.
          Mouarf ! L'excuse bidon. Déjà on parle pas du langage, mais d'un bytecode d'applet, on parle donc de la CLR vs Java. Donc C# 2.0 ou C# 3.0, s'est pareil, c'est la CLR 2.0. Cette dernière est en cours de normalisation ISO. Et je vois pas ce qui empêche de supporter la CLR 1.0 dans la version actuelle d'ODF et de passer à la CLR 2.0 lors du prochain draft ODF.
          De toute façon c'était juste un exemple pour montrer 2 choses :
          - ODF utilise aussi des trucs non ISO, même quand y'a des trucs à l'ISO : d'après vos théories à 2 balles, ODF "réinvente la roue" et ne devrait pas être ISO.
          - La présence de Java et autres JDBC qui non rien d'ISO ou même OASIS/ECMA/cquetuveux montre clairement l'influence omniprésente de Sun sur l'ODF, et relativise complètement vos arguments bidon concernant l'ouverture du processus de standardisation à l'OASIS et l'indépendance vis-à-vis d'une entreprise. Dans la vraie vie, ODF est aussi liée à Sun que l'est OOXML à MS.

          Enfin bon tu me montres les manques dans la doc de Java STP.
          Mais on sait même pas de quoi on parle ! C'est juste marqué "applet Java", ca inclu quoi ? Quelle version de la plateforme ? Quelles bibliothèques ? On sait même pas quelle doc lire !

          De meme pour javascript, la doc est la ou pas?
          Quelle version ? L'ECMAScript (là encore ils parlent de Javascript, ca en dit long sur l'indépendance envers Sun) a plein de version, la dernière étant peu implémentée, je prend laquelle ? ECMAScript 4 qui apparaîtra dans le futur Mozilla ? Un plus vieux ? Lequel ?
          De plus c'est clairement mis "for example", je peux très bien y mettre du Python ou du Ruby, voir du Perl ou n'importe quoi, non seulement certains de ces langages sont notoirement mal spécifiés (Python) et il est impossible de supporter universellement tout et n'importe quoi !

          Ah non non il est pas passe comme une lettre a la poste, il est carrement passe a l'unanimite et pas en fast-track.
          Oui excuse moi, même à la poste ils ne sont pas aussi efficace. T'as saisie l'idée : certaines énormités n'auraient jamais dû passé. Ou alors si ca n'a dérangé personne à l'époque, faut pas venir faire chier l'OOXML avec des critiques du genre.

          Si Microsoft avait des commentaires a faire sur le format ODF ils avaient qu'a le faire avant de voter.
          MS ne remet pas en cause la normalisation à l'ISO d'ODF je te rappelle.

          Si toutes les corrections demandes sont mises en place pour fevrier, je ne vois pas pourquoi le format ne passerait pas la norme ISO.Sauf que grosso-merdo, les détracteurs d'OOXML comme IBM & Co ne veulent pas de corrections, ils cherchent juste un maximum d'arguments pour que le format ne soit pas normalisé du tout, en tout cas le plus tard possible, pour que seul ODF est le logo ISO.

          Le seul probleme c'est que je vois assez mal Microsoft faire evoluer son format de facon a respecter cela car il faudrait mettre a jour tous les Microsoft Office 12 vendu.

          Je ne vois pas où est le caractère obligatoire. Après MS sort toujours des services packs, des plugins d'import/export, des patchs, et des versions majeurs. Y'a que l'embarras du choix pour diffuser ce support.

          Cela me ferait bien chier d'avoir 2 formats totalement redondant
          C'est pour ca que j'ai tenté d'expliqué que ces formats ne sont pas totalement redondant, même si une grande partie se recoupe, ils n'ont pas le même objectif, ce qui se voit facilement aux différents arguments des détracteurs de tout bord : les avantages de l'un sont des inconvénients pour l'autre.

          attendant la proposition de norme tel que presente n'etait pas en etat pour etre une norme ISO.
          Je suis bien d'accord, même mine de rien quand on y réfléchi, l'ODF était pas plus prêt. La V1.1 comble la plus grosse énormité, mais y'a encore du boulot.

          Mais sérieusement ca te choque pas tout ce que j'ai trouvé sans être expert et que ca soit passé à l'ISO ???

          • [^]Re: Mon avis ca fait longtemps

            Posté par Albert () le 12/09/2007 à 08:51. (lien). Évalué à 2.

            MS ne remet pas en cause la normalisation à l'ISO d'ODF je te rappelle.

            Donc toutes tes critiques sur ODF sont nulles et non avenus. Si le format a l'epoque de la normalisation etait si nul il n'y avait qu'une chose a faire: dire "Non avec commentaires". Microsoft ne l'a pas fait tout simplement parceque bien sur qu'il y a des manques, des erreurs et des trucs qui ne devraient pas etre dans ODF 1.0 mais ce format est totalement implementable dans n'importe quel suite office. Le format microsoft openxml tel que presente en fast track ne pouvait etre implementable que dans Microsoft Office, de plus je vais encore poser la meme question que je pose a pbpg:

            Pourquoi avoir voulu absolument repeter les erreurs de ODF et du format binaire?

            C'etait un combo perdant comme cela a ete montre. Maintenant microsoft a 6 mois pour montrer sa veritable volonte d'avoir un format de fichier office reellement interoperable et perenne avec les autres acteurs du marche, donc wait and see.

            Pour en revenir au sujet du journal, de Icaza est soit un idiot (ce dont je doute malgre ses declarations a l'emporte piece sur les brevets) soit il prend ses interlocuteurs pour des cons lorsqu'il dit que le format est "superbe".

            Aller juste pour la route:

            Am (Miguel) personally proud that Jody and Michael made Microsoft add ~650 pages or so to the spec that documented the formulas

            Ce qui veut dire que Microsoft a presente a l'ECMA un document qui n'avait pas les formules documentes. Ca te rappelle rien ca? Pourquoi ne pas avoir pris la decision d'utiliser le standard qui etait en train de se mettre en place pour corriger exactement le meme manque dans ODF, je parle d'openformula?
            C'est rigolo comme on l'a entendu sur le sujet et se moquer de ODF alors que le probleme etait 1) connu 2) en train d'etre regler et qu'il n'a fait aucune publicite que au meme moment le draft de la norme microsoft openxml etait dans le meme cas.

            • [+] [^]Re: Mon avis ca fait longtemps

              Posté par TImaniac (page perso, ) le 12/09/2007 à 10:09. (lien). Évalué à -1.

              Donc toutes tes critiques sur ODF sont nulles et non avenus.
              Mais c'est quoi cette conclusion de merde ? Je suis pas représentant MS que je sache ! Je donne mon avis.

              Microsoft ne l'a pas fait tout simplement parceque bien sur qu'il y a des manques, des erreurs et des trucs qui ne devraient pas etre dans ODF 1.0 mais ce format est totalement implementable dans n'importe quel suite office.
              J'ai montré par A + B qu'il n'était pas implémentable entièrement dans la vraie vie. La vraie vie me donne raison, puisque personne n'a encore réussi et ca maintenant un petit moment que le standard existe.
              MS a voté Oui par pragmatisme : ce format n'est pas 100% interopérable, c'est un saint graal de toute façon inaccessible, proposons un autre format qui n'atteindra pas non plus l'objectif mais qui répondra à un autre : la compatibilité avec des millions de documents existants.

              Pourquoi avoir voulu absolument repeter les erreurs de ODF et du format binaire?
              Parcqu'il y a des contraintes techniques ? Les objets OLE, c'est du bon gros blob binaire, mais des gens s'en serve, et il faut que ces gens puissent sauvegarder leurs documents quand même dans un format moderne : tant pis si certains bouts seront potentiellement illisible plus tard. C'est pour ca que ODF et OOXML supporte OLE.

              . Maintenant microsoft a 6 mois pour montrer sa veritable volonte d'avoir un format de fichier office reellement interoperable et perenne avec les autres acteurs du marche, donc wait and see.
              ODF est pourtant passé depuis en 1.1 à l'ISO (l'année dernière, donc relativement recemment), et pourtant il n'a pas beaucoup été amélioré niveau interopérabilité : impossible d'être 100% compatible avec 90% des suites déployés sur le marché, balo pour un format d'interopérabilité non ? Sauf si on est pragmatique, et qu'on accepte ces entorses pour avoir quand mêmes des formats normalisés, et on accepte l'OOXML comme on accepte l'ODF.
              Un peu de cohérence bon sang, les 2 ou aucun.

              Ca te rappelle rien ca? Pourquoi ne pas avoir pris la decision d'utiliser le standard qui etait en train de se mettre en place pour corriger exactement le meme manque dans ODF, je parle d'openformula?
              Pourquoi prendre OpenFormula, un truc neuf, pas encore normalisé à l'époque, et qui est rien d'autre qu'une copie à peine modifiée du format d'OOo ? MS a son propre format, déjà éprouvé. Pourquoi prendre le truc concurrent qui n'a pas plus de légitimité ?

              Enfin je vois que t'as pas répondu sur la moitié de mes exemples.

              • [^]Re: Mon avis ca fait longtemps

                Posté par Bozo le Clown () le 12/09/2007 à 11:51. (lien). Évalué à 4.


                J'ai montré par A + B qu'il n'était pas implémentable entièrement dans la vraie vie.


                Ou ça ?

                Jusqu'ici tu as juste démontré que OOXML souffrait des mêmes lacunes qu'ODF vis à vis de l'interopérabilité pas qu'obtenir un format véritablement opérable était irréalisable.

                Peu m'importe que MS fasse un format de stockage OOXMLBis non normalisé qui inclut des images en RAW ou que sais-je du moment qu'il fournit un export vers un standard qui attend du PNG.
                Et si le besoin d'extension pour du OLE est nécessaire qu'ils prevoient un autre format d'echange qui ne prétende pas devenir une norme.

                • [^]Re: Mon avis ca fait longtemps

                  Posté par TImaniac (page perso, ) le 12/09/2007 à 12:32. (lien). Évalué à 0.

                  Ou ça ?
                  Ben y'a pas de liste exhanstive des formats d'image à supporter : comment veux tu implémenter ce format sans savoir quoi supporter comme codec d'image ?
                  Y'a pas de liste exhaustive des langages de scripts possible, et encore moins de référence à une quelconque norme/version : que dois-je implémenter pour avoir un document qui exécute correctement les scripts ?
                  Pareil pour les applets Java : on sait pas quelle version de Java est référencée, laquelle implémenter, avec quelles libs (on suppose que JDBC en fait parti, sans savoir quelle version).

                  Peu m'importe que MS fasse un format de stockage OOXMLBis non normalisé qui inclut des images en RAW
                  Justement, selon la norme actuelle, tu peux très bien mettre une image RAW, la norme ODF est parfaitement respectée. Mais tu peux pas relire ton document si OOo (ou autre) ne supporte pas ce format d'image. C'est couillon non ?

                  Ca te suffit pas à prouver qu'il est impossible d'implémenter ODF correctement ?

                  C'est pas pour ca qu'il faut jeter ODF, juste qu'il faut accepter qu'une norme est pas parfaite, et chercher à l'améliorer. mais faut pas la rejeter, rien n'est parfait.

              • [^]Re: Mon avis ca fait longtemps

                Posté par Albert () le 12/09/2007 à 15:55. (lien). Évalué à 2.

                J'ai montré par A + B qu'il n'était pas implémentable entièrement dans la vraie vie.

                Comme dit par Bozo. Tu as montre ca ou? Tu as pointe des points de la norme que tu consideres problematique (peut etre a raison la question n'est pa la) mais tu n'as absolument pas montre que la norme ne pouvait pas etre implemante.

                MS a voté Oui par pragmatisme

                Non ils ont vote Oui parceque ils auraient ete les seuls a ne pas voter pour et donc 1) cela aurait bien montre l'ouverture de Microsoft pour l'interoperabilite 2) ils attendaient un renvoie d'ascenseur et que personnes ne fasse une seul remarque technique sur le format qu'il etait en train de preparer a faire passer de force en fast-track. Je tiens a rappeler que ODF malgre tout ses defauts n'est pas passe en fast-track.

                la compatibilité avec des millions de documents existants

                Encore une fois comme cela a ete demontre pas de nombreuses personnes ici et de bien plus competente que moi (ce n'est pas difficile) c'est faux et archi faux. La seul veritable compatibilite avec les anciens documents ne peut venir que de la documentation du format de ces documents sans points obscure connu d'un seul editeur. De plus cette pseudo compatibilite n'a pas lieu d'etre, les anciens documents devront etre ouvert par un filtre et sauvegarder par un autre. La compatibilite doit donc se trouver dans les filtres et pas ailleurs. Il ne faut pas rever Microsoft Office 97 ne saura jamais ouvrir un document docx de facon native.

                impossible d'être 100% compatible avec 90% des suites déployés sur le marché

                Tu parles pbt de Microsoft office? Parceque microsoft openxml est lui interoperable avec d'autre suites office? Non meme pas il est tellement simple a implemente que Microsoft n'a pas reussi a le faire pour la version Mac de sa suite office 2007 et que cela sera peut etre pour la version 2008 mais probablement sous la forme d'un plugin. Donc niveau interoperabilite, microsoft openxml il est interoperable avec une version (la version 12) d'une suite office (microsoft office) sur une plateforme (Windows). Ca c'est de l'interoperabilte. En face tu as ODF implemente dans un certains nombre de suite office: Openoffice.org, Lotus Notes, Google office et et sur la grande majorite des OS. Niveau interoperabilite c'est "legerement" mieux tu ne trouves pas?

                A moins que tu trouves que la definition d'interoperabilite d'un format c'est le fait que le logiciel sur lequel il a ete cree doit etre capable de le relire correctement? C'est rigolo ca me rappelle un vieux truc sous MS office 97, windows 98 et deux pc different ou le rendu du document doc etait pas le meme...

                MS a son propre format, déjà éprouvé.

                Non documente a l'epoque de la creation de openformula et de la soumission a l'ECMA, avec des erreurs dans les formules (toujours presente) et j'en passe.

                Enfin je vois que t'as pas répondu sur la moitié de mes exemples.

                Parceque je n'ai aucun avis sur ces points particulier, je ne sais pas si c'est vraiment genant (au passage VBA c'est normalise et documente? Parceque bon microsoft openxml a lui aussi exactement le meme probleme) et que je n'ai jamais dit que ODF etait parfait. Jamais! J'ai toujours dit que microsoft openxml fait totalement doublon comme standard et n'a pas lieu d'etre. Que les soupcons sur l fait qu'il etait non completement decrit etaient fondes, que le passage en fast-track pour un truc pareil est une aberration de premiere ordre et une facon de "forcer" la normalisation ISO, etc.

            • [^]Re: Mon avis ca fait longtemps

              Posté par Bozo le Clown () le 12/09/2007 à 11:43. (lien). Évalué à 2.

              Encore une fois parce que le processus de normalisation est arbitraire et tu te réfugies derrière le fait que ODF que MS profite de la même faille. Il aurait tort de s'en priver puisque ses concurrents l'on fait. Et si on n'y change rien peut-être que d'autres le feront à sa place.

              Ceci te dispense de répondre à chacun des arguments qui sont d'ailleurs moinssés comme à l'habitude lorsque la passion l'emporte sur la pertinence.
              Toutes ses réponses sont fondées mais tu esquives .

    • [^]Re: Mon avis ca fait longtemps

      Posté par Bozo le Clown () le 12/09/2007 à 11:30. (lien). Évalué à 3.

      Qui a entrepris une croisade sur DLFP pour descendre OOXML coûte que coûte ?
      Qui a placé un espoir démesuré dans cette croisade en pensant mettre à terre le monstre alors qu'il ne s'agit peut-être que d'un leurre (un moulin ?)

      On est tous le Don Quichotte de quelqu'un d'autre, Hein !

      Ce qui est sûr c'est que Timaniac argumente, que je n'ai jamais pris position pour OOXML (d'autant que j'utilise OO), que tu ne te contentes que de vulgaires attaques ad hominem, amalgames et autres métaphores foireuses lorsque tu es à court d'argument.

      Que ODF et OOXML soient sur le même pied d'égalité, car ils acceptent tous 2 des extensions qui peuvent être non standards, non documentées voire fermées est indéniable.

      La question est donc de savoir si c'est une faille dans le processus de normalisation ISO ou si c'est une vision pragmatique (mais criticable):
      Ne pas obliger les vieux logiciels à être patché pour supporter des extensions standards, tout en ne fermant pas la porte a ceux qui visent l'interopérabilité complète.
      Dans ce cas on n'oblige pas une société à faire la mise de son parc d'install d'Office 97 pour exporter avec du PNG au lieu d'un fomat d'image proprio pour que ses doc en Office 97 puissent être lu par la dernière version d'Office qui supporte déjà le format d'image proprio.
      En même temps, ca empêche des suite concurrentes d'être pleinement compatibles avec ces docs et ca fausse la concurrence.

      Pragmatisme aussi parce que comme essaye de te l'expliquer Timaniac l'interopérabilité totale s'avère être une utopie (ce avec quoi je suis en désaccord)

      Pour moi c'est l'ISO qui détient la clé et qui doit clarifier ses positions vis à vis de ces critères. Ainsi on évite de se retrouver dans l'arbitraire :
      Pour être standard peux t'on ou non accepter qu'une extension au moins ne soit pas standardisée.
      Dans la négative selon ce critère ODF ne devrait pas plus être un standard que OOXML

      Il y a peut être d'autres raisons qui font que OOXML n'est pas acceptable mais celle-ci n'en est pas une si l'on se réfère à ODF.


      Plutôt que de te remettre en question en acceptant que cet argument est caduque et en trouver d'autres, tu prefères te réfugier dans le fait que "MS c'est pas pareil c'est des maichants" ou que nous sommes tous des suppôts de Satan ou que sais-je encore.

  • [^]Re: Mon avis ca fait longtemps

    Posté par Axone () le 12/09/2007 à 06:54. (lien). Évalué à 3.

    OOXML n'a pas le même but qu'ODF

    Ah bon ? Quelle est la différence de but ? Il me semblait justement que MS mettait la pression sur les administrations pour qu'elles ne passent pas au standard ODF car le format MS allait être normalisé.

    un format prétendu "universelle et interopérable" comme l'ODF a été normalisé alors qu'il n'était pertinemment pas implémentable dans la principale suite Office du marché.

    Pourquoi pas implémentable ? Surtout que maintenant MS office sait produire du xml, y'a déjà une partie du boulot qui est fait. J'ai pas l'impression d'une quelconque difficulté technique.

    • [+] [^]Re: Mon avis ca fait longtemps

      Posté par TImaniac (page perso, ) le 12/09/2007 à 07:31. (lien). Évalué à -2.

      Quelle est la différence de but ?
      Y'a des buts communs :
      - proposer le logo commercial "ISO"
      - proposer un format avec une certaine pérénité dans le temps (suppose des choix techniques type XML et une documentation relativement complète).
      Des buts différents :
      - ODF veut proposer un standard qui repose sur OOo. En cela historiquement le format proposé est plus "clean" et s'affranchi plus du passé.
      - OOXML veut proposer un standard qui repose sur MS Office. Moins clean, il offre cependant l'avantage d'être compatible avec l'énorme historique de documents existant.

      Bref OOXML est un bon format de transition pour une administration qui vient du monde MS Office.

      ODF est un bon format pour qui veut passer à autre chose.

      Pourquoi pas implémentable ? Surtout que maintenant MS office sait produire du xml, y'a déjà une partie du boulot qui est fait. J'ai pas l'impression d'une quelconque difficulté technique.
      Lis mes différents exemples sur les grosses lacunes de la norme ODF et les liaisons (trop) fortes avec les technos de Sun.
      Lis également les difficultés rencontrées par ceux qui tentent d'implémenter ODF (KOffice, Gnome Office). C'est parfois surmontable, mais au prix d'hypothèse techniques qui consiste à "singer" OOo pour être compatible. Je vois mal MS "singer" OOo juste pour être compatible avec lui.

mouais

Posté par Éric (Jabber id, page perso, ) le 11/09/2007 à 15:28. (lien). Évalué à 3.

Enfin en disant cela il admet bien que C# est blinde de brevet et que mono en violent pas mal de facon connu.


Sa réponse ne correspond pas à l'éventuelle question sur les brevets, il a une vision très partielle et on ne peut certes pas se contenter de savoir que la version Novell est couverte ..... mais *NON*, il n'admet rien (et d'ailleurs ce n'est pas à lui de le faire, il n'est pas plus légiste ou responsable MS que toi ou moi).

Moi je vois tout au plus sa réponse comme un "c'est possible mais ceux qui veulent être couverts dans l'utilisation de cette techno le peuvent via notre distribution". En gros un "après moi le déluge". Par contre en rien il ne confirme ni n'infirme le potentiel déluge. Je vois mal au nom de quoi il pourrait le faire d'ailleurs.

  • [^]Re: mouais

    Posté par Colin Leroy (page perso, ) le 11/09/2007 à 17:09. (lien). Évalué à 5.

    il n'est pas plus légiste ou responsable MS que toi ou moi

    Juriste ;-)

    --
    Claws Mail - it bites!
    • [^]Re: mouais

      Posté par Bozo le Clown () le 11/09/2007 à 19:48. (lien). Évalué à 3.

      Ca dépend! Si son désir secret est d'enterrer ODF, il se chargera peut être d'autopsier le défunt

Bah ...

Posté par sebastienb () le 11/09/2007 à 16:40. (lien). Évalué à 1.

Ici on est un peu TOUS d'accord, ooxml c'est nul, en même temps, c'est pas pour ça que tous ceux qui pensent que c'est bien sont nuls, il a ses arguments (faibles, ok), et lui n'a pas de réels avantages à dire que c'est bien (enfin pas comme les gars de chez microsoft qui en profiteront)...

C'est en étant pas tous du même avis qu'on évolue, je pense ... (bien qu'il soit connu pour être un trolleur)

  • [^]Re: Bah ...

    Posté par freeze () le 11/09/2007 à 17:40. (lien). Évalué à 7.

    euh ... t'es sûr que lui n'a aucun intérêt (même non financier) ?

    Il bosse pour novell, et dit "si vous avez peur de MS, achetez Novell, et MS fait du super boulot"

    ...

    Moi je ne trouve pas sa position particulièrement neutre.

Les brevets logiciels valable en UE ?

Posté par benoar (Jabber id, ) le 12/09/2007 à 01:39. (lien). Évalué à 5.

Dans une des réponses de Miguel (il cite Martin Schlander) :

> 2) You're saying other distributors can't ship Moonlight legally (in
> the US) because of patent issues. Making Moonlight effectively non-
> free (as in freedom).

Am not sure where you get the idea that the "US" is the only place where software patents exist. Free software people are under the mistaken impression that software patents are only a US thing, while many of the stake holders are European companies. The only difference is that in Europe your "software patent" is written to describe a machine. Law firms will offer you a set of checkboxes to "port" your patent from the US-wording to any other nation wording. And the patents are enforceable in most countries in the EU. Not surprising, as the EU owns many of patents on the media space.


En gros, pour lui, les brevets logiciels sont tout à fait valables en Europe : d'un côté, il n'a pas tord, car ils sont actuellement acceptés par l'EOB, même s'ils ne sont pas applicables. Et c'est là qu'il m'étonne : il dit qu'ils le seraient tout à fait.

Je n'ai encore jamais vu une poursuite judiciaire en Europe qui concerne un brevet logiciel, mais je serais surpris si cela était arrivé. Il a l'air de considérer ça "normal" d'avoir des brevets partout dans le monde (voir la suite de ses mails) même s'il se dit "contre" les brevets logiciels (voir aussi ses autres réponses).

Mais en tous cas, dans ses réponses, il est toujours très vague quant à ces questions de brevets ("pas de problème pour utiliser nos logiciels, tant que vous les téléchargez depuis Novell, qui a la protection" -> qu'est-ce que ça veut dire "télécharger" depuis Novell ?! et pourquoi avoir besoin d'une protection si ce n'est "certainement" pas couvert par des brevets ? Et aucune réponse claire si c'est vraiment "free as in freedom"), ce qui me fait dire que ce mec n'est pas très net avec toutes ces histoires et son affiliation à Microsoft. Bref, il FUD bien.

Sinon, je trouve qu'il a en général un ton très hautain dans ses mails; je ne sais pas si c'est très agréable d'avoir une discussion argumentée avec lui...

  • [^]Re: Les brevets logiciels valable en UE ?

    Posté par Éric (Jabber id, page perso, ) le 12/09/2007 à 06:24. (lien). Évalué à 2.

    > Et c'est là qu'il m'étonne : il dit qu'ils le seraient tout à fait.

    Il dit ce qui est répété et rerépété mais qu'on ne veut pas entendre ici. Rien n'interdit qu'un brevet fasse intervenir du logiciel. Rien n'interdit même qu'un brevet ne puisse (actuellement) être couvert que par du logiciel.
    Ce qui est interdit c'est faire breveter du logiciel "en lui même", que ce soit en tant que logiciel qu'on le fasse breveter.
    On brevette une procédure pour un effet technique innovant. C'est la procédure qui est brevetable, qu'elle fasse intervenir du logiciel importe peu.

    Sa vision du "pour un brevet logiciel en Europe il suffit de reformuler" peut certainement être juste pour certains trucs, ou en tout cas certainement être effectivement ce que font certaines boites.

    • [^]Re: Les brevets logiciels valable en UE ?

      Posté par briaeros007 () le 12/09/2007 à 07:08. (lien). Évalué à 2.

      Rien n'interdit même qu'un brevet ne puisse (actuellement) être couvert que par du logiciel.
      Ça veut dire quoi 'être couvert' ?
      Parce qu'actuellement le brevet pour un logiciel, pour qu'il soit accepté, il doit faire partie d'un appareillage plus complexe (donc pas que logiciel) agissant sur 'les forces de la nature'.
      Bref pas qu'un logiciel tout court.

      Donc sortir que mono est bel et bien breveter en europe (parce que c'était ça le sujet) mais qu'on ne veut pas l'entendre me semble légèrement déformer la réalité.

      --
      Subete ga wakatta toki…watashi ga anta wo korosu.
      • [^]Re: Les brevets logiciels valable en UE ?

        Posté par Éric (Jabber id, page perso, ) le 12/09/2007 à 07:36. (lien). Évalué à 2.

        > il doit faire partie d'un appareillage plus complexe (donc pas que
        > logiciel) agissant sur 'les forces de la nature'.

        Je peux me tromper mais l'histoire des forces de la nature c'était une proposition quand le sujet était passé à l'assemblée, ce n'est pas dans les règles actuelles.

        > Donc sortir que mono est bel et bien breveter en europe

        Ce n'est pas ce que j'ai dit (ni ce qu'il a dit). Je ne suis même pas convaincu d'avoir lu quelque part des faits montrant qu'il est même breveté aux US.

        • [^]Re: Les brevets logiciels valable en UE ?

          Posté par briaeros007 () le 12/09/2007 à 07:48. (lien). Évalué à 2.

          Ce n'est pas ce que j'ai dit (ni ce qu'il a dit). Je ne suis même pas convaincu d'avoir lu quelque part des faits montrant qu'il est même breveté aux US.
          Au temps pour moi alors, c'est ce que j'avais compris.

          pour le cas des 'forces de la nature' :
          en ce qui concerne les brevets voila ce que wikipedia dis :


          Art. 52 : (1) Les brevets européens sont délivrés pour les inventions nouvelles impliquant une activité inventive et susceptibles d'application industrielle. (2) Ne sont pas considérés comme des inventions au sens de lart. 52 notamment : a) les découvertes ainsi que les théories scientifiques et les méthodes mathématiques ; $b) les créations esthétiques ; c) les plans, principes et méthodes dans l'exercice d'activités intellectuelles, en matière de jeu ou dans le domaine des activités économiques, ainsi que les programmes d'ordinateurs ; d) les présentations d'informations. (3) Les dispositions 52 (2) n'excluent la brevetabilité des éléments énumérés auxdites dispositions que dans la mesure où la demande de brevet européen ou le brevet européen ne concerne que l'un de ces éléments, considéré en tant que tel.

          Donc effectivement il n'indique pas les forces de la nature, toutefois il interdit explicitement le cas du programme d'ordinateur, ainsi que les principes et méthodes générales, et les théorie mathématique.
          (par contre le (3) j'avoue ne pas vraiment bien le saisir).

          --
          Subete ga wakatta toki…watashi ga anta wo korosu.
          • [^]Re: Les brevets logiciels valable en UE ?

            Posté par Éric (Jabber id, page perso, ) le 12/09/2007 à 11:23. (lien). Évalué à 3.

            C'est justement le (3) qui est important.

            Ce veut dire que ton brevet peut tout à fait avoir des théories mathématiques et des logiciels mais qu'on ne peut pas breveté le logiciel en lui même ne fait pas un sujet de brevet (son effet ou son utilisation peut lui faire un sujet de brevet).

            Il y avait un très bon article sur la question dans un vieux linuxmag : http://jjdj.free.fr/article/

            J'en conseille la lecture, et en particulier la section "Des autres critères de validité, et des logiciels" qui parle de cette question.

    • [^]Re: Les brevets logiciels valable en UE ?

      Posté par benoar (Jabber id, ) le 12/09/2007 à 14:21. (lien). Évalué à 2.

      OK, merci pour les précisions sur la brevetabilité logicielle.

      Mais ce que je me demande, c'est pourquoi pour l'instant aucune poursuite n'a été intentée en Europe : toutes les grandes actions médiatisées l'ont été aux US, et en plus j'ai rarement vu une entreprise européenne impliquée dedans (alors que MDI dit que ce sont elles qui détiennent une grande par des brevets)(ha si, je viens de penser à Thomson et les brevets sur le mp3).

      Et tout le combat contre la création d'un "brevet logiciel européen" qui s'est joué il y a quelques années (déjà !), pour éviter de se retrouver comme aux US : cela est quand même un signe que la brevetabilité logicielle en Europe n'est pas si certaine que ça...

      Franchement, j'aimerais bien savoir si en Europe, on peut poursuivre quelqu'un pour une violation de brevet logiciel .... ? Et si "oui", pourquoi on ne voit pas de procès autour de ces problèmes ?

Mon cher Albert,

Posté par Jb Evain (page perso, ) le 12/09/2007 à 09:20. (lien). Évalué à 6.

Je lis de temps en temps linuxfr, et je dois t'avouer que je t'avais repéré. En effet, un grand nombre de tes commentaires sur ce site me font sourire. Sourire par tant de préjugés, et surtout, un manque certain de connaissances. Mais c'est bien connu, c'est ceux qui en parle le plus, ...

Tout d'abord mettons les choses dans leur contexte. Je suis ingénieur dans l'équipe de Mono, et participe à ce titre au développement de Moonlight. Ce qui fait, que, si j'avoue ne pas pouvoir être impartial, j'ai au moins une vision de la technologie que tu te plais à critiquer ouvertement, que toi, tu n'as de toute évidence pas.

Je vais passer directement l'attaque sur Miguel (mon responsable direct), que tu connais bien évidemment bien plus que moi, ce qui te permet de dire le fond de sa pensée, et encore mieux, ses passions et ses lubies. Tu es quelqu'un de formidable mon cher Albert.

Parlons un peu d'OpenOffice. OpenOffice permet de lire et même écrire des fichiers qui sont crées ou lisibles par Microsoft Office dans des versions antérieures à leur version OpenXML. Quoi qu'il arrive, pour rester compétitif, OpenOffice va DEVOIR être capable de lire et écrire l'OpenXML. C'est dans ce sens qu'OpenXML est quand même appréciable, parce que les développeurs d'OpenOffice, ou de l'extension d'OpenOffice vont pourvoir utiliser au moins une spécification, qui par ses 6000 pages à l'avantage d'être complète. Spécification qui même si elle présente des failles, sera de toute façon plus facile à implémenter que si il fallait re faire du reverse engineering sur les fichiers, pour savoir à quoi correspond quoi.

D'autant plus qu'OpenXML est un standard ECMA, et donc protégé des brevets par une clause RAND. Ce qui fait qu'OpenOffice serait plus protégé en regard de l'implémentation d'OpenXML que de l'implémentation de l'ancien format binaire.

Incroyable non.

Continuons avec tes idioties, le coeur de Mono et le language C# sont aussi protégés des brevets par la clause RAND des standards ECMA 334 et 335. La seule surface d'attaque, est celle de l'implémentation des libraires non standardisées, et qui sont téléchargeables séparément. Si les packagers de ta distribution favorite le veulent, ils peuvent tout à faire la séparation. D'autant que je ne vois pas des masses d'applications purement Mono qui utilisent ces couches sous Linux. Donc tu peux très bien ne pas les télécharger, et hop, tu ne crains rien.

Incroyable non.

Maintenant, parlons d'un projet qui bien qu'hébergé sur sourceforge et accessible sous forme de packet, est téléchargé spécifiquement à l'installation. Je parle de http://corefonts.sourceforge.net/ . Et bien ici ça va être exactement le même fonctionnement, et tous les système de packages que je connais sont capable de faire ça. Encore une fois, si les packageurs font bien leur boulot, tu devrais pouvoir télécharger Moonlight comme n'importe quel packet, mais celui si sera téléchargé pour de vrai sur le site de Novell, et te voilà directement couvert.

Et tu sais que tu es couvert, alors que si tu utilises une version OpenSource de flash, rien ne te dit que tu ne crains rien.

Bref, à part monter des films, fuder, attaquer Miguel, et raconter des anneries, tu ne sers pas à grand chose.

Pour informations, Mono n'est pas le seul projet à être inquiété par le système idiots des brevets. Prenons en trois autres qui sont potentiellement beaucoup plus inquiétés: Le noyau Linux lui même, Samba, les drivers ntfs. Et soyons réaliste rajoutons OpenOffice. Si Microsoft devait attaquer, ce n'est sûrement pas à Mono qu'ils s'en prendraient directement en premier. Bref, moi je retourne bosser, toi, tu peux rester à soulever ton indignation et ton ignorance.

Bisous

  • [^]Re: Mon cher Albert,

    Posté par ndesmoul () le 12/09/2007 à 09:34. (lien). Évalué à 7.

    Juste une remarque en passant. Je n'ai rien contre OpenXML en tant que tel, à