Réaliser un éditeur XML avec SCENARIbuilder

Modélisation de hiérarchie

Réaliser un éditeur correspondant au modèle suivant.

Question

1
Document -> Titre, Section+
2
Section -> Titre, Bloc+
3
Bloc -> sTxt

Indice

Résultat visé (SCENARItest)

Solution

 .wspdef
.model racine (document)

Des items de type compositionPrim sont à créer pour chaque structure composite, à savoir Document et Section ici.

Le modèle de la section est à référencer en allowedModel de la part du document.

Récursivité

Réaliser deux éditeurs correspondant aux deux modèles suivants.

Question

1
Document -> Titre, Section+
2
Section -> Titre, (Section | Texte)+
3
Texte -> sTxt

Indice

Résultat visé (SCENARItest)

Solution

.model Section (mixé)

Le but est de pouvoir ajouter récursivement des sous-sections.

Syntaxe

En Relax NG, la structure (Section | Texte)+ s'écrit :

1
 <oneOrMore>
2
  <choice>
3
    <element name="section">
4
    ...
5
    </element>
6
    <element name="texte">
7
    ...
8
    </element>
9
  </choice>
10
</oneOrMore>

Dans SCENARIbuilder, cela correspond à un set de plusieurs parts :

Set de parts
RemarqueSet optionnel

Pour réaliser l'équivalent d'un zeroOrMore plutôt qu'un oneOrMore, mettre l'attribut usage du set à optional.

Question

1
Document -> Titre, Section+
2
Section -> Titre, (Section+ | Texte+)
3
Texte -> sTxt

Solution

.model Section (alternative)

Le but est de pouvoir ajouter un ensemble de sous-sections ou un ensemble de textes (mais pas les deux à la fois au même niveau).

Syntaxe

En Relax NG, la structure (Section+ | Texte+) s'écrit :

1
<choice>
2
  <oneOrMore>
3
    <element name="section">
4
    ...
5
    </element>
6
  </oneOrMore>
7
  <oneOrMore>
8
    <element name="texte">
9
    ...
10
    </element>
11
  </oneOrMore>
12
</choice>

Dans SCENARIbuilder, cela correspond à une alternative de plusieurs sets :

Alternative de sets
RemarqueName du set dans une alternative

Dans une alternative, le set a besoin d'un name (pour que l'éditeur puisse proposer le choix entre un set ou un autre) : ici, cela fait sens de reprendre les names des parts en les mettant au pluriel.

RemarqueAlternative optionnelle

Pour réaliser l'équivalent d'un zeroOrMore plutôt qu'un oneOrMore, mettre l'attribut usage de l'alternative à optional (un ensemble de sections ou un ensemble de textes ou rien).

Modelet "base"

Copier et modifier les .model sTitle et sTxt dans un nouvel espace, de façon à réaliser un éditeur correspondant au modèle suivant.

Question

1
Document -> Titre, Section+, Glossaire
2
...
3
Glossaire -> Entree+
4
Entree -> Terme, Definition

Avec Terme se comportant comme un sTitle et Definition comme un sTxt encore simplifié comprenant seulement des Paragraphe et des mots de type Emphasis.

Solution

Copier sTxt.model dans l'espace dédié à cette question (on n'a pas besoin de copier sTitle.model avec, car il ne sera pas modifié).

On souhaite garder uniquement les paragraphes et le balisage inline "Important", on va donc tout supprimer sauf :

  • l'appel à la primitive paraTag, de name "Paragraphe" ;

  • l'inlineStyleTag (dans les inlineTags) et l'htmlStyle (dans la partie ) de role "imp" (et de name "Important").

On peut également supprimer les balises devenues "inutiles" dans la partie authoring, à savoir toutes celles n'ayant pas le role "imp".

