Conception des chaînes éditoriales

La mise en place d'un fragment proxy constitue un lien entre deux fragments issus d'atelier différents. Il n'y a aucune contrainte pour multiplier les proxys entre deux ateliers.

Sur la figure 88, l'atelier second met en place trois proxys vers des fragments issus d'un même atelier premier (X1, X2 et X6).

Cette multiplication peut poser problème lorsqu'un même fragment se retrouve proxié à travers deux liens proxys différents. En reprenant l'exemple illustré sur la figure 88, la question se pose lorsque les fragments X0 et X5 sont tous les deux liés comme fragment proxy. Deux comportement sont possibles pour les fragments doublement proxyés (soit X2, X3 et X4, le sous-graphe commun à X0 et X5) : la mutualisation des fragments (le sous-graphe X2, X3 et X4 est mutualisé par X0 et X5 dans l'atelier second) ou leur duplication (le sous-graphe X2, X3 et X4 est importé deux fois et les proxys X0 et X5 de l'atelier second référence chacun une version différente).

La solution la plus logique consiste à différencier le comportement en fonction de la direction du projet de rééditorialisation. Lorsqu'un projet de rééditorialisation est convergent, les fragments sont référencés dans l'atelier second avec le même identifiant que celui utilisé dans l'atelier premier. Il n'est donc pas possible de multiplier les versions d'un même fragment. En revanche lorsque le projet de rééditorialisation est divergent, un nouvel identifiant est créé pour le contexte de l'atelier second. Chaque fragment dispose ainsi d'un nouvel identifiant ce qui permet de créer plusieurs versions liées à un même fragment d'origine.

Ainsi, lorsque deux proxys convergents sont mis en place, l'atelier second mutualise les fragments selon les mêmes modalités que l'atelier premier.

Cette solution est fonctionnelle mais pose problème dans le cas où plusieurs fonctions de proxy convergentes seraient implémentées. Il est alors nécessaire de restreindre l'ensemble des fonctions de proxys convergentes entre deux ateliers à une seule et même implémentation. Le cas échéant, un même fragment issu de deux sous-graphes distincts importés par deux proxys différents exploitant deux fonctions de rééditorialisation différentes se retrouverait en conflit. Concrètement, si les deux fonctions de rééditorialisation prévoient deux méthodes différentes pour afficher l'état d'un fragment (surchargé ou identique à la source) et deux méthodes différentes pour reverser une modification locale dans le fragment original, il ne sera pas possible de déterminer quelles méthodes utiliser.

Un tel problème disparaît avec des proxys divergents car la multiplication des fragments proxys duplique les fragments proxiés plusieurs fois comme illustré sur la figure 90.

Sans problèmes d'identifiants, il est possible de faire plusieurs liens proxys vers un même fragment (à partir d'une ou de plusieurs fonctions de rééditorialisation différentes, comme une traduction et une dérivation plus générique). Par exemple, la multiplication des liens peut outiller l'exemple de la documentation multilingue avec uniquement deux ateliers. Un atelier premier serait utilisé pour écrire la documentation de référence. Un atelier second ferait quatre liens proxys vers cette documentation pour permettre les quatre traductions. La scénarisation et la publication du document multilingue seraient également réalisées dans l'atelier second.