update help and network labels

12 files changed, 314 insertions, 31 deletions

diff --git a/config/locales/networks.yml b/config/locales/networks.yml
index 910afc509..5d75577b9 100644
--- a/config/locales/networks.yml
+++ b/config/locales/networks.yml
@@ -63,11 +63,11 @@ fr:
         registration_number: "Numéro d'enregistrement"
         name: "Nom"
         comment: "Commentaire"
-        version_date: Date de cette version du réseau
+        version_date: Date de version
         description: Description
-        source_type: "Type de système à l'origine du réseau"
-        source_name: "Nom du système à l'origine du réseau"
-        source_identifier: "Identifiant du système à l'origine du réseau"        
+        source_type: "Type de système origine"
+        source_name: "Nom du système origine"
+        source_identifier: "Identifiant du système origine"        
         objectid: "Identifiant Neptune"
         object_version: "Version"
         creation_time: "Créé le"
diff --git a/doc/functional/companies.textile b/doc/functional/companies.textile
index 30372c18f..c1db6f4d3 100644
--- a/doc/functional/companies.textile
+++ b/doc/functional/companies.textile
@@ -5,11 +5,38 @@ title: Transporteurs
 
 h3. Définition
 
-p. TODO
+Dans la réalité, le transporteur est l'entité en charge de l'exploitation d'une ou plusieurs lignes de transport. 
+Ce principe se retrouve dans ce logiciel. 
+
+* Il s'agit de l'exploitant de la ligne; chaque ligne est rattachée à un seul transporteur, un transporteur pouvant évidemment gérer plusieurs lignes. 
+* Chaque transporteur dispose d'un identifiant fonctionnel (« numéro d'enregistrement ») qui est utilisé dans les échanges XML pour identifier le transporteur et le mettre à jour. Cet identifiant est unique pour toute la base CHOUETTE, quel que soit le réseau ; il est donc important que le gestionnaire de la base CHOUETTE le renseigne d'une manière bien définie et pérenne.
 
 h3. Attributs
 
-p. TODO
+- Nom := nom du transporteur
+- Nom court := nom abrégé du transporteur
+- Nom d'unité := nom de l'unité de gestion dans la société de transport
+- Nom du département := nom du département dans la société de transport
+- Code postal := code postal de l'adresse de la société de transport
+- Numéro de téléphone := Numréro de téléphone de l'unité de gestion
+- Numéro de fax := Numéro de fax de l'unité de gestion
+- Email := adresse électronique de l'unité de gestion de l'unité de gestion
+- Numéro d'enregistrement := code référençant un transporteur au sein d'une autorité supérieure
+
+p(attr_data). Données de gestion : 
+
+- Identifiant Neptune := 
+clé unique pérenne identifiant le transporteur pour les échanges Neptune
+cet identifiant est composé de 3 parties : préfixe:type:id_technique
+* préfixe : clé identifiant un producteur de données unique
+* type = Company : clé identifiant le type d'objet (valeur imposée)
+* id_technique : valeur identifiant un seul object d'un type donné pour un même producteur
+ce champ obligatoire est automatiquement généré s'il n'est pas renseigné 
+il est possible aussi de ne renseigner que le préfixe auquel cas la valeur sera complétée automatiquement.
+=:
+- Date de création := date à laquelle l'objet a été créé ou modifié pour la dernière fois
+- Version := version de l'objet (auto incrémenté à chaque modification)
+- Créé par := compte utilisateur ayant procédé à la dernière modification
 
 h3. Implémentation
 
diff --git a/doc/functional/index.textile b/doc/functional/index.textile
index ac8c72995..b34d4e0bc 100644
--- a/doc/functional/index.textile
+++ b/doc/functional/index.textile
@@ -1,21 +1,34 @@
 ---
 layout: default
-title: Présentation
+title: Présentation
 ---
 
