Articles : Et la guerre des formats bureautique continue
Posté par Brioche4012 (Jabber id, page perso, ). Modéré le 15 août 2007.
0
Suite à la normalisation d'OpenXML par l'ECMA, ce dernier avait recommandé une procédure "fast-track" à l'ISO par l'intermédiaire du JTC-1. Après avoir obtenu ce fast-track, Microsoft essuie un revers : le comité américain membre de l'ISO (INCITS) a en effet décidé de voter contre la normalisation du format OpenXML.
Les votes sont en effet de 8 contre 7 en faveur d'OpenXML, mais l'IEEE ayant décidé de s'abstenir, OpenXML devait alors rafler plus de deux tiers des votes et non la moité+1.
Nouveau revers donc pour Microsoft qui essuie cette fois-ci une défaite à domicile.
![[fr]](../images/fr.png)
L'article de Clubic (1037 hits)![[en]](../images/en.png)
Le processus de normalisation suivi par OpenXML (371 hits)-
Article wikipedia sur l'INCITS (295 hits)
-
Précédent article DLFP 1 (328 hits)
-
Précédent article DLFP 2 (310 hits)
> Lire la suite (277 commentaires, moyenne: 2,8). [dépêche : 1827 caractères]
Vous avez demandé le commentaire #859252.
Run by 
Cette page a été générée par Templeet en 0.0646s (dont 0.0065 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
ÉH! LES GENS !
Pourquoi existe-t-il postgresql et mysql ? Hein? Quoi?
C'est vrai quoi, si les devs avaient bossé de concert pour qu'on aie mypostql, hein, la vie serait pas mieux, non?
Ok un standard iso c'est bien, deux, ça commence déjà à foutre le merdier, j'espère que Jobs a pas envisagé sortir une suite bureautique avec un format de fichiers ouverts sinon, les logiciels libres, on peut faire une croix dessus, hein...
Blague à part, même Microsoft se met au libre, c'est pas de bon coeur, on sait très bien que c'est une machine à pognon, mais ça fait du bien quand même, voir des gens qui vous ignore, qui ensuite vous dénigre ... oO(me dit quelque chose ce début de phrase ... "First they ignore you ...").
Plutôt que de FUDer à tout va, il est urgent d'attendre la suite des évênements et voir comment la firme à la fenêtre s'en sortira...
[^]Re: ÉH! LES GENS !
Microsoft prétend plus ou moins faire de l'open source (pour se faire de la pub), mais du libre je ne sais pas où t'as vu ça.
[^]Re: ÉH! LES GENS !
M$ veut faire normaliser un format non implémenté (O12 laisse derrière lui un tas de trucs de l'ancien format, binaires, illisibles et tout en gros c'est super) .
Ce n'est pas acceptable, de plus qu'il y a déjà ISO 26300 .
[^]Re: ÉH! LES GENS !
postgresql et mysql sont des logiciels qui s'appuient sur une norme/un standard qui est SQL (avec plus ou moins de bonheur)
De la meme facon que OOo et Koffice s'appui sur ODF.
une norme != un logiciel
Il est souhaitable que plusieurs logiciels implémente une norme mais pas qu'il existe plusieurs norme faisant la même chose.
[^]Re: ÉH! LES GENS !
vala et je rajouterais que dans la norme SQL y'a pas de commande alakon du genre SELECT-LIKE-ORACLE-7.3 ou INSERT-LIKE-MSSQL-2K.
Certes les divers serveurs de bases de données n'implémentent pas 100% de la norme SQL et ajoutent parfois leurs petits bricolages perso pour "enrichir" le truc... mais la norme n'a pas été dégueulassée pour "être compatible" avec les bricolages historiques délirants des divers éditeurs de sgbd.
[^]Re: ÉH! LES GENS !
Dans la pratique un script réalisé pour MySQL par exemple tu as presque 100% de risques que ça ne fonctionne pas du premier coup sur du Oracle par exemple. Rien que des problèmes de types de données etc...
[^]Re: ÉH! LES GENS !
Rien que des problemes de logiciels qui n'implementent pas totalement et scrupuleusement les normes mais qui rajoutent leur sauce par dessus. MySQL et oracle suivraient parfaitement la norme SQL, un script ecrit pour l'un passerait parfaitement pour l'autre.
[^]Re: ÉH! LES GENS !
On frise le troll là :-P
Si vous aviez mis la phrase dans l'autre sens ( code sql "Oracle" à faire tourner sur MySQL ) ou si vous aviez précisé la version de mysql ça aurait pu passer... mais :
En l'occurence les vieilles versions de MySQL n'ont qu'un nombre limité d'entorses connues (mais autorisées) à la norme SQL-3... j'ai relevé :
* le type INT auquel devrait être préféré le type INTEGER de la norme SQL-3,
* le type DEC auquel devrait être préféré le type DECIMAL,
* le type NUMERIC auquel devrait être préféré le type DECIMAL.
Et ces "entorses" étant comprises par Oracle (qui fait la même chose depuis plus longtemps) le code tournera sur Oracle sans modification.
Les versions récentes de MySQL convertissant à la volée INT en INTEGER et NUMERIC en DECIMAL à la création des champs (DEC n'étant même plus proposé), ce demi-problème n'est d'ailleurs plus d'actualité.
Dans l'autre sens en revanche Oracle "offre" un jeu d'entorses à la norme SQL-3 un peu plus grand (ce qui peut se comprendre : plus grosse bestiole et ausi nécessité de gérer la compatibilité ascendante)... et MySQL ne suit pas... ce qui n'est pas un mal.
Liste non exhaustive parce que je ne vais pas me peler la comparaison complète de la ref Oracle et de SQL-3 :
* BFILE qui corresponds à BLOB,
* INT auquel devrait être préféré le type INTEGER,
* DATE qui corresponds à DATETIME,
* LONG qui corresponds à BIGINT,
* LONG RAW qui corresponds à BIGINT,
* NCHAR qui corresponds à CHAR,
* NCLOB qui corresponds à TEXT,
* NUMBER qui corresponds à DECIMAL,
* NUMERIC auquel devrait être préféré le type DECIMAL,
* DEC auquel devrait être préféré le type DECIMAL,
* NVARCHAR2 qui corresponds à VARCHAR,
* RAW qui corresponds à BLOB,
* VARCHAR2 qui corresponds à VARCHAR.
Il y a aussi des types "Maison" qui n'ont pas d'équivalent dans la norme SQL-3 : NATURAL, POSITIVE, PLS_INTEGER, BINARY_INTEGER, SIMPLE_INTEGER, SIGNTYPE...
Sans compter quelques trucs plus tordus comme LOGGING, NOCACHE, NOPARALLEL, BYTE ... qui n'ont pas d'équivalent à ma connaissance dans la norme SQL-3. Ainsi que quelques détails sur CHAR et sur les implémentation des TRIGGERS (mais bon les TRIGGERS sur les vieilles versions de MySQL y'en a pas et sur les versions récentes c'est bien conforme à la norme SQL-3 si je ne m'abuse)
Bref... en réalité du code SQL qui passe pour MySQL a presque 100% de chances de tourner sur Oracle (la reciproque n'est pas "tout à fait vraie" encore huhuhu mais le SQL Oracle récent utilise assez peu ces types exotiques... sauf VARCHAR2 qu'on retrouve à toutes les sauces).