Format XML de texte enrichi léger ?

Question

J'écris une application de traitement de texte de base et j'essaie de m'installer sur un format natif "interne", celui que mon code analyse afin de le restituer à l'écran.J'aimerais que ce soit XML afin de pouvoir, à l'avenir, simplement écrire du XSLT pour le convertir en ODF ou XHTML ou autre.

Lorsque l’on recherche des normes existantes à utiliser, la seule qui semble prometteuse est ODF.Mais cela ressemble à une exagération massive par rapport à ce dont j'ai besoin.Tout ce dont j'ai besoin, ce sont des balises de paragraphe, une sélection de polices, une taille de police et une décoration... c'est à peu près tout.Il me faudrait beaucoup de temps pour implémenter ne serait-ce qu'un moteur de rendu ODF minimal, et je ne suis pas sûr que cela en vaille la peine.

En ce moment, je pense créer mon propre format XML, mais ce n'est pas vraiment une bonne pratique.Mieux vaut utiliser un standard, d'autant plus que je pourrai probablement trouver les XSLT dont je pourrais avoir besoin à l'avenir déjà écrits.

Ou devrais-je simplement mordre la balle et mettre en œuvre la FDAL ?

MODIFIER:Concernant la réponse

Je connaissais XSL-FO auparavant, mais en raison du poids de la spécification, je n'y avais pas vraiment pensé.Mais vous avez raison, un sous-ensemble me donnerait tout ce dont j'ai besoin pour travailler et une marge de croissance.Merci beaucoup pour le rappel.

De plus, en incluant une bibliothèque de rendu comme FOP ou RenderX, je bénéficie de la génération PDF gratuitement.Pas mal...

Answer 1

Comme vous êtes sûr de devoir représenter le présentation côté des choses, cela vaut peut-être la peine de regarder le XSL-FO Recommandation du W3C.Il s’agit d’un langage de description de page à part entière et de l’autre moitié (profondément démodée) du XSLT plus connu.

De toute évidence, le tout est tout sauf "Lightwight", mais si vous venez d'incorporer un sous-ensemble très limité - qui pourrait même être (pour correspondre à vos spécifications de "étiquettes de paragraphe, sélection de polices, taille et décoration de la police") pour: bloquer et le propriétés de police communes, quelque chose comme:

<yourcontainer xmlns:fo="http://www.w3.org/1999/XSL/Format">
    <fo:block font-family="Arial, sans-serif" font-weight="bold"
        font-size="16pt">Example Heading</fo:block>
    <fo:block font-family="Times, serif"
        font-size="12pt">Paragraph text here etc etc...</fo:block>
</yourcontainer>

Cela présenterait peut-être quelques avantages par rapport au simple fait de rouler le vôtre.Il existe une spécification ouverte sur laquelle travailler, et tout ce que cela implique.Il réutilise les propriétés CSS en tant qu'attributs XML (de la même manière que SVG), de sorte que de nombreux détails de formatage vous sembleront quelque peu familiers.Vous auriez un chemin de mise à niveau si vous décidiez plus tard que, par exemple, la pagination intelligente était une fonctionnalité indispensable - incluant davantage de sections de la spécification à mesure qu'elles deviennent pertinentes pour votre application.

Il y a une autre chose que vous pourriez obtenir en étudiant XSL-FO : voir à quel point même le simple fait de faire des paragraphes et des polices peut être horriblement compliqué.Essayer de faire une mise en page de texte et des sauts de ligne « de la bonne manière » pour différentes langues et cas d'utilisation me semble très intimidant.

Answer 2

Si c'est uniquement pour le traitement de texte, alors peut-être DocBook pourrait être un peu plus léger que l'ODF ?

Cependant, l'entrée wiki indique :

DocBook est un langage de balisage sémantique pour la documentation technique.Il était initialement destiné à la rédaction de documents techniques liés au matériel informatique et aux logiciels, mais il peut être utilisé pour tout autre type de documentation.

Il n'est donc peut-être pas adapté à un traitement de texte à usage général ?

L'avantage d'utiliser DocBook serait le fait qu'un certain nombre de convertisseurs de format DocBook -> autres devraient être disponibles ?J'espère que cela t'aides.

Answer 3

J'aime DocBook, mais ça ne me convient pas vraiment.Il s'efforce d'être indépendant de la présentation, l'intention étant que vous utilisiez XSLT pour le restituer dans un format de présentation.

Dans un traitement de texte, l'utilisateur édite la présentation ainsi que le contenu.Par exemple, l'utilisateur ne souhaite pas marquer un "mot-clé", il souhaite nécessairement mettre du texte en gras.

Un éditeur DocBook serait une très bonne chose (je ne suis pas sûr qu'il en existe un bon), mais ce n'est pas vraiment ce que je fais.

Answer 4

Eh bien, c'est vrai...Mais puisque je dois de toute façon pouvoir convertir en XML, pourquoi conserver en mémoire mon arborescence de documents et l'arborescence DOM, alors que rien ne m'empêche de travailler directement à partir de l'arborescence DOM ?

D'autant plus qu'une caractéristique unique de mon programme est que tout est toujours enregistré au fur et à mesure que vous tapez, et je ne souhaite pas exécuter une conversion complète en XML à chaque fois que j'appuie sur une touche.Il est plus facile de lier les entrées et les sorties directement à mon arborescence DOM en mémoire.

Modifier:Oh, et le seul problème avec XHTML est que je souhaite prendre en charge la pagination de base.Bien que je suppose que rien ne m'empêche d'utiliser des balises supplémentaires pour cela...

Answer 5

XML est un externe formater, pas interne.

Quel est le problème avec XHTML?C'est simple et omniprésent (du moins le HTML l'est).Votre implémentation serait facile à déboguer et vos utilisateurs vous en seront éternellement reconnaissants.