Ces deux items ayant la même extension .unit, y aurait-il une « astuce » pour transformer un item « fragment » en item « partie de contenu » ?
En effet, nous avons saisi 900 fragments pour un portail réglementaire spécifique… et nous nous appercevons maintenant que nous aurions dû créer des « parties ».
Je crois pour me « disculper » que le choix du fragment a été fait car « avant » on ne pouvait pas faire un lien entre un bout de texte et un item « partie »… mais je me trompe peut-être.
Merci de vos retours… et solutions s’il en existe !
Avec un logiciel de rechercher/remplacer qui peut appliquer les changements sur tous les fichiers d’un dossier, ça devrait être possible.
D’après ce que je vois de la structure des deux items, il faudrait :
transformer dk:fragment en dk:part
transformer <dk:fragmentM><sp:title> en <dk:rTitle><sp:rTitle><dk:richTitle><sc:para xml:space="preserve"> (attention je suppose que pour que ce remplacement fonctionne il faudrait que le contenu ne soit pas indenté, c-a-d tout sur une seule méga-ligne).
transformer </sp:title></dk:fragmentM> en </sc:para></dk:richTitle></sp:rTitle></dk:rTitle>
Depuis SCENARI 6 il est possible de paramétrer des conversions d’items dans un wspdef (ou extdef) et ce serait possible techniquement d’implémenter une conversion « fragment <=> partie ».
Par contre faire cela en standard pose des questions :
Un fragment étant un sous-ensemble de partie, la conversion « fragment => partie » est logiquement possible à 100% par contre une conversion « partie => fragment » passera par une perte de contenu potentiel, ce qui n’est pas acceptable.
Si on implémente seulement la conversion « fragment => partie » un auteur ne pourra pas revenir en arrière en cas d’erreur de manipulation, ce qui n’est pas acceptable.
Tous les points d’insertion des l’item seront alors en erreur car même si ils utilisent la même extension .unit, ils ne sont pas interchangeables au niveau structure du modèle, ce qui n’est pas acceptable.
Du coup ce n’est pas une bonne idée d’ajouter cela en standard dans Dokiel.
Reste la proposition de Loïc, de les migrer en dehors de SCENARI :
Si les 900 fragments sont dans un SCENARIserver, les exporter dans un scar
Importer le scar dans un environnement Filesystem temporaire comme SCENARIchain-desktop
Écrire et exécuter une XSL de migration ou effectuer les recherche-remplacer avec un bon éditeur de texte / IDE généralise
Exporter les parties ainsi obtenus dans un scar puis les importer dans SCENARIserver.
Ou alors, développer / faire développer une extension pour vous qui vient ajouter la conversion automatisé mais dangereuse à l’item fragment, qui peut avoir un sens dans votre cas précis mais qui n’est pas souhaitable pour tous les autres utilisateurs de Dokiel.
La question portant sur une erreur de conception « ponctuelle », l’idée n’était pas de suggérer une nouvelle fonctionalité généralisable.
Je vais donc tenter de mettre en oeuvre l’alternative que vous proposez.
J’ai bonne espoir qu’elle résolve mon pb.
Je vous tiens au courant dès que c’est fait.
Merci pour vos explications et consignes très claires, et votre réactivité !