Liens connexes

Dépêche modérée par

Dépêche éditée par

: Un éditeur XML Wysiwyg passe au libre

Posté par Gohar (). Modéré le 04 juillet 2009.
25
Séparer le fond de la forme, tel est le Graal de la rédaction technique, voire de la rédaction tout court. Si les formats XML tels que DocBook ou Dita répondent parfaitement à ce besoin, ils étaient encore réservés à ceux qui sont prêts à mettre les mains dans le cambouis et à manipuler des balises XML sous des éditeurs tels que vim ou Emacs.

Des solutions WYSIWYG plus simples de prime abord existaient, mais elles étaient - pour le moment - toutes propriétaires.

La libération par Syntex de son produit phare sous licence libre GPL v3 pourrait bouleverser le paysage de la création de documents dans les prochaines années et, peut-on rêver, pousser à l'abandon de cette hérésie qu'est le traitement de texte.

Si la version libre du produit souffre encore de quelques bugs, il est déjà tout à fait utilisable pour créer du contenu XML. Pour la génération au format HTML, PDF ou autre, en revanche, il faut toujours faire appel à des solutions telles que DITA Open Toolkit.

> Lire les commentaires (63 commentaires, moyenne: 3,6).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

WYDSIWYGBYMDIFTSIIN

Posté par ǝsɐʃdoıx∀ ıɥs∀ (page perso, ) le 04/07/2009 à 06:15. (lien). Évalué à 9.

What you don't see is what you get but you must download it fist to see it, in fact.

Pour moi, vim est le wysiwyg idéal pour du XML.
C'est un format de description de données à qui aucune sémantique d'interprétatio n'est attachée, donc "voir du xml", pour moi, c'est bien voir des tags imbriqués et indentés, avec des jolies couleurs.

J'ai du chercher pour trouver une capture d'écran, et j'ai eu du mal. Enfin, en voilà une ]http://www.syntext.com/images/screenshots/serna-on-vista.png] et une autre [http://www.syntext.com/images/screenshots/custom-content.png].

En revanche, ça me fait effectivement penser que ça serait bien si je savais, avec mon éditeur de texte, paramétrer une sémantique pour avoir des commandes "met le curseur sur le prochain chapitre" ou "update moi automatiquement l'index quand je rajoute une balise TOTO" quand j'édite un fichier basé sur XML qui représente tel ou tel format bien documenté *et avec une interprétation*.

--
Je ne suis pas toujours de mon avis.

Le traitement de texte, une hérésie ?

Posté par pititjo (Jabber id, ) le 04/07/2009 à 09:02. (lien). Évalué à 7.

pousser à l'abandon de cette hérésie qu'est le traitement de texte.

Je ne pense pas que le traitement de texte soit, en lui même, une hérésie.Un traitement de texte n'est rie d'autre qu'un éditeur wysiwyg de xml. L'hérésie c'est la façon dont les traitements de texte sont utilisés : à savoir sans aucune séparation du fond et de la forme.

Il est possible de faire un document open office avec une séparation stricte du fond et de la forme en utilisant les feuilles de style. C'est juste super pas optimisé côté ergonomie. De ce point de vue là, et ça me fait assez mal de le dire, office 2007 s'en sort franchement bien : en rendant les styles plus visible que les gras, italiques, soulignés et compagnie, le traitement de texte de microsoft est susceptible de faire changer, dans le bon sens, la façon dont on utilise un traitement de texte.

D'une certaine façon, dommage qu'on est eu besoin d'attendre microsoft pour que l'interface des traitements de texte bouge mais maintenant j'espère qu'on va se diriger vers des traitements de texte libres qui réfléchissent à une interface optimisée plutôt que d'imiter le même schéma depuis 20 ans.

Petite remarque

Posté par obiyann () le 04/07/2009 à 18:15. (lien). Évalué à 9.

Bonsoir.

Cette dépêche est intéressante, mais dire le nom du logiciel concerné aurait été bienvenu. J'ai dû aller dans les liens pour savoir le nom du logiciel concerné: "Serna Free".

Merci tout de même pour cette dépêche intéressante, ce message est juste une petite remarque sur sa rédaction.

Après un test de 5 minutes

Posté par LeJulien () le 04/07/2009 à 21:02. (lien). Évalué à 1.

Je pensais découvrir l'intérêt de la chose en testant le logiciel. Mais rien... Mais si des entreprises payent $749 la licence, ça doit avoir son utilité. Allez, 10 minutes de plus au cas où.

Mais comme toute libération, c'est une excellente nouvelle qu'il convient de saluer.