+Chouette v2 : itération 4 du 16/04/2012
+
+Cette itération présente les formulaires de :
+
+* réseaux
+* lignes
+* arrêts
+* calendriers d'application
+
+l'avancement actuel permet de ...
+
 h3. Sommaire
 
-# "Espaces de données":referentials
-# "Réseaux":networks
+# "Généralités":introduction
+## "Normalisation":normalisation
+# "Espaces de données":dataspaces
+# "Réseaux":networks
 # "Transporteurs":companies
 # "Lignes":lines
-## Séquences d'arrêts
+## Séquences d'arrêts
 ## Horaires
-# "Arrêts":stop_areas
+# "Arrêts":stop_areas
 ## Correspondances
-## Accès
-## Liaisons Arrêt-Accès
-# Calendriers d'application
+## Accès
+## Liaisons Arrêt-Accès
+# "Calendriers d'application":timetables
 # Outils
 ## Imports
 ## Validation
diff --git a/doc/functional/introduction.textile b/doc/functional/introduction.textile
index 54725242b..71f954d53 100644
--- a/doc/functional/introduction.textile
+++ b/doc/functional/introduction.textile
@@ -3,3 +3,13 @@ layout: default
 title: Introduction
 ---
 
+CHOUETTE est un logiciel libre développé à l'initiative du ministère français chargé des transports (et du développement durable), 
+dans le but de faciliter l'échange de données d'offre (théorique) de transport collectif (TC), 
+en s'appuyant pour cela sur la norme NFP 99506, dite Neptune, qui spécifie un profil d'échange XML.
+
+Les utilisateurs visés sont les collectivités locales Autorités Organisatrices de Transport (AOT), 
+les exploitants des réseaux TC ,et leurs prestataires (bureaux d'étude ou société de services). 
+D'autres utilisateurs potentiels sont néanmoins identifiés : services de l'état, éditeurs de logiciels, 
+opérateurs de services d'information, chercheurs...
+
+
diff --git a/doc/functional/lines.textile b/doc/functional/lines.textile
index 29fc94df1..9997c0d50 100644
--- a/doc/functional/lines.textile
+++ b/doc/functional/lines.textile
@@ -5,11 +5,40 @@ title: Lignes
 
 h3. Définition
 
-p. TODO
+Une ligne référence un réseau et un transporteur; par ailleurs la ligne se compose d'un ou plusieurs itinéraires. 
+La ligne dispose aussi d'un identifiant fonctionnel (« numéro d'enregistrement ») qui est utilisé dans les échanges XML pour identifier la ligne et la mettre à jour; il est donc important que le gestionnaire de la base CHOUETTE le renseigne d'une manière bien définie et pérenne.
 
 h3. Attributs
 
-p. TODO
+- Réseau := réseau d'appartenance de la ligne
+- Transporteur := 
+transporteur principal exploitant la ligne
+les autres transporteurs de la lignes sont référencés au niveau de chaque course
+=:
+- Nom := nom de la ligne 
+- Nom public := nom de la ligne connu des usagers
+- Numéro d'enregistrement := code référençant une ligne au sein d'une autorité supérieure
+- Indice := indice de la ligne
+- Mode de transport := 
+mode de transport principal de la ligne
+les modes de transports particuliers sont indiqués au niveau de chaque course 
+=:
+- Commentaire := zone de texte libre sur la ligne
+
+p(attr_data). Données de gestion : 
+
+- Identifiant Neptune := 
+clé unique pérenne identifiant la ligne pour les échanges Neptune
+cet identifiant est composé de 3 parties : préfixe:type:id_technique
+* préfixe : clé identifiant un producteur de données unique
+* type = Line : clé identifiant le type d'objet (valeur imposée)
+* id_technique : valeur identifiant un seul object d'un type donné pour un même producteur
+ce champ obligatoire est automatiquement généré s'il n'est pas renseigné 
+il est possible aussi de ne renseigner que le préfixe auquel cas la valeur sera complétée automatiquement.
+=:
+- Date de création := date à laquelle l'objet a été créé ou modifié pour la dernière fois
+- Version := version de l'objet (auto incrémenté à chaque modification)
+- Créé par := compte utilisateur ayant procédé à la dernière modification
 
 h3. Implémentation
 
