Quant à XPath, ça ne permet pas que de récupérer les noms de programmes dans le texte mais aussi les noms de programmes mentionnés dans les see also ou en tant que termes d'un glossaire.
Je n'ai pas compris. Je ne connais pas le fonctionnement de DocBook.
Ce qu'il voulait dire, c'est que XML et SGML ne sont pas qu'une famille de format de balisage et/ou de description de documents. Ce sont d'abord des « grammaire » pour décrire des structures arborescentes (ce qui s'applique bien à des « documents structurés » mais est tout à l'opposé des langages de description de pages pour lesquels les formats de description de pages —comme TeX/TROff/RTF/etc.— sont des abstractions plus hauts niveau.) Ces grammaires sont distribuées dans une forme normalisée (XML Schema puis ReLaX NG ainsi que DTD plus historiquement) et ne sont plus des grammaires incorporées dans les outils (et documentées en syntaxe BN par exemple.) Du coup c'est très bien comme format d'échange, mais je m'égares un peu.
Outre la validation, cette arborescence peut être simplement interrogée/requêtée et c'est ce que formalisent XPath et XQuery.
De la même façon, on peut mettre en œuvre des transformations d'une grammaire en une autre en utilisant XSLT et indiquer avec XSL-FO les règles générales de présentation ; ce qui la rend la chose encore meilleur comme format d'échange, mais je m'éloigne trop.
Ceci sont valables pour tous les documents XML. On peut avoir des XML pour une base de données bibliographique, pour sa collection de timbres, pour du dessins vectoriel (c'est le cas avec SVG), pour du texte structuré (c'est le cas avec les formats OpenDocument, epub, TEI et DocBook...)
Je suppose que see also est une section balisée comme telle dans DocBook. Si c'est le cas, il n'y a pas d'équivalent à ce que tu dis dans troff. Cette section pourrait être implémentée entre deux appels de macros .SEE_ALSO1 et .SEE_ALSO2 et à l'intérieur tu pourrais y mettre l'appel à .APPLICATION comme partout ailleurs
C'est un peu l'idée mais en plus subtile. Comme les index et les différentes tables (illustrations, tableaux, etc.) tu peux donc avoir une section VoirAussi avec une sous-section Logiciels (ou juste une section Index des programmes...) où les programmes ne sont pas référencés comme dans le corps du document (car pas besoin de mise en page/évidence particulière) mais on sait facilement récupérer cette liste ...en plus des éléments ailleurs.
Bref, XML est utilisé et devrait être la norme (d'échanges) dans les systèmes de traitement documentaires. Ce genre de système (pense par exemple au catalogue de la BNF ou tout système où on doit pouvoir indexer finement et réorganiser programmatiquement de larges volumes) n'a pas de lien avec son propre système de documentation (écrire ses rapports/mémoires/livres) et de toute façon, XML est ingérable à la main (i.e. dans un simple éditeur de texte par exemple.) Je milite pour l'emploie de XML mais il n'est pas dans mon workflow personnel.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Lout
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Redécouverte : Roff. Évalué à 10.
Ce qu'il voulait dire, c'est que XML et SGML ne sont pas qu'une famille de format de balisage et/ou de description de documents. Ce sont d'abord des « grammaire » pour décrire des structures arborescentes (ce qui s'applique bien à des « documents structurés » mais est tout à l'opposé des langages de description de pages pour lesquels les formats de description de pages —comme TeX/TROff/RTF/etc.— sont des abstractions plus hauts niveau.) Ces grammaires sont distribuées dans une forme normalisée (XML Schema puis ReLaX NG ainsi que DTD plus historiquement) et ne sont plus des grammaires incorporées dans les outils (et documentées en syntaxe BN par exemple.) Du coup c'est très bien comme format d'échange, mais je m'égares un peu.
Outre la validation, cette arborescence peut être simplement interrogée/requêtée et c'est ce que formalisent XPath et XQuery.
De la même façon, on peut mettre en œuvre des transformations d'une grammaire en une autre en utilisant XSLT et indiquer avec XSL-FO les règles générales de présentation ; ce qui la rend la chose encore meilleur comme format d'échange, mais je m'éloigne trop.
Ceci sont valables pour tous les documents XML. On peut avoir des XML pour une base de données bibliographique, pour sa collection de timbres, pour du dessins vectoriel (c'est le cas avec SVG), pour du texte structuré (c'est le cas avec les formats OpenDocument, epub, TEI et DocBook...)
C'est un peu l'idée mais en plus subtile. Comme les index et les différentes tables (illustrations, tableaux, etc.) tu peux donc avoir une section VoirAussi avec une sous-section Logiciels (ou juste une section Index des programmes...) où les programmes ne sont pas référencés comme dans le corps du document (car pas besoin de mise en page/évidence particulière) mais on sait facilement récupérer cette liste ...en plus des éléments ailleurs.
Bref, XML est utilisé et devrait être la norme (d'échanges) dans les systèmes de traitement documentaires. Ce genre de système (pense par exemple au catalogue de la BNF ou tout système où on doit pouvoir indexer finement et réorganiser programmatiquement de larges volumes) n'a pas de lien avec son propre système de documentation (écrire ses rapports/mémoires/livres) et de toute façon, XML est ingérable à la main (i.e. dans un simple éditeur de texte par exemple.) Je milite pour l'emploie de XML mais il n'est pas dans mon workflow personnel.
"It is seldom that liberty of any kind is lost all at once." ― David Hume