ZEP-27 : identifier les éléments d'un extrait

Aujourd'hui, la partie la plus atomique d'un contenu¹ est l'extrait. Cela signifie qu'il n'est pas possible de facilement faire référence à un élément plus petit qu'un extrait (titre, paragraphe, phrase, mot…). Il pourrait être intéressant, pour prendre des notes, signaler une erreur… de pouvoir pointer vers des parties plus précises d'un contenu.

Pousser la granularité au niveau de la phrase ou du mot semble utopique et non nécessaire. Par contre, s'arrêter aux paragraphes est un bon compromis entre la précision à outrance et celle faible des extraits. Contrairement à ces derniers, un paragraphe ne se verrait pas accorder une url, mais simplement un index pour générer une ancre : .../extrait#index.

Néanmoins, il pourrait être intéressant de ne pas restreindre ce système aux paragraphes. Les éléments suivants, par la suite appelés « éléments », pourraient être référencés :

• Les paragraphes textuels
• Les blocs (information, secret…)
• Les citations
• Les morceaux de code
• Les images
• Les vidéos
• Les listes
• Les titres

Certains de ces éléments devraient peut-être être intégrés dans le paragraphe textuel les prédédant. Par exemple :

1
2
3
4
5
6

Je suis un paragraphe.

* Je
* suis
* une
* liste

au lieu de

1

Je suis un paragraphe.

1
2
3
4

* Je
* suis
* une
* liste

Exemples d'application

Une identification aussi précise permettrait de faire moult choses :

• Diriger un membre vers un endroit précis d'un extrait
• Signaler une faute à un endroit précis d'un extrait
• Déplacer un élément d'un extrait vers un autre extrait
• Générer des résumés (cf : fiches de révision) : ne conserver que certains éléments d'un tutoriel
• Attacher des notes à un point précis d'un extrait

L'identification

Oui mais on ne peut identifier les paragraphes juste à partir du markdown. Par exemple, si je fournis le markdown

1
2
3

abcd

efgh

j'obtiendrais

1
2
3
4
5
6
7
8

<a href="#p-0">P0</a>
<p>
abcd
</p>
<a href="#p-1">P1</a>
<p>
efgh
</p>

Mais que se passe-t-il si je mets à jour mon extrait avec

1
2
3
4
5

abcd

ijkl

efgh

Je ne vois pas comment le parseur pourrait me retourner autre chose que

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<a href="#p-0">P0</a>
<p>
abcd
</p>
<a href="#p-1">P1</a>
<p>
ijkl
</p>
<a href="#p-2">P2</a>
<p>
efgh
</p>

Mais, du coup, l'ancre du paragraphe efgh a changé. J'aurais préféré :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<a href="#p-0">P0</a>
<p>
abcd
</p>
<a href="#p-2">P2</a>
<p>
ijkl
</p>
<a href="#p-1">P1</a>
<p>
efgh
</p>

Donc la seule solution me semble de faire comme on fait pour distinguer les extraits : des textareas séparés, un par paragraphe, avec un index par textarea. Cela permettra de plus aux auteurs de supprimer un paragraphe, d'en déplacer… Bref, de faire tout ce qu'on peut faire avec un extrait, mais avec des paragraphes.

L'indexation

L'indexation serait basé sur le modèle des clés primaires d'une table dans une base de données.

Le stockage

• Un extrait = un dossier
• Un élément = un fichier markdown index.md
• L'ordre des éléments serait indiqué dans le manifest.json

L'UI

TODO

Merci.

Alors je pense qu'il ne faut pas se restreindre aux paragraphes mais à tous les types de blocs possibles (liste, paragraphe, bloc de code, citation, etc.). C'est le premier point. Dans tous les parseurs markdown il y a cette notion de bloc.

Ensuite je ne pense pas que l'interet principal soit de placer des ancres. Les ancres seront utiles juste après les titres mais c'est un autre problème. Pour beaucoup d'utilisation possible il suffit simplement que chaque bloc ai un identifiant unique (un paramètre id=truc) qui permet au front de l'identifier. Ainsi le front pourra proposer à l'utilisateur un bouton "modifier" a coté de chacun de ceux-ci et on pourra savoir à quel morceau cela correspond.

Identifier un bloc est différent de poser une ancre dessus. L'ancre, comme tu le propose, possède effectivement un problème : on peut être tenté de les utilisés comme cible de lien. Il faut alors assurer un minimum de suivi. Il y aurait certaines possibilités pour limiter la casse mais je pense sincèrement que ce n'est pas la solution.

Enfin je ne suis pas surs de la pertinence de ce sujet comme ZEP. Là on va discuter d'une implémentation général d'un élément. Personnellement je pense que ça peut dépendre du contexte. Il y a pour moi plusieurs problèmes séparés. Identifier les blocs de façon unique en est un. Avoir le liens avec le markdown de ces blocs en est un autre, avoir des ancres en est un troisième. Chacun à des problèmes et des solutions différentes. Typiquement je préfère clairement des ZEP fonctionnel comme celle-ci. Dans un tel cas on sait quel va être la finalité et on va adapter la solution.

Au passage pour toutes ces infos, il reste deux dépendances fortes :

• que la ZEP-5 avance (donc on a encore le temps d'en discuter)
• Qu'on se pose la question si on veut identifier uniquement les blocs de premiers niveau, ceux de dernier niveaux ou tous récursivement (ex: un extrait contient un spoiler qui contient 2 paragraphes, tu identifie uniquement le spoiler, uniquement les paragraphes intérieurs ou tu identifie les 3 ?)

Du coup, comme dit en MP, j'ignore un peu quoi faire. Quelle est la visée de cette ZEP, si toutefois ZEP il y a lieu d'être ?

A la base, je voulais introduire la notion d'ancre pour qu'il soit possible de pointer des passages précis, que ce soit en y faisant référence sur le forum, depuis un autre tutoriel… Le problème étant qu'on aurait des références fixes (les urls) vers des objets mutables (les paragraphes, listes…).

Du coup, que fait-on ?

Merci !

Si on veut faire des références entre tuto on peut imaginer une extension de la syntaxe des liens pour faire des références entre documents sur zds. Typiquement au lieu de mettre l'URL tu mettrai le PK et le path dans la table des matière