diff --git a/doc/functional/networks.textile b/doc/functional/networks.textile
index 4478031cb..d9ef4d0b3 100644
--- a/doc/functional/networks.textile
+++ b/doc/functional/networks.textile
@@ -1,15 +1,39 @@
 ---
 layout: default
-title: Réseaux
+title: Réseaux
 ---
 
 h3. Définition
 
-p. TODO
+Un réseau est constitué par les lignes, les séquences d'arrêts, les Interdictions de Trafic Local (ITL), les horaires, et les courses qui le définissent.
+
+Chaque réseau dispose d'un identifiant fonctionnel (« numéro d'enregistrement ») qui est utilisé dans les échanges XML pour identifier le réseau et le mettre à jour. Il est donc important que le gestionnaire le renseigne d'une manière bien définie et pérenne.
+
 
 h3. Attributs
 
-p. TODO
+- Nom := nom du réseau 
+- Numéro d'enregistrement := code référençant un réseau au sein d'une autorité supérieure
+- Commentaire := zone de texte libre sur le réseau
+- Date de version := date de mise en référence de l'ensemble des constituants du réseau
+- Description := description du réseau
+- Nom du système origine := nom du système ayant produit les données du réseau
+- Identifiant du système origine := identifiant du système ayant produit les données du réseau
+
+p(attr_data). Données de gestion :
+
+- Identifiant Neptune := 
+clé unique pérenne identifiant le réseau pour les échanges Neptune
+cet identifiant est composé de 3 parties : préfixe:type:id_technique
+* préfixe : clé identifiant un producteur de données unique
+* type = GroupOfLine : clé identifiant le type d'objet (valeur imposée)
+* id_technique : valeur identifiant un seul object d'un type donné pour un même producteur
+ce champ obligatoire est automatiquement généré s'il n'est pas renseigné 
+il est possible aussi de ne renseigner que le préfixe auquel cas la valeur sera complétée automatiquement.
+=:
+- Date de création := date à laquelle l'objet a été créé ou modifié pour la dernière fois
+- Version := version de l'objet (auto incrémenté à chaque modification)
+- Créé par := compte utilisateur ayant procédé à la dernière modification
 
 h3. Implémentation
 
