Réflexions sur une DTD pour plugin.xml - commentaires

Réflexions sur une DTD pour plugin.xml

Ce serait intéressant de rajouter une balise (ou ) à la DTD, en plus de . Même si ce n'est pas utilisé immédiatement, l'idée serait d'y récupérer automatiquement, à terme, le numéro de la dernière révision SVN pour les plugins développés sur spip-zone.

Premier lot de remarques sur la structure

J'adhère pas à tout mais il y a encore quelques incompréhensions vis-à-vis de ma modélisation SVP.

...il arrive souvent qu'on distingue différentes versions en modernisant le logo. On peut éventuellement le mettre au deux, le premier étant une valeur par défaut.

Ouais bof, je suis plutôt d'avis que le logo doit rester identique pour conserver un repère visuel. C'est pour la même raison que je ne trouve pas judicieux de traduire le nom d'un plugin.

En revanche, je ne comprends pas ton exigence que chaque paquet reproduise telles quelles les informations du plugin...

Je ne parle pas à l'intérieur d'un même fichier XML mais entre deux fichiers XML définissant une branche différente d'un même plugin. La modélisation de SVP part du principe :

Un plugin a une ensemble de caractéristiques intangibles : préfixe, nom, slogan, logo, catégorie, tags
Un plugin est distribué sous différents paquets, mais chaque paquet possède les mêmes caractéristiques du plugin.

Donc à ce titre, je souhaitais que le bloc d'informations du plugin soit bien identifié dans la DTD, donc dans le fichier XML.

Je ne comprends pas non plus l'introduction des balises « nom » et « slogan » qui ne correspondent pas à ce que tu décris dans ton article 1 car ici elles paraissent redondantes respectivement avec l'attribut ID et la balise « description ».

Si si ça correspond exactement à la modélisation SVP. Ben le nom c'est « Association », « Accès restreint »... Je n'avais pas vu ton id mais je ne crois pas que le nom soit la bonne information à mettre en id dans ce cas : le préfixe serait plus adapté et donc il faut bien une balise nom.

Pour le slogan c'est ce que j'ai expliqué : une description courte et pertinente qui perdure pour le plugin indépendamment de son évolution. La description est plus au niveau du paquet car elle peut inclure les modifications fonctionnelles apportées.

...il faudrait renommer l'actuelle balise « description » de ma DTD par « slogan », et rajouter une balise « description » au niveau de chaque paquet,...

...Quant au nom du fichier, c'est tout de même gênant qu'il se nomme « paquet » sans S s'il en décrit plusieurs...

Alors là c'est un autre sujet qu'on a pas encore abordé et c'est pour cela que dans l'article sur les règles j'ai fait trois groupes d'informations : plugin, paquet et autres.

Un fichier paquet.xml (sans s !) génère bien qu'un seul paquet physique. Quand on a deux blocs à l'intérieur c'est pour que le même paquet fonctionne avec deux versions de SPIP différentes (en général).

Regarde par exemple le plugin.xml de Fancybox à cette adresse : http://zone.spip.org/trac/spip-zone/browser/_plugins_/fancybox/plugin.xml, il a deux blocs nommés et . Par contre, on peut noter dans ce cas que beaucoup d'informations sont inutilement redondantes, celles de l'entité plugin de SVP, mais d'autres aussi comme la version SPIP dans balise plugin et dans le neccesite, alors que seuls le chemin et la version sont dans ce cas différents.

Je peux même te dire que je ne traite pas ce cas correctement dans SVP car j'associe l'archive au paquet alors que pour Fancybox l'archive supporte deux paquets ! La page du plugin ne fait donc état que du paquet de version 0.4. Donc je crois qu'il faut encore travailler la structure de la DTD pour faire apparaître plus clairement les différents blocs.

Donc conclusion provisoire, on parlera des tags plus tard, je proposerais la DTD suivante :

Premier lot de remarques sur la structure

Il y a effectivement deux notions, le plugin et le paquet, mais il suffit a priori de deux balises, je ne vois pas l'intérêt d'en avoir 3, a fortiori en nommant « spip-paquet » (sans S final) une balise regroupant plusieurs balises « paquet ». Ma proposition a donc comme premier défaut de nommer « plugin » une balise qui aurait dû s'appeler « paquet ». Le deuxième défaut est effectivement d'avoir mis au niveau « paquet » des informations intangibles du plugin, savoir le préfixe et la catégorie, et éventuellement le logo mais c'est moins sûr : il arrive souvent qu'on distingue différentes versions en modernisant le logo. On peut éventuellement le mettre au deux, le premier étant une valeur par défaut.

En revanche, je ne comprends pas ton exigence que chaque paquet reproduise telles quelles les informations du plugin : il vaut mieux les mettre une fois pour toutes au niveau de la balise décrivant le plugin, et d'ailleurs dans ta DTD tu ne le fais heureusement pas !

Je ne comprends pas non plus l'introduction des balises « nom » et « slogan » qui ne correspondent pas à ce que tu décris dans ton article 1 car ici elles paraissent redondantes respectivement avec l'attribut ID et la balise « description ». Si je suis ton article, il faudrait renommer l'actuelle balise « description » de ma DTD par « slogan », et rajouter une balise « description » au niveau de chaque paquet, ce qui se défend (je pensais plutôt que la description était intangible, mais on peut effectivement la voir comme description des nouveautés). Quant à id_plugin dans ton article il évoque plutôt un clé numérique primaire SQL, autrement dit une information interne qui n'a pas à apparaître dans la DTD a priori.

Pour les tags, ta DTD les mentionne comme ID mais ce n'est pas possible à cause des répétitions éventuelles. De plus, ce n'est pas clair pour moi si
ça ne devrait pas plutôt être mis au niveau du paquet : il arrive qu'un plugin abandonne un gros bout de code en délégant la fonctionnalité à un autre plugin dont il exige alors la nécessité, et alors les tags repérant cette fonctionnalité ne seront plus d'actualité pour les paquets qui suivront. J'aurais besoin de plus d'informations sur leur rôle pour me faire une idée, pour l'instant je continue à les ignorer.

Quant au nom du fichier, c'est tout de même gênant qu'il se nomme « paquet » sans S s'il en décrit plusieurs. Dans ma DTD je prend comme balise racine « spip-plugin » parce que je crois important que le nom SPIP apparaisse dedans, pourquoi ne pas nommer le fichier « spip-plugin.xml » ?

Je modifie donc ma DTD ci-dessus en remplaçant les deux éléments « spip-plugin » et « plugin » par les trois suivants :

Premier lot de remarques sur la structure

Voici un premier lot de remarques uniquement liées à la structure générale du fichier.

Le nom du fichier : je rappelle la proposition faite sur la liste, paquet.xml.

Dans l'article SVP, objectifs et mise en oeuvre je modélise les deux notions de plugin et paquet en donnant la liste des informations constitutives de l'une et l'autre. Dans l'article Développement de SVP v0, je précise que les informations propres au plugin doivent être uniques et reproduites telles quelles de paquet en paquet.

Donc je proposerais que la DTD du fichier XML instaure cette distinction entre plugin et paquet afin que les développeurs identifie rapidement le bloc plugin à ne pas modifier. Ca pourrait donner ceci :

J'espère que j'ai pas fait d'erreurs d'écriture mais rien n'est moins sur....