Développement du plan

This commit is contained in:
Bastien Dumont 2020-12-30 14:31:38 +01:00
parent a7d09aaa4e
commit bf3d08616a

View File

@ -104,7 +104,7 @@ On peut surmonter de trois manières différentes le fait que les spécification
#. N'utiliser que les fonctionnalités offertes, en modifiant et en complétant à la main le résultat produit par le processeur CSL. Ainsi, pour indiquer une source, on peut enregistrer la publication dans laquelle elle est éditée dans *Zotero*, choisir un style assez proche de celui de la revue visée et ajouter à la main la mention de l'auteur et du nom de la source. Cette solution n'implique aucun bricolage, limite au minimum le temps d'apprentissage et laisse aux revues la possibilité de proposer des styles CSL sur les dépôts officiels qui ne sont pas complètement conformes à leurs directives, mais suivent en revanche rigoureusement les spécifications de CSL. Elle ne permet toutefois pas de tirer pleinement profit des possibilités de CSL et impose un long temps de vérification et de correction ;
#. Inventer des variables qui ne figurent pas dans les spécifications CSL et rédiger des feuilles de style qui les utilisent. Cette solution est applicable dans la mesure où le processeur utilisé supporte les variables non standard, ce qui est le cas de *citeproc-js* (le plus répandu) et de *citeproc* (sur lequel s'appuie Pandoc) ;
#. Utiliser des variables existantes d'une manière qui n'est pas prévue par les spécifications, ce qui permet de respecter formellement le schéma CSL et de créer des styles compatibles avec tous les processeurs. Plus précisément, cette stratégie consiste à *spécialiser* des variables très abstraites (telles que `annote` pour indiquer un titre de source) et à *détourner* des variables plus spécialisées dont les historiens n'ont a priori pas besoin (telles que `jurisdiction` pour indiquer la langue d'origine d'un document traduit).
#. Utiliser des variables existantes d'une manière qui n'est pas prévue par les spécifications, ce qui permet de respecter formellement le schéma CSL et de créer des styles compatibles avec tous les processeurs. Plus précisément, cette stratégie consiste à *spécialiser* des variables très abstraites (telles que `annote` pour indiquer un titre de source) et à *détourner* des variables plus spécialisées dont les historiens n'ont a priori pas besoin (telles que `original-publisher` pour indiquer la langue d'origine d'un document traduit).
Le projet *CSL/Clio* repose sur la troisième option. Certes, l'invention de nouvelles variables présente l'avantage de la clarté, et le détournement de variables existantes pourrait entrer en conflit avec des besoins imprévus. J'ai choisi de privilégier la compatibilité avec le plus grand nombre de processeurs. De plus, l'utilisation de variables non standard interdirait de placer les styles développés dans le cadre de *CSL/Clio* dans les dépôts de CSL et de *Zotero*. J'espère que les évolutions futures de CSL permettront de se passer du détournement de variables ; si les adaptations nécessaires à notre discipline se limitent à des spécialisations, une intégration aux dépôts officiels deviendra envisageable.
@ -175,6 +175,8 @@ Pour l'instant, le projet *CSL/Clio* est surtout informé par ma pratique de doc
### Indications de mise en forme dans une valeur de champ
### Intervalles de dates
### Champ *Extra*
### Console JavaScript
@ -189,13 +191,29 @@ Pour l'instant, le projet *CSL/Clio* est surtout informé par ma pratique de doc
## Enregistrement des documents selon les conventions de *CSL/Clio*
### Rôles
<!-- Préciser ici le cas particulier du collaborateur -->
### Sources primaires
### Rôles
### Manuscrits
### Actes de colloque, revues, sites webs, blogs
###
### Ouvrages traduits
### Ouvrages en plusieurs volumes
### Classement de la bibliographie en catégories
### Apostrophes et guillemets
## Pratiques à éviter
### Abréger les prénoms
### Faire confiance à l'enregistrement automatique des références à partir du navigateur
# Automatiser la mise en forme