Gontran a écrit :
Salut à tous,
J'ai revu ma copie concernant la structure du fichier infos au format XML, le
but étant d'avoir une structure cohérente tout au long du fichier et des noms
de balises le plus explicite possible par rapport à leur contexte
d'utilisation. Voici le résultat, dites-moi si les noms des balises sont bien
intuitifs pour deviner leur rôle :
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE npkg SYSTEM "NasgaiaPackage.dtd">
<npkg version="3.0">
<project>
<version>1.0</version>
<license>GPL</license>
<author>Me</author>
<copyrights>none</copyrights>
<homepage>http://www.project.org/</homepage>
<resources>
<file name="project-1.0.tgz"
checksum="442fed534043a8d66976bdfd7b80eedf">
<location>ftp://ftp.project.org/download</location>
<location>http://http.project.org/download</location>
</file>
</resources>
<domain>
<descriptor>/kind/application</descriptor>
<descriptor>/interface/text/command-line</descriptor>
<descriptor>/topic/system/console/terminal</descriptor>
<descriptor>/audience/end-user</descriptor>
</domain>
<purpose lang="en">
<summary>A full-featured text editor.</summary>
<description>here is the full description of the
software.</description>
</purpose>
<purpose lang="fr">
<summary>Un éditeur de texte avancé.</summary>
<description>Voici la description complète du
logiciel</description>
</purpose>
</project>
<package>
<release>1</release>
<maintainer>
<name>Gontran</name>
<email>[EMAIL PROTECTED]</email>
</maintainer>
<history>
<release version="1.0-nga1" author="Gontran
<[EMAIL PROTECTED]>"
object="pkg-bugfix" date="2005-07-08T18:03:00Z">
- first release of the stable version.
</release>
</history>
</package>
</npkg>
Les changements par rapport à ma précédente proposition concernent :
- l'ajout de l'attribut version à la balise racine npkg pour indiquer la
version de Ncooker pour laquelle le paquet est conçu ;
- j'ai utilisé le nom plus général de ressources pour désigner les fichiers du
projets. Une ressource est un fichier qui sera le plus souvent une archive
source, mais qui pourrait très bien être un fichier d'une tout autre nature.
- domain indique le domaine applicatif/fonctionnel du projet, et j'ai remplacé
la balise node par la balise descriptor, dont le contenu décrit une
caractéristique de ce domaine.
- J'ai placé la release du paquet comme contenu d'une balise plutôt que valeur
d'attribut de la balise package. Ça permet de suivre la même logique que la
balise version pour project.
- De même les attributs de la balise maintainer ont été transformés en
balises.
- la balise changelog a été renommée en history, et l'attribut purpose de la
balise release a été renommé en object. Pour les mots-clés utilisable avec
cet attribut, je propose :
. app-bugfixes : correction de bogues dans le projet
. app-securityfixes : élimination de failles de sécurité dans le projet
. app-features : amélioration (ou nouvelle version) du projet
. pkg-bugfixes : correction de bogues dans le paquet (dans le fichier infos
ou build)
. pkg-securityfixes : élimination de failles de sécurité dans le paquet
. pkg-features : amélioration du paquet
L'attribut object peut contenir plusieurs mots-clés séparés par des espaces.
Voilà. Remarques, avis, critiques bienvenus ;-)
Ça me va. Par contre je préfére "changelog" à "history" comme balise, ça
me semble plus
parlant pour désigner la liste des changements effectués.
voilà mes deux centimes,
++
