Jean-Jacques Thomasson (Nagora Consultants) expose son point de vue sur le
rôle des éditeurs XML dans les chaînes de production de documents.
Eric van der Vlist,
Dyomedea (vdV@dyomedea.com).
lundi 19 mars 2001
 Jean-Jacques Thomasson, Directeur de l'Agence Intranet et
Documentaire de Nagora Consultants a plus de dix ans
d'expérience dans les applications de SGML et XML à la gestion des documents. Il est co-rédacteur
des traductions françaises des spécifications DOM,
XPath et XSLT.
Dans cette interview réalisée par Eric van der Vlist le 16 mars 2001, il dévoile un point de vue caustique et
original sur le rôle des éditeurs de documents XML
dans les chaînes de production et de gestion de documents.
vdV: L'un des objectifs clairement mentionnés dans le cahier
des charges de XML est d'être un méta langage
facilement lisible. N'est-il pas paradoxal que, trois ans après la publication
de XML 1.0, on entende si souvent dire que
l'éditeur XML idéal reste à inventer?
JJT: Il faut faire la part des choses et les situer dans
leur contexte. L'essentiel des efforts de simplification de XML a eu pour objectif de faciliter la lisibilité pour
les applications et notamment pour les éditeurs, et non par les utilisateurs! SGML est né en 1986, à une époque où l'on ne
connaissait pas les éditeurs WYSIWYG, où les documents, tapés par des pools de
secrétaires étaient facturés au nombre de signes et où la place disque coûtait
cher. Il était donc très important de minimiser le nombre de signes, d'où la
souplesse de SGML à définir des raccourcis, mais
cette souplesse serait impossible à gérer par des outils WYSIWYG. La lisibilité
d'un document XML pour un utilisateur humain est
d'ailleurs toute relative. Ce qui s'écrit en XML:
<auteurs>
<auteur>
<nom>Thomasson<prenom>Jean-Jacques</prenom>
<societe>Nagora</societe>
</auteur>
<auteur>
<nom>van der Vlist<prenom>Eric</prenom>
<societe>Dyomedea</societe>
</auteur>
</auteurs>
peut s'écrire en SGML:
<auteurs>
Thomasson, Jean-Jacques; Nagora
van der Vlist, Eric; Dyomedea
</auteurs>
Lequel est le plus lisible ?
vdV: Malgré cette simplification qui aurait donc du être une
raison supplémentaire de voir des éditeurs XML
investir rapidement le marché, il ne semble pas que ce soit le cas.
JJT: Il faut poser la question de la production de XML dans son ensemble. Les documents XML de type "données" sont produits et gérés
par des applications, ils n'ont donc pas besoin d'éditeurs XML. S'il s'agit de produire des documents de type
bureautique autonomes, un éditeur Word ou HTML est imbattable.
vdV: il reste donc les systèmes de gestion de documentation
papier ou web?
 JJT:
L'enjeu pour les grandes entreprises est la réutilisation du contenu et on fait
de plus en plus la distinction entre la saisie du contenu et son assemblage.
C'est sur cette capacité à réutiliser le contenu qui ne sera saisi qu'une seule
fois et utilisé par différentes applications pour être présentés sur différents
supports papier et Web que se réalisent les gains de productivité et de
compétitivité. On a donc affaire à deux populations d'utilisateurs très
différentiées et travaillant sur deux postes de travail différents. Les postes
de saisie de contenu dont la qualité principale est d'être simples et banalisés
et des postes d'assemblage aux fonctions se rapprochant de celles de la PAO.
vdV: Quel outil utiliser pour les postes de saisie de
contenu?
JJT: Le contenu n'a pas besoin d'être saisi sous forme très
structurée. En fait, une structuration trop rigide du contenu peut même être
pénalisante pour sa réutilisation. Une structuration de base, telle que celle
qui existe dans HTML est suffisante si l'on y
rajoute les quelques balises sémantiques indispensables pour la réutilisation
des fragments. Dans cette catégorie, les éditeurs de texte classiques, Word en tête, à la fois simples et banalisés, sont imbattables.
vdV: J'utilise effectivement Word
de cette manière pour produire les documents publiés sur XMLfr. Les balises sémantiques sont représentées par
des styles "caractères" et les balises de structuration par des
styles "paragraphe". Je sauvegarde les documents sous forme HTML et les transforme en XML
au moyen d'une transformations XSLT et d'un
parseur XML modifié, le HTML
utilisé par Word 2000 n'étant ni du HTML ni du XML
conformes. La principale limite que je rencontre est que l'on peut définir un style
caractère dans un style paragraphe et qu'on ne peut pas aller au-delà en terme
d'imbrication. Je ne peux donc pas imbriquer un style "person" dans
un style "quotation" puisque ce sont deux styles
"caractère".
JJT: C'est effectivement une des principales limitations et
cela tient au modèle interne de Word. Il faudra
que Microsoft change ce point d'architecture pour que
l'on puisse résoudre ce problème. En attendant, cela n'est pas très pénalisant
pour la saisie de contenus réutilisables puisque les besoins de structuration
sont limités et il y a moyen de trouver des contournements.
vdV: Pour XMLfr, j'ai pensé
introduire des balises utilisant d'autres caractères que les "<"
et ">" de XML…
JJT: C'est une possibilité et cela marche bien. Ce n'est pas
gênant d'introduire de telles balises puisque ces documents sont convertis
avant d'être échangés et ces balises peuvent être très mnémotechniques. On
pourra par exemple noter les références à un code produit de la manière
suivante: ->47000<-.
vdV: Il ne reste donc plus que les postes d'assemblage comme
marché potentiel pour les éditeurs XML?
JJT: Oui, et c'est bien là le problème. Il s'agit d'un
marché de taille limitée qui demande des investissements colossaux que les
éditeurs de logiciels n'ont pas encore pu ou souhaité réaliser.
vdV: Qu'utilisez-vous donc?
JJT: Dans le cadre des grands projets dont j'ai la charge,
nous utilisons à ce niveau des éditeurs SGML
avec des DTDs "XMLisées", c'est à dire
permettant un passage facile à XML le jour où
les outils seront disponibles.
vdV: Les éditeurs de logiciels avaient donc eu la capacité
de développer de tels outils pour SGML?
JJT: Oui, mais ils avaient derrière eux dix et parfois vingt
ans d'expérience et de développements et un marché différent avec des niveaux
de prix élevés.
vdV: Ne vont-ils pas "XMLiser" leurs
produits?
JJT: Espérons-le.
Ces produits ont atteint un niveau de sophistication et de complexité tel que
tout développement est extrêmement lourd et le marché tellement réduit qu'ils
ne semblent pas se précipiter sur cette voie.
vdV: Y a t'il des cas où vous
êtes tout de même amené à utiliser un éditeur XML?
JJT: Non, je n'en ai jamais le besoin.
Copyright 2001,
Eric van der Vlist.
|