diff --git a/doc/functional/normalisation.textile b/doc/functional/normalisation.textile
new file mode 100644
index 000000000..2790d5320
--- /dev/null
+++ b/doc/functional/normalisation.textile
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Normalisation
+---
+
+Le projet Chouette a été développé dans le cadre de la normalisation de l'information sur les transports publics (AFNOR/BNEVT CN03/GT7), en vue de faciliter l'interopérabilité des systèmes et en particulier les échanges de données entre Systèmes d'Information Multimodale.
+
+h3. TRANSMODEL (EN12896)
+
+La norme européenne TRANSMODEL constitue le modèle conceptuel de données sur lequel s'appuie l'ensemble des travaux normatifs (Neptune, SIRI, IFOPT, NETEX) . Elle est actuellement validée dans sa version 5.1.
+
+Elle a pour objectif de décrire les différents concepts utilisés au sein des multiples métiers du transport public (aussi bien dans le domaine de l'exploitation, de la régulation que dans celui de l'information voyageur) en usant de la modélisation UML. Cette description a abouti à la constitution d'un "dictionnaire" dans lequel chacun peut venir piocher la terminologie adéquate pour pouvoir désigner, quels que soient la structure et le métier de l'intéressé, de façon homogène et non ambigu&eumlc; les concepts qu'il va décliner dans son application.
+
+h3. de TRIDENT à NEPTUNE (PR NF P99-506)
+
+Dans le cadre de la commission de normalisation CN03 pour les applications télématiques dans les transports publics, miroir du groupe européen CEN TC278 / WG3, un groupe de travail GT7 a été créé en 2002 pour normaliser les échanges de données concernant l'information aux voyageurs entre exploitants et Autorités Organisatrices de transport.
+
+Après examen des travaux en cours au niveau européen, il est apparu au groupe que les spécifications d'échange élaborées dans le cadre du projet européen TRIDENT étaient la meilleure base de travail sur laquelle s'appuyer pour la normalisation. 
+Ces spécifications d'échange couvrent l'information VP et TC, théorique et en situation perturbée; elles s'appuient sur :
+* un modèle d'échange pair à pair entre fournisseur et client, avec possibilité d'abonnement ; 
+* un modèle de données orienté objets décrit en UML, reprenant pour ce qui concerne les transports publics, le modèle conceptuel de données Transmodel V4.0, normalisé au niveau européen ; 
+* un format d'échange XML spécifié sous forme de schémas XSD. 
+
+Les spécifications TRIDENT ont été implémentées dans plusieurs pays européens, et en France ont été mises en œuvre par la RATP pour son système d'information sur les situations perturbées SIPRE, et également pour les échanges d'information au niveau francilien en cours entre les systèmes de la RATP et du STIF, pour ce qui concerne l'information théorique.
+
+Le travail du groupe GT7 a abouti à des spécifications de profil d'échange TRIDENT / Chouette en 2006, qui ont servi de référence pour implémenter le logiciel CHOUETTE et sont utilisées depuis lors par plusieurs projets de SIM en France.
+
+Lors des discussions précédant l'enquête probatoire AFNOR en 2009 en vue faire de ces spécifications une norme française, ces spécifications ont été complétées par quelques éléments de données relatifs à l'accessibilité des transports : le nouveau profil d'échange baptisé *NEPTUNE* (PR NF99-506 Décembre 2009) a été adopté en janvier 2010. Il y a compatibilité ascendante avec les fichiers au profil Trident/Chouette dont Neptune est une extension.
+
+h3. Le profile d'échange NEPTUNE
+
+Le développement des Systèmes d'Information Multimodale a conduit les partenaires des transports publics en France (AOT et opérateurs, représentants d'utilisateurs et administrations publiques) dans leur ensemble à demander l'inscription de ce profil d'échange en tant que 'norme pleine'. L'adoption de ce statut de norme est d'autant plus important aujourd'hui, que les outils précités vont connaître des périodes d'évolution et d'adaptation. 
+
+Dans le cadre du processus de normalisation, le profil d'échange a été rebaptisé NEPTUNE et complété . Le processus s'est conclu début 2010 par l'adoption d'un document AFNOR (cf. PR NF P99-506) . 
+
+En pratique, l'essentiel est de savoir que le profil TRIDENT/CHOUETTE est compatible avec NEPTUNE : Neptune reprend l'essentiel de Trident profil Chouette, et n'a été complété qu'en ce qui concerne l'information sur l'accessibilité aux Personnes à Mobilité Réduite et les accès. En particulier, le nommage des éléments de données du profil XSD n'a pas été modifié.
+
+Ce profil résulte d'un consensus entre les différentes parties prenantes participant au groupe de travail de normalisation CN03/GT7. Il est rédigé en français. Dans certains cas, pour éviter des confusions ou des contre-sens, les concepts de la norme TRANSMODEL  qui ont été manipulés sont rappelés dans leur terminologie, voire leur définition en anglais dans le texte original de la norme TRANSMODEL  V5.1 qui vaut référence. Les rapprochements nécessaires ont été faits avec la version provisoire en français de la norme TRANSMODEL  en cours de validation. 
+
+Ce profil sera sans doute amené à évoluer en fonction des travaux réalisés dans le cadre des travaux de normalisation européens ou internationaux en cours. Ceux-ci touchent tout à la fois la représentation topographique  des réseaux de transport, les interfaces entre les données d'exploitation et l'information diffusée vers le voyageur avant et pendant le voyage (NeTEX ), la description des points d'arrêts et points fixes (IFOPT2) , les interfaces avec la billettique et les autres échanges de données envisageables dans les métiers des transports publics (TRANSMODEL).
+
+Le profil d'échange NEPTUNE (PR NF P99-506 Décembre 2009) et donc l'outil CHOUETTE se limitent aux échanges d'information concernant la description " statique " de l'offre TC (réseau, horaires), et ne couvrent pas l'information en temps réel.
+
diff --git a/doc/functional/restapis.textile b/doc/functional/restapis.textile
index 2b1018ee4..ed4aaf3b4 100644
--- a/doc/functional/restapis.textile
+++ b/doc/functional/restapis.textile
@@ -11,13 +11,13 @@ la liste des objets d'un même type peut être obtenue par l'URL REST
 ??[URL_server]/[referential_id]/[Objects].[format]??
 où :
 * URL_server : l'adresse web d'installation du serveur Chouette