Il est important de noter le changement de la balise identification ici, sans laquelle on aurait un conflit entre les deux versions de sTxt.model mobilisées dans le modèle (l'originale de base pour les sections, et celle-ci pour les entrées) ; dans cette version modifiée, on doit donc changer :

  • soit le code ;

  • soit le namespace (ce qui est le plus cohérent).

Structure de sTxt

Créer un .model pour l'entrée et bien penser à référencer le sTxt.model modifié en allowedModel de la part.

Structure d'une entrée

Créer un .model pour le glossaire et le référencer en allowedModel dans une nouvelle part de Document.

Structure du glossaire (question 7)

Modelet "binaries"

Réaliser un éditeur permettant l'intégration d'images (binaires externes).

Question

Adapter le modèle Entree pour ajouter des illustrations dans les définitions.

On s'inspirera pour cela de flow.model.

Solution

On a besoin de remplacer sTxt par un modèle plus complexe dans la part de l'entrée, ce qui donne lieu à la création de definition.model.

Il est important de souligner que la part correspondant aux images (png.model, jpeg.model, etc.) ne peut pas avoir son attribut internalized égal à always (les images sont par définition des ressources externes).

Structure d'une définition
Remarque

Il y a plusieurs façons d'interpréter l'énoncé de la question ; ici, on a choisi de pouvoir en mettre un ensemble (optionnellement) à la suite du texte.

Attention

Les .models des images doivent être ajoutés aux publicClasses du wspdef, pour que l'auteur puisse les instancier de manière autonome.

Métadonnées

Utiliser la primitive dataFormPrim pour ajouter à Document les 15 éléments principaux du Dublin Core, comme sur le modèle suivant.

Question

1
Document -> Entete, Section+, Glossaire
2
Entete -> Titre, Créateur, ...
3
...

Solution

Jusqu'à là, on a uniquement utilisé des méta-données de type titlePrim (sTitle) ; le type dataFormPrim permet une structuration plus complexe, ce qui convient bien pour les éléments du Dublin Core.

Créer entete.model de type dataFormPrim et le paramétrer, par exemple, comme ceci :

Structure des méta-données Dublin Core

On remarquera les types proposés pour les champs de méta-données (string, date, etc.)

Remarque

Ici, on s'est servi des balises group (pour grouper plusieurs champs de méta-données sous un nom) et field (champ auquel on peut associer un type), mais la dataFormPrim fournit également :

  • une balise subData pour référencer d'autres dataFormPrim (utile quand on a un modèle de méta-données complexe et/ou requérant des parties externalisées) ;

  • une balise setOf (équivalent d'un set dans la compositionPrim, utile pour pouvoir définir des mots-clés par exemple).

Plan logique

Renseigner les champs family de façon à obtenir le plan adéquat.

Question

Plan logique

Solution

Mettre l'attribut family des parts correspondant aux sections (dans document.model et section.model) à la valeur sub-level : cela permet de spécifier que ces parts sont des éléments structurels (par opposition à des éléments de contenu).

Attribut "family"

Dès lors, dans SCENARIchain (ou SCENARItest), un clic-droit sur un item de type "document", puis "Afficher le plan" doit faire apparaître le plan à droite, sous forme d'arborescence où la racine est le document et les feuilles sont ses différentes sections ou sous-sections.

Externalisation

Autoriser la transclusion entre items sections.

Question

Modifier la propriété d'internalisation de façon à rendre les sections (pas les sous-sections) externalisables et réutilisables si l'utilisateur le décide (userDependent).

Solution

Mettre l'attribut internalized des parts correspondant aux sections à la valeur userDependant : cela laisse le choix à l'auteur d'externaliser une section, ou au contraire de la laisser intégrée au document ou à la section la contenant.

Attribut "userDependant"
Attention

Comme dans la question 8, il faut ajouter section.model aux publicClasses dans le wspdef, pour que l'auteur puisse instancier des items de type "section".

Cette démarche est à faire impérativement, dès lors qu'un item est "externalisable" (concrètement, le choix "Section" sera présent dans le menu de création d'item pour l'auteur).

Déploiement

Préparer le déploiement d'un modèle dans SCENARIchain.

Question

Ajouter un item de type packMake pour générer un wsppack à installer dans SCENARIchain.

Solution

Créer un item de type packMake ("Gestion des ateliers -> Compilation" dans le menu de création d'item) puis référencer le wspDef dans la balise du même nom.

Le résultat de la compilation dans cet item est un fichier .wsppack, qu'on peut installer dans SCENARIchain ensuite.