From: Pierre Attar (patt@tireme.fr)
Date: 05/09/2001 - 08:09
>Bonjour,
Si vous cherchez vraiment des concurrents de xml, il faut parcourir
l'histoire, avec une norme qui se nommait ODA (ISO 8613) et d'autre,
toujours existantes dans le domaine documentaire. Cela n'a qu'un intérêt
historique mais vous permettra mieux de comprendre la transversalité de XML.
Je m'explique. Beaucoup d'efforts de normalisation du document viennent du
monde documentaire, avec :
- SGML a été inventé pour permettre aux maisons d'édition de ne plus être
liés à leurs photocomposeurs et imprimeurs. L'idée était de pouvoir mettre
des documents en production chez un imprimeur, pluis de récupérer les
"sources" pour faire une seconde édition ou une mise à jour chez un autre
imprimeur. Pour un livre de par exemple 1000 pages, c'était important de
pouvoir faire cela. Ce n'était pas possible avant sgml car chaque système
avait son propre jeu de codes et ses propres méthodes de définition de la
typographie. Donc SGML est au départ orienté document de photocomposition
et il va, par la suite dans la documentation toujours, de l'industrie.
- ODA (ISO 8613) lui fait le pari qu'il est nécéssaire d'avoir un standard
riche d'échange de documents bureautiques en "format révisable". Ils
avaient raison : aujourd'hui, sur le Web, j'ai dés documents pdf, non
modifiables ; et des documents word de Microsoft (voir des documents rtf,
de chez microsoft aussi).
Du coup, ils inventent un format absolument épatant qui permet de coder
dans un même document deux vues : sa structure logique, par essemce
révisable mais aussi sa structure de présentation permettant de générer une
forme papier à l'image des intentions de l'auteur. L'originalité ? Les
structures logiques et de présentation partagent les mêmes fragments de
contenus textuels, graphiques, ou que sais-je encore.
Cette norme existe toujours ! Pourquoi n'a-t-elle pas été implémentée ?
Deux raisons à mon avis. D'une part car les éditeurs de logiciel
(microsoft, Worperfect, etc. ) se sont battus contre ! Il était possible de
construire des docxuments révisables indépendant de leur logiciel : quelle
horreur !
D'autre part car sa conception était novatrice et que à l'époque on avait
peu d'informaticiens capable de comprendre de réelles architectures
logicielles et surtout de les utiliser, voir de les implémenter. Vous
regardez les débats sur la présupposée complexité de DOM et vous
comprendrez que même aujourd'hui, on se pose encore la question de
l'intéret de réelles architectures fonctionnelles par rapport à des
ensembles de bidouilles informatiques.
- SPDL (ISO 10180) enfin, une normalisation de PDF qui à la différence de
ce dernier s'intéresse au "document" final et non à la seule page.
Ca c'est un grenier d'expérience dans l'univers normatif. Tout d'un coup
apparait le Web ! Deux enseignements tout de suite :
- le document est une excellente métaphore pour accéder à l'information
d'entrprise, contenue dans des bases de données. c'est une grande
découverte car on est alors capable de proposer une ergonomie cohérente et
à peu de couts à des utilisateurs friants de la nécessité de se connecter
aux différentes bases de son entreprise et de ses partenaires. C'est le
développement des notions d'intranet et d'extranet, surcouches fédératives
d'accès à des bases de données.
- html va manquer de de fonctionnalités pour jouer son rôle fédérateur.
Plutôt que de dériver et d'ajouter des sémantiques dans html, il faut
trouver une autre méthode.
C'est à cette époque que les css se développent et on voit bon nombre de
webmaster coder leurs sites avec uniquement des tableaux de présentation et
des éléments <p> qui utilisent la classe css pour définir ce qu'est
l'information et par là même comment elle va être représentée.
Il existe alors d'une part, un vivier d'experts documentaires, ayant non
seulement testé mais aussi conceptualisé ce qu'est le document et d'autre
part, un besoin important de sémantique. Le génie des concepteurs d'xml est
alors d'avoir inventé le document à deux niveaux : valide ou seulement bien
formé. On pouvait alors démultiplier ses usages sur internet et ailleurs.
C'est ce qui s'est fait ! L'avenir d'XML était au départ un langage
documentaire, et c'est maintenant le remplacant de l'ASCII.
Aujourd'hui, on a donc un méta-langage. Coder du pdf en xml, ca existe, si
mes souvenirs sont bon, le moteur de acrobat, utilise une représentation
interne sous forme XML (ou plutôt quelque chose comme DOM). Coder du
n'importe quoi en xml ... ca existe. Normal, on a inventé un META-langage,
à orientation documentaire faible.
Du coup, avec ce méta-langage, on peut construire toutes les grammaires que
l'on souhaite elles seront représentées par des DTDs ou des schéma. Cela
semble gêner certains, c'est certainement lié à l'anarchie, la gabegie, la
libre concurrence, la ... ? Je ne me pronnonce pas là dessus. L'avantage,
est que l'on dispose d'une technologie partageable, en dehors de toutes
niches comme le documentaire, l'EAI, l'échange inter-applicatif, etc.
Lexique, grammaires, d'aucuns expliquent le manque de sémantique. Un de mes
clients me disait hier qu'il devait être possible, un fois la DTD écrite,
d'afficher directement. Difficile alors de faire comprendre le document
multi-usages ou on ne code qu'une forme logique réutilisable par
différentes applications. Heureseument, le w3c est en train d'introduire
des sémantiques transversales automatiquement reconnaissables par des
applications. Au niveau des documents, ce sont les xlink, xpointer,
xmlbase, xmllang, etc. Au niveau des modèles, ce sont les forts typages de
données des schémas.
Enfin et pour finir, je crois définitivement que le fait que le document
xml soit visible, en clair, n'a aucun intérêt ! A la limite, et en
reprenant CGM ou ODA, on peut avoir différentes représentations : binaire,
full text, text codé. Je suis à ce titre particulièrement intéressé par le
codage de XML en ASN-1.
En effet, si on utilise, par exemple un modèle xml pour les schéma, je
préfère avoir des outils de définition comme XMLSpy plutôt qu'un éditeur
ascii/unicode : mes schémas font, pour les plus complexes quelques
centaines de kiloooctet et c'esdt un peu lourd à lire. De même, si je dois
faire du XSLT, je suis passionné par ce qui se passe du coté de XSLcomposer
et à nouveau XMLSpy.
Que dire alors ? Les outils de manipulation de base, DOM, SAX, XSLT seront
gratuits mais va se développer des outils à forte valeur ajoutée de
manipulation de plus haut niveau, ayant des interfaces utilisateur plus
accessibles ? C'est certainement la différence entre TeX et d'une part Word
ou d'autre part les add-on Wysiwyg à TeX.
Voici une réponse un peu fleuve, j'expère que vous y trouverez quelques
éléments qui vous permettrons d'avancer.
------------
Pierre Attar (mailto:pattar@tireme.fr)
Projet "Mutualiser l'effort de montée en compétences sur XML"
http://www.mutu-xml.org/index.html
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 11:06 UTC
webmaster@xmlfr.org
| 
