Hum, désolé mais je ne comprends comment le fait de n'avoir pas de schéma particulier entraîne un nouveau « standard » particulier. Il me semble au contraire que n'avoir aucune contrainte laisse davantage de liberté. Ensuite, tu peux toujours valider tes documents avant et/ou après compilation.
Je parlais du choix des balises que tu utilises, pour les différentes fonctions : même s'il n'est pas normalisé (avec un schéma), c'est une sorte de convention, de standard « de fait ». Je veux dire, c'est le principe d'un outil que d'avoir certaines conventions : ce que je critique, c'est le fait d'en avoir inventé une nouvelle. Je sais que je mélange un peu les instances particulières des modules que tu utilises et stog lui-même, mais pour moi ton logiciel va forcément apporter certaines conventions pour être « utile » à des personnes qui ne voudront pas réinventer tous les modules que tu utilises.
j'ai l'impression que tu as réinventé XSLT, en moins bien...
Selon quels critères ?
Parce qu'il n'est pas standard, et de plus parce que les modules ne sont pas écrits en XML eux-même, ce qui est un avantage pour moi ; je sais bien que toi tu vas voir ça comme un inconvénient vu que tu as l'air de bien aimer OCaml :-)
Tu peux être plus précis ? de quel algo parles-tu ?
Les règles de la RFC 3986, enfin, ce que ça sous-entend : si tu places ton système dans le monde « hypertexte », les références relatives des URL doivent se faire par rapport à l'emplacement du document lui-même. Cf l'algo https://tools.ietf.org/html/rfc3986#section-5.
Je ne suis pas un expert de XSLT, le peu que j'en ai fait il y a longtemps m'a paru lourdingue au possible.
Oui, c'est vrai que c'est un peu lourdingue. Mais avec l'expérience, j'ai tendance à préférer le lourdingue mais standard, à du moins lourdingue mais « exotique ».
De plus, quand je parle de réécriture, c'est dans un sens assez large: par exemple, certaines balises (typiquement ) font appel à un outil externe pour générer du xml ensuite inclus dans le document (pour , une coloration syntaxique, mais il y a aussi des choses comme la balise du greffon stog-dot, ou du greffon stog-asy).
Effectivement, ce genre de chose est moins facile à faire en XSLT. En théorie, ça aurait dû apparaître de manière plus courante, mais XSLT n'attire pas les foules.
Je ne sais pas (il ne m'a pas semblé à première vue) si XSLT permet ce genre de choses, ou encore s'il permet de compiler plusieurs fichiers à la fois avec inclusion d'un bout de l'un dans l'autre à une certaine étape de la compilation.
Je ne suis pas sûr de ce dont tu parles, mais l'inclusion est possible.
Il y a peut-être un moyen de le faire avec des transformations XSLT successives, mais c'est simple dans Stog.
Pour l'enchaînement de transformation, j'avoue utiliser la souplesse des pipe en shell, géré par Makefile.
J'insiste sur le fait que ce dernier est orienté publication, donc influencé par le format de sortie, notamment (X)HTML, et qu'il offre donc des facilités pour viser une sortie de ce type.
Même si XSLT est plus généraliste, le XHTML est également un format courant en sortie pour lui aussi.
Encore une fois, il n'y a pas de syntaxe nouvelle dans Stog, c'est du XML.
Oui, pardon, je ne parle pas de « syntaxe » au sens premier, mais de la « sémantique » des nœuds, si tu veux, même si une fois qu'on prend le XML pour base, le sens de l'enchaînement des balises devient pour moi de la syntaxe... Et donc, Stog au sens du logiciel et des modules que tu promeus avec forment une nouvelle « syntaxe ».
Ensuite, il y a une sémantique par défaut pour certaines balises pour le nœud racine d'un document.
Je n'ai pas tout à fait compris cette phrase : tu veux dire que les balises « processées » par Stog sont seulement celles filles du nœud racine ?
[^] # Re: Format des fichiers source ?
Posté par benoar . En réponse à la dépêche Sortie de Stog en version 0.15. Évalué à 2.
Je parlais du choix des balises que tu utilises, pour les différentes fonctions : même s'il n'est pas normalisé (avec un schéma), c'est une sorte de convention, de standard « de fait ». Je veux dire, c'est le principe d'un outil que d'avoir certaines conventions : ce que je critique, c'est le fait d'en avoir inventé une nouvelle. Je sais que je mélange un peu les instances particulières des modules que tu utilises et stog lui-même, mais pour moi ton logiciel va forcément apporter certaines conventions pour être « utile » à des personnes qui ne voudront pas réinventer tous les modules que tu utilises.
Parce qu'il n'est pas standard, et de plus parce que les modules ne sont pas écrits en XML eux-même, ce qui est un avantage pour moi ; je sais bien que toi tu vas voir ça comme un inconvénient vu que tu as l'air de bien aimer OCaml :-)
Les règles de la RFC 3986, enfin, ce que ça sous-entend : si tu places ton système dans le monde « hypertexte », les références relatives des URL doivent se faire par rapport à l'emplacement du document lui-même. Cf l'algo https://tools.ietf.org/html/rfc3986#section-5.
Oui, c'est vrai que c'est un peu lourdingue. Mais avec l'expérience, j'ai tendance à préférer le lourdingue mais standard, à du moins lourdingue mais « exotique ».
Effectivement, ce genre de chose est moins facile à faire en XSLT. En théorie, ça aurait dû apparaître de manière plus courante, mais XSLT n'attire pas les foules.
Je ne suis pas sûr de ce dont tu parles, mais l'inclusion est possible.
Pour l'enchaînement de transformation, j'avoue utiliser la souplesse des pipe en shell, géré par Makefile.
Même si XSLT est plus généraliste, le XHTML est également un format courant en sortie pour lui aussi.
Oui, pardon, je ne parle pas de « syntaxe » au sens premier, mais de la « sémantique » des nœuds, si tu veux, même si une fois qu'on prend le XML pour base, le sens de l'enchaînement des balises devient pour moi de la syntaxe... Et donc, Stog au sens du logiciel et des modules que tu promeus avec forment une nouvelle « syntaxe ».
Je n'ai pas tout à fait compris cette phrase : tu veux dire que les balises « processées » par Stog sont seulement celles filles du nœud racine ?