--
Mon dieu ! ils ont tué Hadopi ! bande d'enfoirés !

Prudence avec l'emploie du mot WYSIWYG

Posté par Stéphane P. () le 04/07/2009 à 23:46. (lien). Évalué à 6.

Je ne suis pas sûr que l'on puisse parler de WYSIWYG pour un éditeur XML générique, étant que le XML tout seul, ce n'est pas un format destiné a afficher ou imprimer quelque chose...

J'ai toujours pensé que l'on n'utilisait cette acronyme lorsque le résultat est visuellement identique a ce que l'on imprime ou ce qui est affiché une fois l'édition des données terminées, par exemple un traitement de texte.

Par exemple imaginez que l'on tape une équation MathML, une page web XHTML, ou un fichier SVG avec cet éditeur (tous des formats XML), voit-on le résultat en temps réel au cours de l'édition tel qu'il va être imprimé ? certainement pas !

Vos avis ?

./serna.bin: error while loading shared libraries: libqtpropertybrowser.

Posté par ctorah () le 05/07/2009 à 18:19. (lien). Évalué à 0.

J'ai voulu tester sur ma debian testing et y me dit ça :

./serna.bin: error while loading shared libraries: libqtpropertybrowser.so.1: cannot open shared object file: No such file or directory

pas trés concluant!

Amusant

Posté par Tanguy Ortolo (Jabber id, page perso, ) le 05/07/2009 à 22:47. (lien). Évalué à 4.

Amusant, comme concept, le DocBook graphique. Mais ce n'est pas demain que j'utiliserai autre chose que Vim pour éditer la formation Debian, franchement. Je trouve qu'on s'y perd un peu, avec un clicodrome qui ne rend pas les balises plus apparentes.

Je m'attendais à un genre d'EDI pour DocBook, comme KILE pour LaTeX.

Non, je n'ai pas tout dit !

Posté par Gohar () le 06/07/2009 à 09:26. (lien). Évalué à 3.

Mais c'est pas drôle si on dit tout d'un coup :-)

L'interview du COO de syntext est très intéressante, notamment parce qu'il cite la crise comme facteur majeur de sa décision de libérer le code:

