>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.
# Etna
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un éditeur XML Wysiwyg passe au libre. Évalué à 10.
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.