-* referential_id: l'identifiant de l'espace de données
-* Objects: le type d'objet demandé (au pluriel) 
+* referential_id: l'identifiant de l'espace de données
+* Objects: le type d'objet demandé (au pluriel) 
 ** networks
 ** lines
 ** companies
 ** ...
-* id : l'identifiant de l'objet désiré
+* id : l'identifiant de l'objet désiré
 * format : le format de sortie :
 ** json
 ** xml
diff --git a/doc/functional/stop_areas.textile b/doc/functional/stop_areas.textile
index c0f49e8d7..b0e1bfbd2 100644
--- a/doc/functional/stop_areas.textile
+++ b/doc/functional/stop_areas.textile
@@ -1,15 +1,70 @@
 ---
 layout: default
-title: Arrêts
+title: Arrêts
 ---
 
 h3. Définition
 
-p. TODO
+Le référentiel des arrêts constitue un maillon essentiel du réseau, et se compose de plusieurs éléments de niveaux différents. 
+
+On recense tout d'abord les arrêts physiques, qualifiés de *point d'embarquement* ou de *quai*.  
+
+Du fait de l'existence de deux concepts dans TRIDENT, cet arrêt physique sera considéré par l'application comme une *zone d'arrêt de premier niveau*. Cette notion est nécessaire pour gérer les *points d'arrêts sur itinéraire* utilisés par certains réseaux. 
+
+L'application gère ensuite les points d'arrêts sur itinéraire à partir de ces arrêts physiques, en assurant le regroupement des points d'arrêt sur itinéraire dans un arrêt physique (cas de plusieurs lignes passant par le même arrêt physique).
+
+Par la suite, vous pourrez regrouper deux (ou plus) arrêts physiques au sein d'un *arrêt commercial* (par exemple pour regrouper les points d'arrêt physiques correspondant à deux poteaux d'arrêt de la même ligne situés de part et d'autre d'une chaussée mais aussi pour regrouper l'ensemble des points d'arrêt physiques d'un quai de gare routière pour lesquels vous considérez que le temps de correspondance est nul). Vous aurez ainsi constitué une zone d'arrêt, avec qualification arrêt commercial, de deuxième niveau.
+
+Enfin, CHOUETTE vous offre la possibilité de regrouper les lieux d'arrêt agglomérés ainsi créés au sein d'une *zone d'arrêt de troisième niveau* pour constituer des *pôles d'échange*.
+
+Ainsi on obtient les possibilités de regroupements suivants:
+* un arrêt physique regroupe plusieurs arrêts itinéraire.
+* un arrêt commercial regroupe plusieurs arrêts physiques (quai, embarquement).
+* une pôle d'échange regroupe plusieurs arrêts commerciaux. 
+
+Pour ne pas aboutir à un système trop complexe, les règles suivantes sont posées:
+* un pôle d'échange peut contenir des arrêts commerciaux et/ou des pôles d'échanges (qui ne peuvent pas en contenir d'autres).
+* un arrêt commercial ne peut contenir que des arrêts physiques.
+
+Un dernier regourpement est *l'ITL* : 
+
+*L'interdiction de trafic local* est l'interdiction faite à un service routier de prendre et de laisser un même voyageur à l'intérieur du périmètre des transports urbains _(cf. Décret nº49-1473 du 14 novembre 1949)_ .
+Ainsi dans CHOUETTE:
+* Une ITL est un regroupement d'arrêts représentant le périmètre d'interdiction.
+* Une ITL est associée à une ou plusieurs lignes 
 
 h3. Attributs
 
-p. TODO
+- Type d'arrêt := catégorie de l'arrêt
+- Nom := nom de l'arrêt 
+- Commentaire := zone de texte libre
+- Point d'intérêt le plus proche := nom du lieu desservi par l'arrêt
+- Nom de la rue := nom de la rue de l'arrêt
+- Code INSEE := code INSEE de la commune de l'arrêt
+- Zone tarifaire := zone de tarification applicable à cet arrêt
+- Numéro d'enregistrement := code référençant un arrêt au sein d'une autorité supérieure
+
+p(attr_data). Données géographiques :
+
+- Position X := coordonnée horizontale de l'arrêt dans le référentiel de projection de l'espace de données
+- Position Y := coordonnée verticale de l'arrêt dans le référentiel de projection de l'espace de données
+- Longitude := longitude de l'arrêt dans le référentiel WGS84
+- latitude := latitude de l'arrêt dans le référentiel WGS84
+
+p(attr_data). Données de gestion :
+
+- Identifiant Neptune :=
+clé unique pérenne identifiant la ligne pour les échanges Neptune
+cet identifiant est composé de 3 parties : préfixe:type:id_technique
+* préfixe : clé identifiant un producteur de données unique
+* type = Line : clé identifiant le type d'objet (valeur imposée)
+* id_technique : valeur identifiant un seul object d'un type donné pour un même producteur
+ce champ obligatoire est automatiquement généré s'il n'est pas renseigné 
+il est possible aussi de ne renseigner que le préfixe auquel cas la valeur sera complétée automatiquement.
+=:
+- Date de création := date à laquelle l'objet a été créé ou modifié pour la dernière fois
+- Version := version de l'objet (auto incrémenté à chaque modification)
+- Créé par := compte utilisateur ayant procédé à la dernière modification
 
 h3. Implémentation
 
diff --git a/doc/functional/stylesheets/help.css b/doc/functional/stylesheets/help.css
index 437b28347..9e03d7a30 100644
--- a/doc/functional/stylesheets/help.css
+++ b/doc/functional/stylesheets/help.css
@@ -16,10 +16,45 @@
     margin: 7px 0 7px 20px;
 }
 
