Système de commentaires

Principe

Le système de commentaires constitue une expérimentation inspirée à la fois des commentaires mobilisés par les outils de bureautique classique et des systèmes de commentaires de code source évoqués dans le chapitre quatre. Leur enjeu est de permettre l'ajout de contenus au sein de n'importe quel fragment, à n'importe quel niveau, quel que soit le modèle. Cette indépendance du modèle permet de construire des fonctions d'exploitation de ces commentaires qui pourront fonctionner de manière universelle quel que soit le modèle.

Le contenu de ces commentaires a pour objet la documentarisation du fragment. Les informations qu'il contient sont donc exclusivement à destination des rédacteurs et des autres usagers intervenant au cours du processus de rédaction (comme par exemple le responsable d'une équipe ou un expert métier). Elles sont expurgées des publications finales des chaînes éditoriales.

Il est possible d'imaginer de multiples usages. Par exemple, l'ajout de commentaires pour négocier le contenu d'un fragment entre rédacteurs, l'ajout d'indications personnelles sur des éléments à revoir ou encore la contextualisation d'un fragment.

Conception

Pour permettre l'ajout de commentaires dans n'importe quel fragment, à n'importe quel niveau, quel que soit le modèle, nous exploitons le principe de commentaire du langage XML. Le XML permet l'ajout de balises de commentaires qui démarrent par les caractères « <!-- » et terminent par les caractères « --> ». Entre ces deux chaînes de caractères, il est possible d'insérer n'importe quel contenu non pris en compte lors des contrôles de validité d'un schéma XML. Nous exploitons ce principe pour insérer du contenu formaté afin d'y enregistrer des fils de discussions entre rédacteurs.

Un fil de discussion est une succession de commentaires. Chaque commentaire a une date de création, de dernière édition, est associé à un usager et dispose d'un contenu. Le fil de discussion peut être ouvert ou clos. La structuration de ces discussions se fait par un formalisme XML. Cela correspond donc à des contenus XML insérés dans les commentaires XML d'un fragment de document. Le schéma de ces fils de discussion est reproduit ci dessous.

1
<?xml version="1.0" encoding="UTF-8"?>
2
<grammar xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
3
    <start>
4
      <element xmlns="http://relaxng.org/ns/structure/1.0" name="comment" ns="scenari.eu:comment:1.0">
5
        <attribute name="type"><value>thread</value></attribute>
6
        <optional><attribute name="threadClosed"><data type="boolean"/></attribute></optional>
7
        <oneOrMore>
8
          <element name="comment">
9
            <optional><attribute name="author"><text/></attribute></optional>
10
            <attribute name="creationTime"><data type="positiveInteger "/></attribute>
11
            <optional>
12
              <attribute name="updateTime"><data type="positiveInteger "/></attribute>
13
              <attribute name="updateBy"><text/></attribute>
14
            </optional>
15
            <text/>
16
          </element>
17
        </oneOrMore>
18
      </element>
19
    </start>
20
</grammar>

Les fils de discussion sont directement insérables à n'importe quel niveau dans l'éditeur XML de Scenari.

Figure 51 : éditeur Scenari - affichage des commentaires

La figure 51 est une vue de l'éditeur Scenari. Le code XML correspondant au fragment commenté est visible dans l'encadré ci-dessous.

1
<sc:item xmlns:sc="http://www.utc.fr/ics/scenari/v3/core">
2
	<op:courseUa xmlns:sp="http://www.utc.fr/ics/scenari/v3/primitive" xmlns:op="utc.fr:ics/opale3">
3
		<op:uM>
4
			<sp:title>HTTP</sp:title>
5
		</op:uM>
6
		<sp:intro>
7
			<op:res>
8
<!--<comment xmlns="scenari.eu:comment:1.0" type="thread">
9
  <comment author="Fred" creationTime="1391600612399" updateTime="1405617354829" updateBy="Arthur">
10
    On pourrait nomdmer les RFC et donner les URLs vers les pages de l'ietf. Il faut que les étudiants  prennent l'habitude d'aller regarder le standard quand ils ont un doute.
11
  </comment>
12
  <comment author="Georges" creationTime="1399830009263">
13
    Ok, je suis d'accord.
14
    Donc, un lien vers les RFC 1945, 2068 et 2616 ?
15
  </comment>
16
  <comment author="Fred" creationTime="1402830904557">
17
    Attention, l'IETF vient de publier une mise à jour des RFC HTTP.
18
    Il y a maintenant 8 RFC décrivant l'ensemble de HTTP 1.1 (de la 7230 à la 7237).
19
  </comment>