La crise financière mondiale, qui a fortement touché le marché informatique (avec un chiffre d'affaires en baisse de 50 à 60 %), nous a amené à envisager une approche très différente de notre activité.

(The world financial crisis situation, which the IT market has clearly felt (with a revenue drop of 50%-60%), has made us think that we have to approach very differently our business.)


Est-ce que dans un monde que les plus pessimistes disent en train de s'effondrer, le libre offrirait un modèle alternatif crédible?

À verser en tout cas au dossier Impact de la crise sur le logiciel libre.

Etna

Posté par Laurent J (page perso, ) le 06/07/2009 à 13:12. (lien). Évalué à 10.

>Des solutions WYSIWYG plus simples de prime abord existaient, mais elles étaient - pour le moment - toutes propriétaires.

Non, pas toutes, il y avait le projet Etna, que j'ai commencé à développer il y a presque 5 ans. Entièrement libre, basé sur Mozilla (qui possède un bon moteur de rendu, et des fonctions d'éditions mais que j'ai du quand même hacker). http://etna.disruptive-innovations.com

Malheureusement, faute de temps, il n'est pas encore prêt pour une utilisation en production, et je peine à trouver du temps (surtout depuis que je ne suis plus chez disruptive innovations) pour finaliser une nouvelle version qui contient un nouveau validateur RelaxNG temps réèl plus costaud, et basé sur un gecko plus récent...

Sinon, pour répondre à certaines questions, faire du XML wysiwyg (ou plutôt de l'édition "visuel" d'un document XML, sans que l'utilisateur ait à écrire/à voir du XML), c'est plutôt compliqué, voir plus compliqué que de faire un éditeur HTML wysiwyg.

Quand l'éditeur connait en natif le format XML, (genre Kompozer pour (x)html, ou OpenOffice pour odf), on peut "cabler" en dur des comportements pour tel ou tel balise, voir même à la limite transformer le document XML en un truc binaire qui serait plus facilement exploitable par le moteur de rendu et d'édition.

Mais quand il s'agit d'un éditeur générique, c'est à dire qu'il puisse éditer visuellement n'importe quel type de document XML, ça se complique. Il faut d'abord fournir à l'éditeur un schéma pour qu'il puisse faire de la validation, qu'il sache quel element on peut créer et où, et vérifier le contenu textuel que l'on insère dans ces éléments... Mais ce n'est pas suffisant, car l'éditeur doit pouvoir savoir comment afficher ces balises, si par exemple ce sont des balises qui représente des blocks, ou si ce sont des élements "inlines" (comme le strong en XHTML par exemple.) Malheureusement, il n'est pas possible de fournir ce genre d'informations dans les formats de schemas existants (XMLSchema ou RelaxNG, et puis DTD, on oublie hein).

Il n'est pas possible non plus d'indiquer quel est le contenu par défaut quand on crée tel élément. L'éditeur peut éventuellement le deviner à partir du schema, mais quand il y a plusieurs choix possibles, ben il prend le premier, qui n'est pas forcément celui que veut l'utilisateur...

Manque aussi tout ce qui est descriptif. Un éditeur XML générique, il ne sait pas ce qu'est la balise P en XHTML. Et indiquer "inserer un P" à l'utilisateur, ça va pas beaucoup aider ce dernier. Il faut donc un moyen de dire à l'éditeur que P, c'est un "paragraphe", afin que l'interface soit intuitive. Il faut aussi apporter des descriptions pour que l'utilisateur puisse faire son choix quand, lorsque pour créer un élément, il y a plusieurs choix autorisés par le schema.

Bref, il n'y a rien de prévu dans XMLSchema et RelaxNG pour les éditeurs. Il faut donc fournir ces informations, en plus du schema.

Dans Etna, ça passe par des balises supplémentaire dans RelaxNG (c'est autorisé par la spec RelaxNG) pour tout ce qui est nécessaire à l'édition proprement dite. Et pour ce qui est de l'affichage, il faut fournir une feuille CSS.

Il y a aussi des problèmes d'interfaces utilisateurs. Même dans un document XML orienté textuel, il y a des éléments contenant des informations "techniques" (des metas datas, ou le titre du document par exemple). Là encore, l'éditeur wysiwyg ne peut pas deviner la nature de ces éléments. Et il est préférable que ces informations soient édités avec une interface dédiés. Il faut donc que l'éditeur fournisse des "hooks" pour pouvoir lancer par exemple une boite de dialogues pour éditer ces choses (genre dans open office, la boite de propriété du document). Bref, il faut fournir des éléments d'interface graphique à l'éditeur. Dans Etna, ça passe donc par la réalisation d'une extension (à la firefox) (et la feuille de styles CSS cache les éléments qu'il faut pas éditer via la zone d'édition) .


Enfin, pour les questions à propos de l'utilité d'un editeur XML "wysiwyg", posez vous alors la question : préféreriez vous éditer un document open-office "à la main" avec VI ? Pensez vous que cette méthode d'édition serait plus pratique pour madame michu pour écrire son courrier ? Pour ma part, je dis non. L'utilisateur en à la limite rien à foutre du format. Ce qu'il veut, c'est écrire son document le plus simplement du monde, et que ce document puisse être ensuite utilisé correctement par d'autres outils éventuels (l'éditeur doit produire du XML valide etc.)

Mais maintenant, un éditeur XML wysiywg n'est pas fait non plus pour éditer n'importe quel type de fichier XML. Ca reste bien entendu utile que pour les formats XML orienté documents textuels (docbook, xhtml, odf et j'en passe). Ça n'a bien entendu aucun sens d'éditer par exemple un fichier de configuration XML avec ce genre d'outils. Pour ce genre de document, c'est plus une interface utilisateur graphique qu'il faut, pas une surface de rendu/d'édition textuelle.

Enfin il faut savoir qu'il y a pas mal de domaines et d'industries, où des documents textuels sont stockés en XML, et dans un format XML qui leur ait propre parce que mieux adapté à leurs besoins et parce que leur système d'information a été conçu avec ce format.

J'ai l'exemple d'ailleurs de Rice University (qui commanda le projet Etna), qui stockent leurs cours dans leur propre format XML, et qu'ils publient ensuite sur le web (après transformation via XSLT). Et les gens qui éditent ce genre de document avaient voulu une sorte de traitement de texte, plutôt que d'apprendre le markup du format, ou d'utiliser ces éditeurs XML arborescents et peu pratique finalement pour ce genre de documents... (et malheureusement, suite à l'ouragan catherina, leur budget a été restreint, et n'ont pas pu continuer à financer le projet Etna...)


Enfin pour conclure, les éditeurs XML wyiwyg, c'est comme pour les browsers ou les éditeurs HTML wysiwyg : y en a très peu en open source, parce que ça demande des compétences spécifiques, ça demande de la recherche (donc du temps, donc des sous) parce que c'est un domaine complexe (tant au niveau technique qu'au niveau interface utilisateur), et qu'il y a peu d'expériences "publiques", de feedback, pour aider à leur réalisation.

Revenir en haut de page