+#workspace ul li li {
+    list-style: disc;
+}
+
+
+#workspace ol {
+    list-style: none; 
+    margin: 7px 0 7px 20px;
+    padding: 0;
+    counter-reset: num;
+}
+
+#workspace ol li:before {
+    content: counter(num) '. ';
+    counter-increment: num;
+}
+
+#workspace ol ol li:before {
+    content: counters(num, '.') ' ';
+}
+
+
 #workspace em {
     font-style: italic;
 }
 
+#workspace strong {
+    font-weight: bold;
+}
+
+#workspace cite {
+  font-style: italic;
+}
+
+#workspace p.attr_data {
+  font-style: italic;
+  text-decoration: underline;
+}
+
 #workspace table {
     width: 100%;
 }
@@ -30,6 +65,7 @@
 }
 
 #workspace dt {
+    font-style:italic;
     margin: 5px 0; 
 }
 
diff --git a/doc/functional/stylesheets/help.scss b/doc/functional/stylesheets/help.scss
index 42a5a2d0c..1923a494e 100644
--- a/doc/functional/stylesheets/help.scss
+++ b/doc/functional/stylesheets/help.scss
@@ -16,10 +16,39 @@
     margin: 7px 0 7px 20px;
 }
 
+#workspace ol {
+    list-style: none; 
+    margin: 7px 0 7px 20px;
+    padding: 0;
+    counter-reset: num;
+}
+
+#workspace ol li:before {
+    content: counter(num) '. ';
+    counter-increment: num;
+}
+
+#workspace ol ol li:before {
+    content: counters(num, '.') ' ';
+}
+
 #workspace em {
     font-style: italic;
 }
 
