J'ai mergé les changements apportés par Paul-Virak et converti les \'e
et compagnie en accents UTF-8. J'ai aussi relu ce qui a été changé et ça me semble mieux que le texte précédent. git-svn-id: file:///home/matteo/Downloads/gna/svn/gulum@57 e86ba84a-1b32-0410-87b2-c3a91cda2950
This commit is contained in:
parent
fd9eba604a
commit
e61f4a4969
|
@ -1,4 +1,4 @@
|
|||
%% $Id$
|
||||
hoix con%% $Id$
|
||||
|
||||
% bon, au lieu d'utiliser \og et \fg qui sont visiblement un peu
|
||||
% capricieux, j'ai utilisé « et » avec ~ pour faire des espaces
|
||||
|
@ -109,6 +109,7 @@ logicielle convient
|
|||
mieux à ses besoins devrait faire face à la crainte d'être incapable
|
||||
de lire tous les documents fournis par d'autres entreprises, voire ses
|
||||
propres documents archivés.
|
||||
On appelle cela \en{vendor lock-in} en Anglais.
|
||||
|
||||
D'un autre côté,
|
||||
si des formats ouverts sont utilisés,
|
||||
|
@ -147,10 +148,10 @@ formats secrets.
|
|||
\subsubsection{Indépendance et longévité}
|
||||
|
||||
Comme n'importe qui est en mesure de concevoir des logiciels conformes
|
||||
à un format ouvert, \textbf{l'utilisation de ce formats ouverts à des
|
||||
à un format ouvert, \textbf{l'utilisation de ces formats ouverts à des
|
||||
fins d'archivage est un choix judicieux.} Il est implicitement garanti
|
||||
qu'il y aura toujours des logiciels en mesure de le manipuler
|
||||
adéquatement, même si le format a été lancé par une compagnie défunte.
|
||||
adéquatement, même si le format a été lancé par une entreprise défunte.
|
||||
|
||||
% Ceci est valable est vrai à condition que le support sur lequel les
|
||||
% archives sont mises soit toujours lisible.
|
||||
|
@ -182,7 +183,8 @@ devraient être promus et utilisés par ces derniers, il y a:
|
|||
propriétaire, qui change régulièrement selon le bon vouloir
|
||||
de son créateur) ;
|
||||
|
||||
\item garantir également aux citoyens l'accès éternel à ces documents;
|
||||
\item garantir également aux citoyens l'accès éternel à ces
|
||||
documents ;
|
||||
|
||||
\item ne pas exercer de discrimination monétaire : par exemple,
|
||||
publier des documents dans le format d'une suite bureautique
|
||||
|
@ -202,12 +204,14 @@ devraient être promus et utilisés par ces derniers, il y a:
|
|||
Voici une liste non exhaustive de formats ouverts populaires.
|
||||
\begin{description}
|
||||
|
||||
% Format ISO
|
||||
\item \soft{OASIS OpenDocument}~\cite{SPEC_opendocument}
|
||||
(\fileext{.odt}, \fileext{.ods}, \fileext{.odp}, etc.) : formats
|
||||
de documents de bureautique permettant de représenter du texte, des
|
||||
tableaux de nombres, des diaporamas, des diagrammes, etc.
|
||||
Ces formats s'appuient sur plusieurs autres normes telles que XML, SVG,
|
||||
MathML, etc.
|
||||
MathML, etc., et forment un standard ratifié ISO (ISO/IEC
|
||||
26300\string:2006).
|
||||
Ils pourraient remplacer les formats fermés \fileext{.doc},
|
||||
\fileext{.xls}, \fileext{.ppt}, etc. Ces formats sont supportés par
|
||||
\soft{OpenOffice, Google Docs \& Spreadsheets, KWord, Abiword, Gnumeric,
|
||||
|
@ -262,8 +266,9 @@ Il est également possible d'associer un niveau d'opacité distinct à
|
|||
chaque point de l'image.
|
||||
%Supporte également les palettes de couleurs
|
||||
%fixes et la transparence avec canaux alphas.
|
||||
Contrairement à SVG, PNG,
|
||||
étant un format d'images matricielles, est à taille fixe et dépend de
|
||||
PNG étant un format d'images matricielles
|
||||
contrairement à SVG qui est vectoriel,
|
||||
chaque image est à taille fixe et dépend de
|
||||
la résolution d'écran ou d'impression.
|
||||
|
||||
\item \soft{Portable Document Format}~\cite{SPEC_pdf} (\fileext{.pdf})
|
||||
|
@ -304,70 +309,46 @@ Voir aussi : % Sous forme de références ? -- Pascal
|
|||
%On pourrait aussi parler de XPS (XML Paper Specification) qui est encore une autre copie corrompue par Microsoft du vénérable format PDF.
|
||||
%Sauf que j'ai l'impression que ça commencerait à être long. À voir. Dans ce cas faudrait renommer tout ça en "attention aux faux formats ouverts qui en sont pas vraiment, isatrap!" --Jeff
|
||||
|
||||
\subsection{Pourquoi pas «~XPS~» ou «~Office OpenXML~» de \mso{} 2007 ?}
|
||||
\subsection{Quelques contre-exemples}
|
||||
|
||||
Dans un contexte de formats ouverts, il faut toutefois se mettre en
|
||||
garde contre les \textbf{«~faux~» formats ouverts}. \soft{XPS (XML
|
||||
Paper Specification)} et \soft{Office OpenXML} sont des formats mis en
|
||||
avant par Microsoft dans le but de raffermir son emprise sur les
|
||||
formats que nous utilisons dans la vie courante.
|
||||
garde contre les \textbf{«~faux~» formats ouverts}. En effet, certains
|
||||
formats sont publicisés comme ouverts, mais n'offrent
|
||||
pas tous les avantages décrits ci-haut (voire même aucun de
|
||||
ceux-ci).
|
||||
|
||||
Les raisons de fuir le nouveau format \soft{OOXML} (\soft{Office Open XML}, à ne pas confondre avec \soft{OpenDocument} ou \soft{OpenOffice}) sont nombreuses, au point où elles pourraient faire l'objet d'un argumentaire entier. Pour des raisons de simplicité et de concision, nous ne mentionnerons que quelques points saillants sous forme simplifiée, et nous nous attarderons uniquement sur le format \soft{OOXML}.
|
||||
Le format «~Office OpenXML~» (\soft{OOXML}) utilisé par \mso{} 2007
|
||||
pour décrire les documents \soft{Word} est un bon exemple de ce
|
||||
problème. Bien que la description du format (spécification)
|
||||
soit publique, son extrême lourdeur (plusieurs milliers de pages) en
|
||||
rend la programmation par des tiers-partis une entreprise ardue. De
|
||||
plus, la spécification est, en quelques endroits, incomplète ; il
|
||||
faudrait alors copier le comportement de diverses versions de
|
||||
\mso{}. Cela rend la tâche encore plus difficile, puisque ces
|
||||
derniers ne sont décrits par aucun document public, difficulté qui
|
||||
ne sera qu'accrue dans le futur, quand ces versions de \mso{} ne
|
||||
seront plus disponibles. Il est donc peu plausible que ce format
|
||||
puisse jamais être bien supporté par autre chose que
|
||||
\mso{}. Ainsi, une migration à \soft{OOXML} n'apporterait ni
|
||||
protection contre le \en{vendor lock-in}, ni meilleure longévité
|
||||
pour des documents d'archives.
|
||||
|
||||
\subsubsection{\soft{OOXML} n'est pas réellement ouvert}
|
||||
Contrairement au format OpenDocument (qui a été ratifié comme le
|
||||
standard ISO/IEC 26300\string:2006), le format Office OpenXML semble
|
||||
n'être qu'une tactique publicitaire de \ms{} pour tenter de conserver
|
||||
ses contrats gouvernementaux en se proclamant «~ouvert~» tout en
|
||||
s'assurant d'être les seuls à être réellement en mesure d'utiliser
|
||||
le format à sa pleine capacité.
|
||||
Adobe, avec le format «~Shockwave Flash~» (\fileext{.swf}), fournit
|
||||
un autre exemple. Ce format est grandement utilisé,
|
||||
particulièrement sur le web, afin de distribuer des animations,
|
||||
vidéos, sons et même des applications interactives. Dans ce cas
|
||||
aussi, la description du format est publique. Cependant, il est
|
||||
interdit d'utiliser cette description pour de développer un
|
||||
lecteur. Un fichier au format \fileext{.swf} n'offre donc pas de
|
||||
protection contre l'obsolescence du lecteur offert par Adobe.
|
||||
|
||||
Notamment, de nombreuses «~fonctions~» ne sont que des références
|
||||
non documentées vers des produits \ms{} antérieurs. Dans le quatrième
|
||||
volume de la documentation d'OOXML~\cite{SPEC_ooxml}, on retrouve :
|
||||
|
||||
\begin{itemize}
|
||||
\item autoSpaceLikeWord95 (spécifier les espaces «~comme Word 95~», section 2.15.3.6) ;
|
||||
\item lineWrapLikeWord6 (retours à la ligne «~comme Word 6~», section 2.15.3.31) ;
|
||||
\item useWord2002TableStyleRules (tableaux «~comme Word 2002~», section 2.15.3.6) ;
|
||||
\item useWord97LineBreakRules («~retours à la ligne de Word 97~», section 2.15.3.6).
|
||||
\end{itemize}
|
||||
Ces fonctions ne font donc que dire au lecteur «~vous saurez ce que ça fait si vous détenez la clé du fonctionnement de \ms{} \soft{Word} 6/95/97/2002/etc.~». Évidemment, personne sauf \ms{} ne sait comment ça marche ! Ce genre de «~fausse documentation~» est un exemple flagrant du type d'«~ouverture~» dont \ms{} fait preuve.
|
||||
|
||||
Ainsi, certaines fonctionnalités, au lieu d'être expliquées comme les autres dans la documentation du format OOXML, ont une mention «~définie par l'application~», ce qui veut dire que leur fonctionnement est entièrement dépendant du logiciel qui lit le format. En d'autre mots, c'est comme dire à quelqu'un «~c'est très simple de fabriquer une station spatiale, regarde, tu prends une station, et de l'espace~»~!
|
||||
|
||||
%j'ai commenté le paragraphe ci-dessous, il est redondant et tout à fait incompréhensible pour les mortels.
|
||||
%Par exemple, la section 6.1.2.19 du quatrième volume de la spécification du format \soft{OOXML} définit le fonctionnement de l'attribut «~equationxml~» des éléments «~shape~» en tant que «~le format du contenu de cet attribut est en fait défini par l'application~» : «~\en{actual format of the contents of this attribute are application-defined}~». \cite{EOOXML_objections}%Si vous n'avez pas compris le paragraphe précédent, rassurez-vous : c'est écrit aussi clairement dans la documentation OOXML!
|
||||
|
||||
|
||||
\subsubsection{6039 pages}
|
||||
La «~spécification~» (description du fonctionnement du format) d'\soft{OOXML} est répartie sur plusieurs livres, totalisant plus de six mille pages, ce qui est inutilement complexe pour un simple format de documents de bureautique.
|
||||
|
||||
Pour comparer, la spécification entière du format OASIS OpenDocument
|
||||
(ISO/IEC 26300\string:2006) tient en 722 pages.
|
||||
|
||||
\begin{figure}
|
||||
\begin{center}
|
||||
\includegraphics[height=5cm]{images/word2007spec}
|
||||
\caption{Pour implanter correctement la spécification Office Open XML dans son logiciel, il faut passer au travers de 6039 pages de documentation.}
|
||||
\end{center}
|
||||
\end{figure}
|
||||
|
||||
%\subsubsection{\soft{OOXML} réinvente la roue au lieu d'utiliser des standards existants}
|
||||
|
||||
% Typiquement, cette partie me semble inutile pour des néophytes. -- Pascal
|
||||
\subsubsection{Autres critiques et références additionnelles}
|
||||
\begin{itemize}
|
||||
\item \soft{OOXML} a été conçu pour le passé, et non l'avenir~\cite{BRA07}
|
||||
\item Les 6039 pages de la spécification sont impossibles à évaluer dans un délai raisonnable~\cite{GOO07}
|
||||
\item Le format de dates décimal est utilisé et ignore le standard ISO~8601~\cite{SPO06}
|
||||
\item Omissions et contradictions dans la spécification \soft{OOXML}~\cite{EOOXML_objections}
|
||||
\item Format de numérotation ignorant les standards \soft{ISO 10646} et \soft{W3C XSLT}~\cite{EOOXML_objections}
|
||||
\item Microsoft réinvente la roue au lieu d'utiliser des standards existants (comme MathML, SVG, les formats de numérotation ISO 10646 et les dates ISO 8601 mentionnés ci-haut)
|
||||
\item Objections diverses au format \soft{OOXML}~\cite{EOOXML_objections}
|
||||
\item When is a standard not a standard?~\cite{MAC07}
|
||||
\item Critiques du format \soft{OOXML} sur Wikipédia~\cite{WIK_OOXMLcriticism}
|
||||
\end{itemize}
|
||||
Une spécification publique est un élément essentiel à un
|
||||
format ouvert, mais est cependant loin d'ètre suffisante. Il est
|
||||
essentiel, lors de l'évaluation d'un format de fichier, de garder
|
||||
l'\oe il ouvert quant à la faisabilité (ou même la légalité)
|
||||
de manipuler des fichiers de ce format dans des applications tierces,
|
||||
et ce particulièrement pour des documents axés vers la
|
||||
distribution au public ou l'archivage.
|
||||
|
||||
|
||||
|
||||
|
|
Binary file not shown.
Loading…
Reference in New Issue