Ceci est une annotation test.

Voyons si cela est vrai !

Il faudrait définir précisément ce que "technological environment" signifie, et pourquoi pas plutôt "technical environment" par exemple (sans vouloir couper les cheveux en 4) ?

Ce "paradoxe de l'accès" pourrait aussi être comparé avec la question de l'accès aux données numériques ? Les données sont produites, stockées, mais sont-elles encore accessibles, compréhensibles (par des machines ou des humains) ou exploitables ?

= to perform

Remplacer par "4 novembre" (supprimer le "0").

Ajouter un lien ici ?

Préférer "libre accès".

À reformuler : il ne faudrait pas faire croire que ces deux types de modèles existent dans deux mondes parallèles.

Trop d'adaptations dans la même phrase.

Virgule à supprimer.

Je ne suis pas sûr de la justesse de cette expression, il faudrait préciser qu'il ne s'agit pas d'une écriture collective au sens littéral du terme, mais plutôt d'un processus collectif (impliquant des éditeurs·trices).

À reformuler, puisque l'utilisation de Stylo implique un protocole spécifique, mais plus ouvert que d'autres outils comme les traitements de texte.

Définition ou référence nécessaire:

Oui, mais peut-être surtout pour vendre plus de livres aussi.

Attention à l'utilisation de ce concept, voir par exemple : https://sens-public.org/articles/1184/ À reformuler en "Les innovations éditoriales" ?

Il serait pertinent de développer un petit peu plus cette affirmation, avec peut-être des exemples supplémentaires.

Une contextualisation est nécessaire, de quoi s'agit-il ?

Virgule à supprimer.

Attention à ne pas généraliser. Par ailleurs le choix de fonctionnement de l'entreprise que sont les PUG n'implique pas forcément un accès ouvert et libre.

Ce serait plutôt l'inverse. Dans le paysage français une bonne partie des "presses universitaires" sont rattachées à une université et non pas les mêmes obligations de rentabilité qu'une maison d'édition privée.

Il ne s'agit pas du choix de la plateforme mais de l'éditeur ou de la revue. Ainsi certaines revues diffusent directement en libre accès sans commercialisation.

Certaines pour le moment, pas toutes.

Remplacer par Git (voir https://fr.wikipedia.org/wiki/Git).

Préférer "éditent" car il s'agit d'un travail d'édition (qui implique une fabrication).

Est-ce que c'est un domaine qui réfléchit à quelque chose (avec son bagage de savoir et de références) ou est-ce que c'est une personne (avec un bagage moins structuré et identifié) ?

Est-ce qu'il ne faudra pas signaler qu'il s'agit aussi parfois (souvent ?) d'une dimension d'interprétation inhérente à toute activité de ce type ? Une transcription n'implique-t-elle pas nécessairement des choix et des décisions de la part du transcripteur (même s'il se base sur des normes) ?

Est-il possible d'utiliser les deux en même temps ? C'est-à-dire une description très détaillée et indépendante de la forme, et une description succincte reprenant l'aspect du document original (dans le cas d'une absence de norme bibliographique correspondant).

Cette pratique est fortement déconseillée en HTML, qu'en est-il en XML TEI ? Est-ce qu'il est important de conserver cette information dans un même fichier ou est-ce qu'il y a un intérêt à la stocker ailleurs (dans une feuille de style) ? Cela ne risque pas d'alourdir fortement le fichier ?

Si, il s'agit bien d'une information porteuse de sens : il s'agit d'un passage surligné, donc mis en valeur. De la même façon qu'en HTML il est possible d'indiquer un passage en emphase avec la balise <em> (et non <i> qui signifie italique), et ensuite il est possible de définir cette emphase comme étant en italique (il s'agit alors du rendu graphique). C'est un point que je trouve important.

Le "dans" porte à confusion : le principe d'une feuille de style est d'accompagner un document structuré, et non d'être incorporée à celui-ci. Il y a ainsi une distinction très nette entre la structure et la mise en forme. (Même s'il est possible de styler un document HTML directement dans le HTML, c'est absolument déconseillé.)

Comme d'autres langages de balisage, sémantiques par défaut : HTML, mais aussi Markdown ou AsciiDoc. Remarque qui prolonge cette annotation dans le chapitre précédent.

À défaut d'explorer ce problème (que j'avoue découvrir et qui me semble facilement contournable, mais je suis conscient de ma naïveté) est-ce qu'une référence pourrait être ajoutée ici ?

À la lecture de ce passage je me pose une question : les métadonnées habituellement identifiées et indiquées à côté du document qui les concerne (notice bibliographique par exemple) peuvent être intégrées dans le document avec la TEI, est-ce que cela ne fait pas doublon ? Est-ce qu'il sera plus difficile de les exploiter si elles ne sont disponibles que dans le document en XML TEI ?

HTML et TeX sont des langages de balisage qui ne comportent pas d'indication de mise en forme (au sens de rendu graphique), même si des feuilles de style sont parfois attribuées par défaut (par exemple dans la plupart des navigateurs un lien sera indiqué en bleu et souligné même s'il n'y a pas de feuille de style). Il me semble que l'on ne peut pas parler de "langage de formatage" pour LaTeX et HTML.

Complet = fini ? délimité ? Dont le contenu ne sera pas modifié ?

Est-ce que cela signifie que chaque document encodé en TEI devrait avoir sa propre documentation pour préciser le sens de certains @type ou @xml:id ? De la même façon que du code HTML ou CSS est parfois commenté pour faciliter sa compréhension et son évolution. Peut-être que ce point est évoqué dans une autre partie.

Peut-être qu'ajouter un lien ici permettrait de se rendre compte de la documentation disponible (et de son ampleur).

Loin de moi l'idée de lancer un débat sur le XML, mais est-ce qu'il ne faudrait pas évoquer la différence avec d'autres standards comme le HTML, et plus spécifiquement HTML5 qui évolue sans devenir un monstre ? (C'est une vraie question) Voir par exemple : https://www.xml.com/articles/2017/02/20/beyond-xml-making-books-html/

Une référence utile à ce sujet, même s'il ne s'agit pas d'un publication scientifique : https://ia.net/topics/multichannel-text-processing

J'irais plus loin : les traitements de texte classiques entretiennent une confusion entre structure (sémantique) et mise en forme (rendu graphique), même s'il serait trop long d'expliquer les raisons (UI, UX, culture numérique).

Je pinaille mais il ne faudrait pas laisser penser qu'aucun logiciel spécifique n'est nécessaire pour lire ou produire des fichiers XML TEI.