Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Si vous vous posez une question, vous n'êtes peut-être pas le premier...Les traductions en français des bibles XML.Ces articles sont des références dans leur domaine.Tout ce qu'il faut savoir pour démarrer sur un sujet XML...


Les éditeurs XML dans le monde du document.

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.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org