Gagne de la cryptomonnaie GRATUITE en 5 clics et aide institut numérique à propager la connaissance universitaire >> CLIQUEZ ICI <<

La DTD en pratique

Non classé

Elément racine.

La première ligne de la DTD déclare l’élément racine qui est « ABC » ainsi que les éléments
imbriqués dans ABC

La DTD en pratique

Plusieurs instances de ces éléments sont autorisées dans le document XML du fait de la présence
du signe + suivant chacun des éléments déclarés (client+,..etc..)

Elément « client » .

La DTD en pratique 1

L’élément « client » est déclaré, il inclut un élément « commande » qui peut faire l’objet de plusieurs
instantiations.

La DTD en pratique 2

Pour chaque élément (sauf « ABC » qui est vide), nous déclarons la liste des attributs
correspondant.

La liste des attributs de l’entité « client », soit :

– id_client, dont le type est une liste de choix entre les différentes valeurs possibles pour cet
attribut, soit « jaeger01 » ou « cairelli02 » ou bien « panerai03 ». Il n’est pas possible d’encoder
dans le futur document XML une valeur autre que ces trois, autorisées par la DTD.

– nom, où nous saisirons le nom du client avec logiquement trois possibilités, soit « jaeger » ou
« cairelli » ou bien « panerai ».

– adresse, où figurera l’adresse du client, de type CDATA.

Elément « commande » .

La DTD en pratique 3

La déclaration de l’élément commande intervient au sein de « client », lui-même comportant les
éléments mesurage et charge_directe (plusieurs instantiations de mesurage et de charge_directe sont
possibles) , l’élément commande étant un élément imbriqué dans l’élément client.

Les attributs de l’élément « commande »: « id_commande », « descriptif » et « chiffre_affaire », tous trois en format CDATA.

Notons que nous n’avons pas utilisé un attribut « id_client » dans l’élément « commande »,
contrairement à ce qu’indiquent les schémas de modélisation ERD et hiérarchique, où il avait un
rôle de pointeur qui n’est plus nécessaire, les entités « client » et « commande » étant imbriquées.

Elément « mesurage » .

La DTD en pratique 4

Nous déclarons ensuite l’élément « mesurage » qui ne comporte pas d’élément imbriqué, et est donc
« EMPTY ».

Les attributs de cette élément: « id_mesurage », « id_aktivite », « date » (du relevé), « quantite »
(d’unités d’oeuvre) et « unite_oeuvre » avec une liste de choix imposés.

Nb. Il a été choisi d’orthographier « id_aktivite » avec un « k » pour être en mesure de la distinguer
d’un second attribut « id_activite ».

Notons que l’attribut « id_activite » est de type IDREF: il s’agit du pointeur reliant l’élément
« mesurage » à l’élément « activite ».

Ici aussi, du fait de l’imbrication, l’attribut « id_commande » des modélisations précédentes n’a pas
été créé.

Elément « charge_directe ».

La DTD en pratique 5

Nous déclarons enfin l’élément « charge_directe ».

Ses attributs sont: « id_charge_d », « id_pcmn » qui a une liste de choix de postes pcmn autorisés,
« montant_dir_htva_impute » et « quantite ».

Sauf « id_pcmn », les attributs sont de type CDATA.

Comme pour l’élément « mesurage », l’attribut « id_commande » n’est plus repris.

Elément « activite ».

La DTD en pratique 6

L’élément « activite » qui inclut un élément « composition_activite » peut être instancié une ou
plusieurs fois. Les attributs en sont « id_activite » et « nom_activite », avec une liste de choix;
« id_activite » est de type ID.

Il assure le lien avec l’attribut IDREF que nous décrivons quelques lignes plus haut.

Le lien est effectué par comparaison de la valeur prise par ces deux attributs.

Element « composition_activite » .

La DTD en pratique 7

L’élément « composition_activite » n’inclut pas d’autre élément (EMPTY).

Ses attributs: « id_compoact » de type CDATA; chaque instanciation de l’élément « composition
_activite » aura une valeur unique pour cet attribut; id_famille_kout de type IDREF est un pointeur
vers l’élément « famille_cout »; proportion est de type CDATA.

Elément « famille_cout » .

La DTD en pratique 8

Définissons l’élément « famille_cout » qui inclut l’élément « composition_famille ».

Ses attributs: « id_famille_cout », de type ID qui assure la relation avec l’élément
« composition_activite » (ci-dessus) et recevra une valeur unique à chaque instantiation;
« nom_famille » imposant une liste de choix.

Elément « composition_famille » .

La DTD en pratique 9

« composition_famille » est l’élément imbriqué dans « composition_famille ». L’attribut
« id_pcmn_fam » liste les postes pcmn autorisés par leur code en 6 chiffres, « proportion_cf » de
type CDATA reprendra la part d’intervention de tel poste pcmn dans la composition de famille.

Elément « charge_indirecte » .

La DTD en pratique 10

Nous déclarons l’élément « charge_indirecte » incluant l’élément « imputation » dont une ou
plusieurs instances sont possibles.

Ses attributs: « id_chargeindirecte » et « montant_htva_total » tous deux au format CDATA.

Elément « imputation » .

La DTD en pratique 11

L’élément « imputation » incorporé à « charge_indirecte » a pour attributs « id_imputation » de
type CDATA, pour lequel chaque instanciation recevra une valeur unique et une liste de choix
portant sur les codes pcmn comme précédemment (la liste est identique) pour l’attribut
« id_pcmn_imputation ».

Elément « pcmn » .

La DTD en pratique 12

Nous présentons ci-dessous la DTD.

La DTD en pratique 13

La DTD en pratique 14

Page suivante : Le document XML

Retour au menu : Elaboration d’une application de la méthode Activity Based Costing utilisant les technologies XML