20
  <comment author="Georges" creationTime="1402830960289">Oui, vu. je mettrai ce paragraphe à jour.</comment>
21
</comment>-->
22
<				sp:txt>
23
					<op:txt>
24
						<sc:para xml:space="preserve" sc:id="t3">HTTP est un protocole de la couche application destiné à assurer les échanges entre un serveur et un client dans l'Internet.</sc:para>
25
					</op:txt>
26
				</sp:txt>
27
				<sp:res sc:refUri="id:02stG2z2raTCqMTeW6ps9k">
28
					<op:resInfoM/>
29
				</sp:res>
30
				<sp:txt>
31
					<op:txt>
32
						<sc:para xml:space="preserve" sc:id="t6">Le protocole HTTP, normalisé par des RFC, a été défini en trois versions. La version 0.9 est le protocole défini à l'origine par Tim Berners-Lee (l'idéateur du WEB). La version 1.0 apporte de très nombreuses fonctionnalités (typage des documents, codage du contenu, identification, ...). La dernière, la version 1.1, est la plus avancée et permet de réaliser différentes négociations, mais surtout d'obtenir des sessions persistantes.</sc:para>
33
					</op:txt>
34
				</sp:txt>
35
			</op:res>
36
		</sp:intro>
37
		<sp:courseUc sc:refUri="id:02utG2z2raTCqMTeW6ps9k"/>
38
		<sp:courseUc sc:refUri="id:02vtG2z2raTCqMTeW6ps9k"/>
39
		<sp:courseUc sc:refUri="id:02wtG2z2raTCqMTeW6ps9k"/>
40
		<sp:courseUc sc:refUri="id:02xtG2z2raTCqMTeW6ps9k"/>
41
	</op:courseUa>
42
</sc:item>

Publication, édition et indépendance du modèle

Sans aucun moyen de publier les commentaires en dehors de l'interface d'édition de la chaîne éditoriale, le système de commentaires reste assez neutre quant à la possibilité de véritablement documentariser l'activité sur les fragments, soit de créer sa documentation. Une seconde exploitation des commentaires réside dans leur publication.

Les chaînes éditoriales peuvent permettre la génération de publications statiques (les documents sont générés puis copiés par les usagers pour un usage externe au logiciel) ou dynamique (les documents sont générés à chaque demande de l'usager). Cette différence technique est assimilable aux vues (pour les publications dynamiques) et aux vues matérialisées (pour les publications statiques) des bases de données. En produisant à la volée chaque page HTML, une chaîne éditoriale se comporte comme un serveur web classique.

Le principe de la publication dynamique et l'indépendance du modèle permettent de concevoir de nouvelles modalités d'édition des fragments à moindre coût. Le lien dynamique permet d'avoir constamment une version à jour d'un document transformé au sein d'un navigateur tandis que l'indépendance du modèle permet de concevoir un service d'édition des commentaires sans étendre la mécanique de génération et d'interprétation des modèles documentaires à de nouvelles composantes des chaînes éditoriales.

Ainsi, l'indépendance du modèle nous permet de développer un service de visualisation et d'édition des commentaires au sein des publications HTML dynamiques. Cette expérimentation permet d'étudier à moindre coût l'opportunité de sortir une partie de la gestion de la production documentaire des interfaces graphiques des chaînes éditoriales et de leur complexité d'usage dans l'objectif de la déporter dans un navigateur web sur des documents HTML classiques. En fonction des retours des contextes d'usage, cette expérimentation pourrait gagner à être étendue à la gestion de l'ensemble des fragments pragmatiques.

Problèmes techniques

Un tel projet de publication pose plusieurs problèmes techniques.

  • Lorsqu'un usager commente un élément HTML, il s'attend à ce que son commentaire soit attaché à l'élément XML du fragment mobilisé pour générer l'élément HTML. Il est donc nécessaire de développer un système d'adressage d'un fragment et des éléments XML au sein de ce fragment depuis la publication HTML.

  • De nouvelles modalités d'édition des fragments posent la question de la synchronisation du document HTML visualisé. Si le contenu d'une publication dynamique est modifié au sein de la chaîne éditoriale, cela peut remettre en cause à la fois la validité technique des liens entre élément HTML et élément XML ainsi que la validité du contenu du commentaire (le contenu commenté ayant pu évoluer).

  • Proposer un document HTML à commenter dont l'usage édite directement les fragments au sein de la chaîne éditoriale nécessite de penser le comportement du système lors d'une édition simultanée par plusieurs usagers différents.

Les détails de la conception et le traitement de ces trois contraintes sont décrits dans l'annexe dédié à notre contribution technique.