Serge NOEL
506 lines
26 KiB
Plaintext
506 lines
26 KiB
Plaintext
<!DOCTYPE html>
|
|
<html lang="fr">
|
|
<!-- Updatedated by Blorec Hervé 2016-08-20-->
|
|
<head>
|
|
<title>JMRI: Xml Schema Examples</title>
|
|
<meta name="author" content="Bob Jacobsen">
|
|
<meta name="keywords" content="JMRI technical code xml schema usage">
|
|
<!--#include virtual="/help/fr/parts/Style.shtml" -->
|
|
</head>
|
|
|
|
<body>
|
|
<!--#include virtual="/help/fr/parts/Header_fr.shtml" -->
|
|
<div id="mBody">
|
|
<!--#include virtual="Sidebar.shtml" -->
|
|
<div id="mainContent">
|
|
<!-- Page Body -->
|
|
|
|
<h1> JMRI: Utilisation de Schema XML</h1>
|
|
|
|
<p>JMRI utilise XML pour un certains nombres ce but:
|
|
organiser les définitions de décodeur, pour ses
|
|
<a href="XmlPersistance.shtml">système de rémanence</a>
|
|
pour la configuration et panneau d'information,
|
|
et pour créer des parties du site web depuis d'autres fichiers.
|
|
Cette page décrit comment nous spécifions le
|
|
contenu de ces fichiers par l'utilisation de
|
|
<a href="http://www.w3schools.com/schema/schema_intro.asp">schema XML</a>.</p>
|
|
|
|
<p>
|
|
Par exemples sur la structure de
|
|
notre schéma, voir la
|
|
<a href="XmlSchemaExamples.shtml">page d'exemples</a>.
|
|
|
|
<p>
|
|
Le schema actuel peut être vue en ligne dans le
|
|
<a href="http://jmri.org/xml/schema">répertoire schema</a>.
|
|
Le plus couramment utilisé est le
|
|
<a href="http://jmri.org/xml/schema/layout.xsd">schema pour les fichiers de panneaux layout.xsd</a>.
|
|
Voir ci-dessous comment ils sont organisés.
|
|
|
|
<h2>Accès aux Définitions de Schéma</h2>
|
|
JMRI utilise le Schema XML pour définir le format de ses fichiers.
|
|
<p>
|
|
Ces Schémas XML peuvent avoir besoin d'être disponibles pour le programme quand il
|
|
lit les fichiers, car ils définissent les valeurs par défaut des attributs manquants
|
|
et autre information nécessaire.
|
|
<p>
|
|
Dans les distributions JMRI, Ils sont stockés dans le
|
|
répertoire <a href="/xml/schema ">xml/schema </a>
|
|
Notez qu'ils ne sont pas stockés dans chaque répertoire
|
|
à côté des fichiers XML. Il y a tout simplement de trop nombreux
|
|
endroits pour garder un tel ensemble de fichiers de définition de schema à jour.
|
|
JMRI lui-même, via la classe jmri.jmrit.XmlFile, fournit
|
|
le support pour localiser ces fichiers quand l'analyseur XML
|
|
a besoin d'eux.
|
|
</p>
|
|
|
|
<h2 id="modschema ">Modification de Schema JMRI</h2>
|
|
|
|
Cette section explique comment gérer de tous petits changements dans un schema existant,
|
|
par exemple, ajouter ou enlever un attribut ou un élément. Pour des changements
|
|
plus important, incluant la création entière de nouveaux types ou nouveaux formats de fichier,
|
|
voir la section suivante sur le "<a href="#devschema ">Développement de Schema JMRI</a>".
|
|
<p>
|
|
Chaque fois que vous changez ce que JMRI écrit ( et donc lit ) dans un fichier XML,
|
|
Il y a des choses que vous devez faire.
|
|
<ol>
|
|
<li>Vous devez changez le code qui fait la lecture et l'écriture.
|
|
<li>Vous avez besoin de modifier les fichiers de schema , de sorte que le format XML peut
|
|
être correctement vérifié.
|
|
<li>Vous devez fournir de nouveaux fichiers de test XML pour vous assurer que rien n'a été brisé,
|
|
et dans certains cas avoir à ajuster les anciens.
|
|
</ol>
|
|
<p>
|
|
SVP ne sautez pas les étapes suivantes. Ils ont matière à une
|
|
stabilité à long terme du code JMRI.
|
|
|
|
<p>
|
|
Si possible, il vaut mieux faire les changements par ajout, pour que
|
|
les fichiers existants puissent continuer à être lu inchangé.
|
|
JMRI valorise fortement la compatibilité ascendante, où une version plus récente
|
|
de JMRI peut encore charger et utiliser un fichier écrit par une ancienne version.
|
|
|
|
<p>
|
|
Si vous pouvez faire un changement qui est juste un ajout, alors le processus est:
|
|
<ol>
|
|
<li>Changez votre code
|
|
<li>Ajoutez les nouveaux éléments et attributs
|
|
à la version la plus récente du fichier de schema .
|
|
<li>Exécutez "ant headlesstest" pour être sûr que les anciens fichiers,
|
|
toujours présents dans le test peuvent encore être traités. Réparer
|
|
tout ce qui cassé. ( Vous pouvez découvrir à ce
|
|
moment que vous ne faites pas actuellement un changement
|
|
rétro-compatible, auquel cas soit vous le corrigez ou voir plus bas
|
|
la section sur la "<a href="#versioning">Gestion des versions de Schema </a>" ).
|
|
<li>Créez un fichier test avec le nouveau contenu. Idéalement, cela
|
|
ne nécessitera pas l'utilisation de l'écran, il peut effectivement
|
|
être chargé et stocké dans le cadre de headlesstest.
|
|
Dans ce cas, mettez votre fichier dans un sous-répertoire test "load"
|
|
( voir ci-dessous ). Au minimum, cependant, mettre votre fichier
|
|
dans un sous-répertoire test "verify" afin que vos
|
|
modifications du schema soient testées.
|
|
Pour plus d'infos, voir <a href="#test">ci-dessous</a></li>
|
|
</ol>
|
|
|
|
|
|
<h3><a id="versioning">Gestion de Version de Schéma</a></h3>
|
|
|
|
La "gestion de Version" de Schema nous permet d'avoir différents fichiers
|
|
de schema du plus ancien au plus récent. Ceci laisse les nouvelles versions de JMRI
|
|
de continuer à vérifier et lire les fichiers
|
|
qui ont été écrits par des anciennes versions de JMRI.
|
|
Cette rétro-compatibilité est une caractéristique importante de JMRI
|
|
que nous ne devons pas perdre.
|
|
<p>
|
|
En pratique, La "gestion de Version" consiste à avoir de multiples versions mais relatives
|
|
de versions des fichiers de définition de schema qui sont étiquettées par la
|
|
première version JMRI qui peut les lire.
|
|
<p>
|
|
Quand avez vous besoin de créer une nouvelle version?</p>
|
|
<ul>
|
|
<li>
|
|
vous <em>n'avez pas</em> besoin
|
|
de créer une nouvelle version de schema , si vous ajoutez ou changez quelque chose tel
|
|
que des fichiers existants qui continueront à être validés.
|
|
<p>
|
|
Dans ce cas, Faites juste votre changement de schema dans
|
|
le document schema courant, et soumettez de les ramener au répertoire de code JMRI.
|
|
<li>Vous <em>avez</em> besoin de
|
|
la version d'un schema où vous faites un changement dans le
|
|
le schema de telle sorte que les fichiers précédents ne seront plus valider
|
|
avec le schema actuel.
|
|
<p>
|
|
Dans ce cas, les étapes vers la version du schema sont:
|
|
<ol>
|
|
<li>Copiez le fichier du schema actuel vers un nouveau avec
|
|
le numéro de la version JMRI <em>suivante</em>. Exemple:
|
|
Copiez types/turnouts-2-9-6.xsd vers types/turnouts-3.7.3.xsd
|
|
si vous faites ceci avant que JMRI 3.7.3 soit publié.
|
|
Faites vos changements et soumettez cette nouvelle version.
|
|
<li>Si c'est un sous-fichier, tel que le types/turnouts-2-9-6.xsd,
|
|
qui est inclus dans un schema principal comme layout-2-9-6.xsd,
|
|
ce fichier principal doit également être copié, avoir les changement
|
|
inclus, et soumis.
|
|
Vous avez obtenu
|
|
un nouveau schema layout-3-7-3.xsd pour les fichiers de sortie de référence.
|
|
<li>Puis, changez le code Java qui écrit la
|
|
référence schema en haut des fichier de sorties
|
|
pour utiliser le nouveau Filname. Par exemple, les fichiers réseau
|
|
(panneau ) sont écrit par
|
|
<code>src/jmri/configurexml/ConfigXmlManager.java</code>.
|
|
Regarder la ligne
|
|
<br><code>static final public String schema Version = "-3-7-3"</code><br>
|
|
et changez par votre nouveau numéro de suffixe de version.
|
|
<li>S'il y a une stylesheet(s) XML
|
|
associée, ses noms doivent être changés d'une manière coordonnée.
|
|
( Vous devrez aussi actualiser la stylesheet pour montrer votre nouveau
|
|
contenu XML, naturellement ).
|
|
</ol>
|
|
</ul>
|
|
|
|
Dans les deux cas, il est important d'inclure suffisamment de
|
|
fichiers de test pour que les tests unitaires capturent les problèmes avec le nouveau
|
|
et l'ancien schéma. Voir la
|
|
section d'essai <a href="#test"> ci-dessous </a>.
|
|
|
|
<p>Notez que le schema non libellé est le schema primordial, le plus ancien et désormais
|
|
obsolète. Par exemple layout.xsd est <em>plus vieux</em> que layout-2-9-6.xsd, et
|
|
donc ne doit plus être utilisé pour les nouveaux fichiers. Ne supposez pas que
|
|
layout.xsd est la valeur par défaut pour les nouveaux fichiers!
|
|
|
|
<h2>Vérification de Shema JMRI</h2>
|
|
|
|
Il est important que les définitions shema JMRI conserve une sémantique
|
|
correcte.
|
|
Si nous laissons trop de problèmes s'accumuler,
|
|
nous allons finalement avoir beaucoup de correction à faire.
|
|
L'outil W3C en ligne
|
|
<a href="http://www.w3.org/2001/03/webdata/xsv">outil de validation de schéma</a>
|
|
est un excellent outil pour vérifier que les changements de schema JMRI sont encore techniquement
|
|
corrects. Vous devez verifiez vos changements avec lui avant de les soumettre au répertoire.
|
|
Malheureusement, il ne semble pas vérifier la conformité avec les éléments de schema imbriqués,
|
|
exemple depuis DocBook ( voir ci-dessous ) ou schema JMRI,
|
|
mais il est encore un contrôle très utile.
|
|
|
|
<p>
|
|
L'utilisation de l'outil JMRI "Validate XML File" dans le menu "Debug" pour
|
|
valider un fichier .xml ( "instance file" ) qui utilise votre schema nouveau ou
|
|
réactualisé est une vérification importante des deux. Utlisez le souvent pendant
|
|
le développement. Vous pouvez aussi l'utiliser depuis les lignes de commande via ex:
|
|
<code>
|
|
./runtest.csh apps/jmrit/XmlFileValidateRunner xml/decoders/0NMRA.xml
|
|
</code>
|
|
|
|
<p>
|
|
Pour une vérification rapide de fichier, les utilisateurs Linux et Mac OS X peuvent valider depuis
|
|
la ligne de commande avec ex:
|
|
<code>
|
|
cd xml
|
|
xmllint -schema schema /aspecttable.xsd -noout signals/sample-aspects.xml
|
|
</code>
|
|
<code>xmllint</code> ne peut pas vérifier le schema fichiers eux-mêmes, malheureusement, parce que
|
|
leur schema n'est pas quelque chose qu'il peut gérer.
|
|
|
|
<p>
|
|
Vos documents schema doivent pointer vers notre stylesheet standard
|
|
dans leur contenu de tête:
|
|
<code>
|
|
<?xml-stylesheet href="schema 2xhtml.xsl" type="text/xsl"?>
|
|
</code>
|
|
Stylesheets tourne le code XML comme ce schéma, dans une forme lisible par l'utilisateur
|
|
quand le XML est analysé et affiché par un navigateur.
|
|
Pour un exemple, cliquez sur ce lien pour le fichier schéma
|
|
<a href="http://jmri.org/xml/schema/aspecttable.xsd">aspecttable.xsd</a>
|
|
Notre norme stylesheet est assez basique.
|
|
Elle montre juste quelques structure basique. Si quelqu'un connaît une meilleur Stylsheet, nous
|
|
pourront certainement basculer vers elle.
|
|
|
|
<a id="test"></a>
|
|
<h3>Test JUnit</h3>
|
|
|
|
Vous devez ajoutez aussi un
|
|
<a href="JUnit.shtml">test JUnit</a>
|
|
qui vérifie un fichier typique
|
|
Il y a trois sortes de vérifications qui peuvent être faites:
|
|
<ol>
|
|
<li>Vous devriez toujours avoir une classe qui valide
|
|
un fichier typique contre le schéma.
|
|
<br>
|
|
Cela se fait en ayant une classe Schema Test dans votre paquet d'arbre de test ( voir par exemple:
|
|
<a href="http://sourceforge.net/p/jmri/code/HEAD/tree/trunk/jmri/java/test/jmri/configurexml/SchemaTest.java" target="_blank">test/jmri/configurexml/Schema Test.java</a>
|
|
qui vérifie tous les fichiers XML conservés là.
|
|
Si cela est en place, mettez juste une copie du ( nouveau )
|
|
fichier typique XML dans le sous-répertoire "verify" existant.
|
|
<br>Pour vérifier plus largement votre schéma, vous pouvez vérifier qu'il
|
|
met en défaut les fichiers XML que vous pensez n'être pas valides.
|
|
Il y a beaucoup de façons de ne pas être valable, et vous ne devez pas
|
|
tout vérifier, mais s'il y a quelque chose de spécifique dont
|
|
vous voulez être sûr, mettez un exemple de ceci
|
|
dans le sous-répertoire "invalid". Ces fichiers sont attendus en échec
|
|
pour une raison spécifique. Vous devez documenter cette raison par l'intermédiaire des commentaires dans le fichier
|
|
lui-même afin que vos collègues puissent le comprendre plus tard.
|
|
<li>S'il n'y a pas de sous-répertoire "verify", créez en un et ajoutez le
|
|
à la fin de de la classe Schema Test dans ce paquet. S'il n'y
|
|
a pas de classe Schema Test, créez en une en dupliquant une existante,
|
|
voir lien ci-dessous. N'oubliez pas de l'ajouter dans le PackageTest pour qu'elle soit appelée!</li>
|
|
|
|
<li>Si vous travaillez sur les fichiers configurexml ( fichiers panneau ) ,
|
|
et que votre nouveau code n'est pas appelé dans l'affichage actuel des panneaux
|
|
( ex: peut fonctionner dans le cadre d'headlesstest ), vous devez ajouter un test pour qu'un
|
|
exemple de fichier puissent être téléchargé et restocké avec succès.
|
|
|
|
( nous exécutons ces tests headless comme une part de Jenkins, donc SVP
|
|
n'ajoutez pas de test qui font apparaître des fenêtres, cela causerait des erreurs ).
|
|
<br>
|
|
Cela se fait en ayant une classe LoadAndStoreTest dans votre paquet test-tree ( voir ex:
|
|
<a href="http://sourceforge.net/p/jmri/code/HEAD/tree/trunk/jmri/java/test/jmri/configurexml/LoadAndStoreTest.java" target="_blank">test/jmri/configurexml/LoadAndStoreTest.java</a> )
|
|
qui vérifie tous les fichiers XML gardés là.
|
|
Si c'est en place, mettez juste une copie d'un ( nouveau )
|
|
fichier XML typique dans le sous-répertoire existant "load"
|
|
<br> S'il ny a pas de sous-répertoire "load", créez en un en dupliquant un existant,
|
|
à la fin de la classe LoadAndStoreTest à la fin de ce paquet. S'il n'y
|
|
a pas de classe LoadAndStoreTest, créez en une en dupliquant une existante.
|
|
voir le lien ci-dessous. N'oubliez pas de l'ajouter dans PackageTest pour qu'elle puisse être appelée!
|
|
<br>Quand LoadAndStoreTest s'exécute, il charge les fichiers dans le répertoire "load"
|
|
un par un, stocker chaque retour vers le répertoire "temp" au sein
|
|
du répertoire des préférences locales, et ensuite compare les fichier d'entrées et
|
|
sorties. Parfois ce processus de charge-et-stockage a comme conséquence quelque chose qui est
|
|
dans un ordre différent, ou contient plus d'infos( ex: les attributs manquants depuis
|
|
le fichier sont écrits avec les valeurs par défaut dans les fichiers de sortie ). Si
|
|
la comparaison échoue, mais le fichier de sortie est encore OK quand vous l'inspecter manuellement,
|
|
copiez ce fichier de sortie dans le répertoire "loadref" (créez le
|
|
si nécessaire ) au sein de votre paquet test. Voir
|
|
<a href="http://sourceforge.net/p/jmri/code/HEAD/tree/trunk/jmri/java/test/jmri/configurexml/loadref" target="_blank">test/jmri/configurexml/loadref</a>
|
|
comme exemple. LoadAndStoreTest comparera aux dossiers qu'il trouve ici,
|
|
au lieu du fichier original dans le sous-répertoire "load".
|
|
<br>Si vos changements de code provoque l'échec de ce test
|
|
avec l'ancienne version de ce fichier, <em>ne pas changer l'ancienne version.</em>
|
|
À la place, soit mettre une référence de sortie actualisée dans le répertoire
|
|
"loadref", versionner le schema pour permettre à l'ancien fichier de se charger,
|
|
ou réparez votre code. La compatibilité ascendante est importante!</li>
|
|
|
|
<li>Vous pouvez aussi ajouter un test JUnit personnalisé qui lit votre dossier
|
|
témoin et veille que les objets appropriés ont été créés, qu'ils
|
|
ont les données et les états corrects, etc. Ceci pourrait être
|
|
quelque chose d'une "chargez et vérifiez que les nouveaux beans existent dans le nouveau gestionnaire"
|
|
pour quelque chose de beaucoup plus étendue.</li>
|
|
</ol>
|
|
|
|
Au minimum, SVP veuillez faire les contrôles de schéma. Ils sont faciles, et
|
|
épargneront un bon nombre d'ennuis à l'avenir. Si votre nouvelle fonction
|
|
n'appelle pas d'affichage sur l'écran, l'ajout de des vérification charger et stocker est aussi
|
|
valable, et ce n'est pas si dur.
|
|
<p><em>Note: Ne pas supprimer ou modifier un fichier XML existant vérifié.
|
|
Ceux-ci conservent les anciennes versions des fichiers de travail!</em>
|
|
Si votre nouveau code et/ou schema casse le processus de fichiers existants,
|
|
vous devez soit corriger votre code ou
|
|
<a href="#versioning">numéroter la version du schéma</a> pour permettre à de multiple
|
|
formats de coexister.
|
|
|
|
<a id="devschema"></a>
|
|
<h2>Developpement du Schema JMRI</h2>
|
|
|
|
Pour quelques exemples des structures de schema XML
|
|
décrit ici, voir la page séparée
|
|
<a href="XmlSchemaExamples.shtml">Exemples Schema XML</a>
|
|
<p>
|
|
Notre organisation préférée pour les schema XML
|
|
est basée sur la structure du code sous-jacent:
|
|
Une classe particulière *XML est l'unité de réutilisation.
|
|
|
|
<p>
|
|
Un bon nombre de classes descendent de jmri.configurexml.XmAdapter:
|
|
( <a href="http://jmri.org/JavaDoc/doc/jmri/configurexml/XmlAdapter.html">voir JavaDoc</a> )
|
|
|
|
<p>
|
|
Par convention, fournir <xsd:annotation><xsd:appinfo> élément contenant
|
|
le nom de classe qui lit et écrit l'élément:
|
|
<pre><code>
|
|
<xs:annotation>
|
|
<xs:documentation>
|
|
Some human readable docs go here
|
|
</xs:documentation>
|
|
<xs:appinfo>
|
|
<jmri:usingclass configurexml="false">jmri.managers.DefaultSignalSystemManager</jmri:usingclass>
|
|
</xs:appinfo>
|
|
</xs:annotation>
|
|
</code></pre>
|
|
|
|
<h3>Le Motif de Stores Vénitiens</h3>
|
|
|
|
Nous nous dirigeons vers la structuration de notre XML en utilisant le
|
|
"<a href="http://www.xfront.com/GlobalVersusLocal.html#ThirdDesignCharacteristics">Motif de Stores Vénitiens</a>".
|
|
Dans ce style, les éléments de niveau supérieur qui sont écrits par classe ont des types définis.
|
|
Tous les éléments qui se trouvent dans ceux-ci sont définis de façon anonyme, au sein de ces éléments.
|
|
Pour un exemple, voir le fichier
|
|
<a href="http://jmri.org/xml/schema/types/sensors.xsd">types/sensors.xsd</a>
|
|
qui définit un type pour l'élément "sensors",écrit pour SensorManagers.
|
|
Dans ce cadre, il est inclus une définition d'un élément capteur,et un élément
|
|
"comment" dans ce contexte.
|
|
|
|
<p>
|
|
Ceci limite le nombre de types et garde les fichiers schema à peu près alignés avec
|
|
les classes qui font la lecture et l'écriture.
|
|
|
|
<p>
|
|
Il y a quelques éléments (éléments et groupes d'attributs) qui s'étendent sur plusieurs types.
|
|
Ils sont définis dans le fichier
|
|
<a href="http://jmri.org/xml/schema/types/general.xsd">types/general.xsd</a> .
|
|
|
|
<p>
|
|
Plus d'informations sur les modèles de conception de schémas XML est disponible à
|
|
<a href="http://www.ibm.com/developerworks/xml/library/ws-soa-xmlwsdl.html#N1012B">DeveloperWorks</a> et le
|
|
<a href="http://www.oracle.com/technetwork/java/design-patterns-142138.html">Site web Java Oracle</a>.
|
|
|
|
<h3>Sur des Éléments contre des Attributs</h3>
|
|
Lors de la définition comment stocker de nouvelles classes ou mises à jour des classes, les questions
|
|
de bases sont:
|
|
<ul>
|
|
<li>Stockons nous des données? Dans ce cas, elles doivent être stockées dans un élément qui leur sont
|
|
propres. Commentaires, les valeurs de vitesse, noms utilisateur et système sont tous des exemples de données
|
|
qui doivent être stockées séparément.
|
|
<Li>Est-ce un modificateur qui fournit des informations sur les données de l'élément?
|
|
Dans ce cas, il est CORRECTE de stocker les informations de modification dans un attribut.
|
|
La couleur d'une étiquette, que ce soit un aiguillage est inversée, quelle icône de la liste ci-dessous
|
|
à charger sont des exemples de modificateurs.
|
|
</ul>
|
|
|
|
JMRI XML à l'origine se pencha fortement sur les attributs en raison des limitations dans la
|
|
bibliothèque JDOM. Ces limitations ont disparu depuis longtemps, et nous sommes en train de passer en direction
|
|
d'utilisation des éléments de la bonne façon.
|
|
|
|
<h3>Types Définis Disponibles</h3>
|
|
|
|
Le schema JMRI fournit un grand nombre de types de données prédéfinies. Celle-ci
|
|
(En général) vérifient leur contenu, et seront maintenue à l'avenir comme des changements
|
|
de contenu valides, il est donc préférable d'utiliser ceux-ci, si possible, au lieu de
|
|
définir les votre.
|
|
<p>
|
|
Une liste partielle des types prédéfinis:
|
|
<dl>
|
|
<dt>systemNameType<dd>Noms Système, à terme, être renforcé dans un véritable test de validité
|
|
<dt>userNameType<dd>Noms utilisateur, le nom vide n'est pas inclut
|
|
<dt>nullUserNameType<dd>Noms utilisateur, avec la valeur vide autorisée
|
|
<dt>beanNameType<dd>Soit nom utilisateur ou nom système
|
|
<dt>turnoutStateType<dd>closed, thrown
|
|
<dt>signalColorType<dd>red, yellow, et
|
|
<dt>trueFalseType<dd>true, false
|
|
<dt>yesNoType<dd>yes, no
|
|
<dt>yesNoMaybeType<dd>yes, no, maybe
|
|
</dl>
|
|
|
|
Pour d'autres, naviguer sur les
|
|
<a href="http://jmri.org/xml/schema/types/general.xsd">types généraux de schema</a>.
|
|
|
|
<h2>Normes Externes et Travaux Futurs</h2>
|
|
|
|
le
|
|
<a href="http://www.oasis-open.org/"> collaboration OASIS</a>
|
|
définit un certain nombre de schema et d'éléments de schema qui sont devenus
|
|
des normes bien connu. Où c'est possible, nous devrions utiliser les
|
|
<a href="http://www.oasis-open.org/specs/index.php"> éléments standard </a>
|
|
pour améliorer l'inter-opérabilité. Les premiers intérêts sont:
|
|
<ul>
|
|
<li><a href="http://docbook.org/">DockBook</a> définit les éléments pour plusieurs concepts que nous utilisons:
|
|
<ul>
|
|
<li>author (http://www.docbook.org/tdg/en/html/author.html)
|
|
<li>address (http://www.docbook.org/tdg/en/html/address.html)
|
|
<li>revision history (http://www.docbook.org/tdg/en/html/revhistory.html)
|
|
</ul>
|
|
|
|
Voir
|
|
<ul>
|
|
<li><a href="http://www.docbook.org/specs/docbook-5.0-spec-cs-01.html">http://www.docbook.org/specs/docbook-5.0-spec-cs-01.html</a></li>
|
|
<li><a href="http://www.docbook.org/xml/5.0/xsd/">http://www.docbook.org/xml/5.0/xsd/</a></li>
|
|
<li><a href="http://www.docbook.org/xml/5.0/xsd/docbook.xsd">http://www.docbook.org/xml/5.0/xsd/docbook.xsd</a></li>
|
|
</ul>
|
|
<p>
|
|
Nous avons notre propre sous-ensemble DocBook que nous utilisons, parce
|
|
le DocBook 5.0 de schema prend un temps très long à analyser,
|
|
et n'est pas entièrement compatible avec les versions d'autres logiciels que nous utilisons.
|
|
Nous utilisons l'espace de noms normal de DocBook 5.0 , de sorte que nous pouvons facilement convertir plus tard à
|
|
un schema plus complet de façon transparente.
|
|
Notre schema plus petit est situé à
|
|
<a href="http://jmri.org/xml/schema/docbook/docbook.xsd">http://jmri.org/xml/schema /docbook/docbook.xsd</a>
|
|
(Notre emplacement de schema habituel). Il est <em>seulement</em>
|
|
référencé à partir de fichiers de schema JMRI, et non pas les fichiers d'instance,
|
|
afin que nous puissions plus tard convertir avec le travail fini.</p></li>
|
|
|
|
<li><a href="http://www.oasis-open.org/committees/ubl/faq.php">UBL</a>,
|
|
mais visant les
|
|
transactions, définit des éléments pour représenter des parties (sociétés,
|
|
les gens), des dispositifs, des numéros de type, etc.</li>
|
|
|
|
<li><a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office">OpenDocument</a>
|
|
(OODF) définit un ensemble d'éléments et de structures pour
|
|
les calculs dans le cadre de son module de calcul. (Mais ils fournissent Relax-NG schéma, pas le W3C XML Schema ,
|
|
donc cela ne vous aide pas tellement)</li>
|
|
</ul>
|
|
|
|
Apprendre à utiliser ceux-ci, demandera un peu de travail, comme
|
|
nous ne pouvons pas supposer que les ordinateurs utilisant JMRI ont accès à Internet,
|
|
on ne peut donc pas simplement référencer l'ensemble du schema comme des entités distantes.
|
|
|
|
<h2> Droit d'auteur, Auteur et Information de Révision </h2>
|
|
|
|
Pour diverses raisons, nous devons passer au format DocBook
|
|
pour le Copyrignt, Auteur et Informations de Révision dans nos fichiers XML
|
|
(fichiers d'instance).
|
|
|
|
<p>
|
|
Exemple XML:
|
|
<code>
|
|
<db: copyright >
|
|
<db: année > 2009 </db: année >
|
|
<db: année > 2010 </db: année > <
|
|
db: support > JMRI </db: support > </db: copyright >
|
|
|
|
<db:authorgroup>
|
|
<db:author>
|
|
<db:personname><db:firstname>Sample</db:firstname><db:surname>Name</db:surname></db:personname>
|
|
<db:email>name@com.domain</db:email>
|
|
</db:author>
|
|
</db:authorgroup>
|
|
|
|
<db:revhistory>
|
|
<db:revision>
|
|
<db:revnumber>1</db:revnumber>
|
|
<db:date>2009-12-28</db:date>
|
|
<db:authorinitials>initials</db:authorinitials>
|
|
</db:revision>
|
|
</db:revhistory>
|
|
</code>
|
|
|
|
<p>
|
|
Description de l'échantillon du schéma: (Mais voir le vrai, qui est prévu dans le schema /docbook )
|
|
<code>
|
|
<xs: element ref =: minOccurs "docbook copyright" = "1" maxOccurs = "1" >
|
|
<xs: annotation > < xs: documentation >
|
|
élément (s) DocBook fournissant des informations de copyright sous forme standard.
|
|
Doit être présent.
|
|
</xs: documentation > </xs: annotation >
|
|
</xs: element >
|
|
|
|
<xs: element ref =: minOccurs "docbook AuthorGroup" = "1" maxOccurs = "unbounded" >
|
|
<xs: annotation > <xs: documentation >
|
|
élément DocBook (s) décrivant les auteurs en forme standard
|
|
</xs: documentation > </xs: annotation >
|
|
</xs: element >
|
|
|
|
|
|
<xs:element ref="docbook:revhistory" minOccurs="1" maxOccurs="unbounded" >
|
|
<xs:annotation><xs:documentation>
|
|
élément(s) DocBook décrivant l'historique des révisions en forme standard
|
|
</xs:documentation></xs:annotation>
|
|
</xs:element>
|
|
</code>
|
|
</p>
|
|
|
|
<!--#include virtual="/help/fr/parts/Footer_fr.shtml" -->
|
|
</div><!-- closes #mainContent-->
|
|
</div> <!-- closes #mBody-->
|
|
<script src="/js/help.js"></script>
|
|
</body>
|
|
</html>
|