+#workspace strong {
+    font-weight: bold;
+}
+
+#workspace cite {
+  font-style: italic;
+}
+
+#workspace p.attr_data {
+  font-style: italic;
+  text-decoration: underline;
+}
+
 #workspace table {
     width: 100%;
 }
@@ -30,6 +59,7 @@
 }
 
 #workspace dt {
+    font-style:italic;
     margin: 5px 0; 
 }
 
diff --git a/doc/functional/timetables.textile b/doc/functional/timetables.textile
index bff532980..57fe0d50b 100644
--- a/doc/functional/timetables.textile
+++ b/doc/functional/timetables.textile
@@ -5,33 +5,49 @@ title: Calendriers d'application
 
 h3. Définition
 
-p. Un calendrier d'application est un ensemble de dates et de périodes calendaires 
+Un calendrier d'application permet de définir la période de validité des horaires d'une course. 
+Les calendriers d'application sont donc définis indépendamment des lignes, à l'instar du référentiel des arrêts.
+
+La manière de définir un calendrier d'application est restreinte. 
+Les calendriers sont caractérisés par : 
+
+* une liste de quantièmes (jours calendaires dans l'année)
+* une liste de jours d'application (lundis, mardis, etc.)
+* une liste de périodes
+
+L'utilisateur doit donc faire attention au nommage de ses différents calendriers d'application.
+
+Plusieurs courses peuvent référencer le même calendrier.
+
+Ainsi, il est possible de construire des calendriers d'application qui sont ensuite référencés par des courses de lignes différentes. 
 
 h3. Attributs
 
 - Commentaire := Description du calendrier
-- Version := 
+- Version := version du calendrier (différent de la version de l'objet)
 - Jours d'application := jours de la semaine effectivement applicables dans le cas où des périodes sont définies dans le calendrier
 - Périodes d'application := périodes calendaires durant lesquelles le calendrier est applicable
 - Dates d'application := 
-dates spécifiques pour lesquelles le calendrier est applicable;
+dates spécifiques pour lesquelles le calendrier est applicable;
 ces dates peuvent être ajoutées dans ou en dehors des périodes calendaires.
 Un calendrier peut n'avoir que des dates calendaires, auquel cas les jours d'applications n'ont pas de signification
+=:
 
-Données de gestion : 
+p(attr_data). Données de gestion :
 
 - Identifiant Neptune := 
 clé unique pérenne identifiant le réseau pour les échanges Neptune
 cet identifiant est composé de 3 parties : préfixe:type:id_technique
+
 * préfixe : clé identifiant un producteur de données unique
 * type = Timetable : clé identifiant le type d'objet (valeur imposée)
 * id_technique : valeur identifiant un seul object d'un type donné pour un même producteur
 ce champ obligatoire est automatiquement généré s'il n'est pas renseigné 
 il est possible aussi de ne renseigner que le préfixe auquel cas la valeur sera complétée automatiquement.
 =:
-- Date de création := date à laquelle l'objet a été créé ou modifié pour la dernière fois
+- Date de création := date à laquelle l'objet a été créé ou modifié pour la dernière fois
 - Version := version de l'objet (auto incrémenté à chaque modification)
-- Créé par := compte utilisateur ayant procédé à la derni&egarve;re modification
+- Créé par := compte utilisateur ayant procédé à la dernière modification
 
 h3. Implémentation