Le XML A quoi ca sert?

Tiens voici un lien qui pourra peut etre t'intéresser

http://xml.developpez.com/cours/

Quelques précisions:
http://sebsauvage.net/comprendre/xml/

Merci,

SebSauvage, je connais bien ton site et j'ai déjà pas mal survoler ton article la dessus, quand à celui de développer .com, lui aussi je connais, celui d'ici aussi avant qu'on me le propose...

En faite, je suis plus à la recherche d'un petit exemple concret de mise en application des fonctionnalités du xml

Enfin bon, désolé, mais je vois pas l'intérêt profond du xml

Moi non plus !

Le principal intérêt que je verrais, c'est pour l'échange de données automatisés entre système hétérogènes.
(Et encore ! Souvent des fichiers à plat ou un fichier SQLite3 ferait mieux l'affaire.)

Ok, merci, alors je vais bien attendre pour m'y mettre....

Va jetter un oeil sur cet article afin de comprendre les enjeux liés à l'XML.

http://www.guideinformatique.com/fiche-xml-355.html

cordialement,
geb's

Je sais à quoi ca sert... je fais du dot net... et avec le framework 3, xaml, c'est du xml et puis les fichiers ressources, config....... et puis les rss, les plans sitemap, etc etc etc.....

Mais reste que xml, je comprends pas qu'on dise que c'est compliqué, c'est juste une espece de type de classement ou organisation de données texte. Je ne comprends en faite pas vraiment qu'on en fasse tout un foin...
En faite, quand j'essai d'utiliser le xml dans des applications je m'arrete vite parce que j'ai besoin de relationnel.... le xml reste pour des stockages de données simples, paramètres d'appli, plans, des données plattes...
Quand aux pages avec du xml comme sources et xls format ou autres, je ne suis pas pret de m'y mettre... sauf sous la torture.

Enfin, pour moi xml, ca reste un fichier texte structuré... pas un langage... désolé.

Merci d'être le diable... lol

Désolé d'avoir traité XML de fichier texte... mais je crois j'en démords complètement. En faite, ce que j’ai voulu dire par la, c’est que la données en elle même est du texte, sans les transformations du parseur, la donnée est du texte… tu peux très bien enregistrer une données texte dans un champ qui se dis entier… tu ne types pas réellement les données.
Quand aux parseurs, oualala, c’est bien vrai que la j’ai beaucoup de mal… enfin, j’utilise surtout celui de dot net, et la, je pense qu’à chaque fois, faut que je regarde comment ca fonctionne (p-e aussi de la mauvaise volonté).
Quand aux langage dérivés du xml (si je m’exprime bien), langage déclaratif à la xaml, je ne suis pas adepte… mais je vais m’y mettre quand même, j’ai pas le choix.

Mais, j’admets quand même qu’en matière d’échange de données, ou gestion de données assez simples et à volumes réduits, c’est vrai que c’est génial.

Mais si j’ai choix de placer mes données d’applications dans un bdd ou dans un xml… la bdd l’emporte… si j’ai des échanges, il me sera plus simple de générer du xml avec ma bdd, que de travailler en continu avec du xml.

NB : Le SQL, ca c'est de la standardisation... lol ( pour comparer aux parseurs)

volumes réduits, c’est vrai que c’est génial.

Volumes réduits, oui.

Justement, c'est là que XML me pose un problème:

A gros volume, c'est ingérable (je ne sais pas si vous avez déjà travaillé avec les Purchase Order de Rosetta.Net, les schémas sont à se tirer une balle). Ok.


Donc XML est mieux adapté aux petits volumes. On est d'accord.
Mais dans ce cas, est-ce que XML n'est pas un peu overkill ?
Si c'est un petit volume, un simple fichier texte ne serait-il pas largement suffisant ?
(Je ne parle pas de CSV, qui est - c'est vrai - pas simple à parser).


Exemple 1: Entre les fichiers de configuration XML du serveur Samba et ceux en texte (paramètre=valeur) d'Apache, je préfère largement ceux d'Apache: c'est beaucoup plus simple à lire humainement et il est facile d'écrire un parseur.
(Et c'est plus facile à comparer aussi ! Et aussi à tracer dans un gestionnaire de sources)

Exemple 2: Dans un de mes soft, j'avais la configuration du programme à conserver.
J'avais fait en XML et je suis revenu à une structure .INI.
Au final, je me suis aperçu que j'avais une structure nettement plus simple lire et écrire que l'XML, tout aussi humainement compréhensible et qui pourtant permet de hiérarchiser les paramètres. (En fait, je suis arrivé à un truc très similaire au about:config de Firefox).


Donc que ce soient gros ou petits volumes, dans grande majorité des cas les solutions autres que XML me semblent mieux adaptées. J'ai de plus en plus de mal à trouver de pertinence à l'XML.

Comme disait je ne sais plus qui sur un blog, XML est une solution à la recherche d'un problème.
(C'est méchant comme remarque, c'est vrai.)

Tiens justement, deux articles pertinents et critiques (et argumenté) concernant XML (Ne vous fiez pas au titre qui est racolleur):
http://xmlsucks.org/but_you_have_to_use_it_anyway/does-xml-s­uck.html
http://webservices.xml.com/pub/a/ws/2001/10/03/webservices.h­tml

(Le premier article est vraiment très bien.)
“Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++

si j’ai des échanges

Justement j'ai découvert un truc très intéressant pour stocker des données, les rechercher et les échanger: SQLite

C'est une base de données sous forme de librairie (le runtime ne fait que 250 ko).

- Les bases SQLite sont portables (Windows, Linux, MacOSX, PDA...). (XML l'est aussi, ok).
- SQLite est accessible de pratiquement tous les langages (C, C++, Java, Python...). (XML aussi, ok)
- Une base SQLite est un simple fichier contenant tout (schéma, tables, indexes,...). (En XML le schéma est un fichier séparé)
- SQLite est efficace (stockage des données en binaire) ; XML est verbeux (tout est stocké en texte, même le binaire !)
- SQLite supporte entiers, flottants, texte et binaire (blob). XML ne supporte que le texte. Pour stocker du binaire, vous devez passer par du base64 (gaspillage de place !)
- SQLite gère les transactions (donc en prime ça assure l'intégrité des données). Aucune notion de transaction en XML.
- Et enfin ça permet de gérer jusqu'à 2 Téra-octets de données (totalement impensable en XML).
- SQLite est indexé: la recherche est ultra-rapide. (XML ne l'est pas, et la recherche est très lente)

Ce qui veut dire que SQLite peut servir à échanger des données relationnelles ou à plat, texte, nombre ou binaire, entre programmes et systèmes hétérogènes.

ça me semble nettement plus efficace, simple et intéressant que l'XML pour échanger un ensemble de données complexes (quel que soit le volume).
Plus besoin de perdre son temps à créer des parseurs XML, parcourir les arbres XML pour extraire les données, tout ça pour au final aller les remettre dans une base de données (ce qui est bien souvent le cas).
Là vous échangez directement la base de données.


(Et en prime si un jour SQLite ne suffit plus, vous pouvez switcher votre base de données sur de l'Oracle ou autre pour gérer de très gros volumes.)

Je suis de plus en plus fan de cette base de données.
“Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++

pour le meme resultat ?
pardon mais c est exagere


J'argumente:

Un fichier de config:

Version XML:

<?xml version="1.0" encoding="ISO-8859-1"?>
<config>
    <network>
        <proxy>
            <enabled>True</enabled>
            <address>myproxy.myisp.com</address>
            <port>3128</port></proxy>
    </network>
    <assembler>
        <invert>True</invert>
        <emboss>False</emboss>
    </assembler>
    <debug>False</debug>
    <pool>
        <directory>imageppol</directory>
        <nbimages>50</nbimages>
    </pool>    
</config>

network.proxy.enabled=True
network.proxy.address=myproxy.myisp.com
network.proxy.port=3128
assembler.invert=True
assembler.emboss=False
debug=False
pool.directory=imageppol
pool.nbimages=50

Lust : malheureusement j ai l impression que ta volonte de rester sur ton impression qu xml n est pas adapte voile ta comprehension de la technologie
tu dis 'la donnee est du texte' et tu oublies donc que la grammaire xsd est justement la pour 'typer' le document... le fait qu elle soit optionnelle est une bonne idee qui simplifie l utilisation d xml mais si tu veux justement utiliser des fonctionalites plus avancer tu dois prendre en compte les 'technologies' liees
et ne compare pas xml a une base de donnees... en gros tu es en train de critiquer une mauvaise pratique que tu as probablement vu etre mise en oeuvre (et tu as le droit de le critiquer) cela ne veut pas dire pour autant qu xml n a aucun but

sebsauvage : desole mais si on me dit que pour traiter un fichier de parametres je dois ecrire un parseur alors je reponds 'j ai autre chose a faire'
pour les gros volumes de donnees (et notamment documentaires) c est tout a fait gerable (documentations de maintenance en avionique... 160M la piece sans images) ; un schema complexe denote soit une incompetence du redacteur (douteux) soit un fonctionnel lui meme complexe mais en aucun cas ce n est un probleme d xml
pour la solution qui ressemble au about:config... une question au hasard : ou est le typage de la donnee ? quel est l outil de validation permettant a quelqu un le modifiant a la main de savoir ou est une erreur ? on gratte un peu et on se retrouve avec toutes les questions deja posees et resolues avec xml (sic)
je ne trouve pas que le premier article soit si argumente que ca et il est meme tres critiquable (2002 peut expliquer certains points)
par exemple :
le point 6 ne sont que des affirmations non argumentees
le point 7 est une reponse a cote de la plaque car ses exemples de remplacement ne fournissent pas de systeme de parcours/recherche... a partir du moment ou l on type/identifie de maniere verbeuse le resultat est forcement verbeux
le point 8 n est pas une complexite mais une liberte donnee dans l utilisation d xml (venant du sgml d ailleurs) il est idiot de critiquer xml parce que 'des gens' (lesquels d ailleurs) utilisent des attributs plutot que du contenu
le point 9 est du meme tonneau quoiqu il soit vrai que dans les 10 buts premiers il etait indique qu ecrire un parser xml devait etre simple (et a vrai dire cela ne me semble pas si complique a coup de Lex/Yacc... pas simple mais pas si complique)... la derniere ligne est desormais fausse
etc (je passe sur des points ou il semble avoir raison et d autres ou il a manifestement tort)
on trouve une discussion plus interessante ici http://c2.com/cgi/wiki?XmlSucks

il y aurait beaucoup a dire sur la solution SQLite qui ne m en semble pas une notamment parce qu elle ne resout qu un probleme (stockage de donnees) parmi d autres (interoperabilite, acces simplifie) : autrement dit xml / SQLite = pas le meme combat (ils n adressent pas les memes problemes)
SQLite gere les transactions(donc l integrite des donnees... pardon ?)... on se trompe manifestement de combat... qui a dit qu xml devait remplacer les bases de donnees ??? pourquoi xml qui decrit un format devrait s occuper de definir les transactions qui permettent de le mettre a jour ?!? d autant plus que c est tres facile a mettre en place dans le langage de programmation utilise autour d xml
le meilleur pour la fin :
> ça permet de gérer jusqu'à 2 Téra-octets de données
> (totalement impensable en XML).
c est tout a fait exact mais... est-ce bien le traitement du meme type de probleme ?

> SQLite est indexé: la recherche est ultra-rapide.
> (XML ne l'est pas, et la recherche est très lente)
pardon ? compilation des patterns ca dit quelque chose ?
xml est indexe aussi (en fait cela depend du parser) mais ce n est pas si explicite...

a propos de tout ca j ai aussi un lien autrement plus interessant
http://www.awprofessional.com/articles/article.asp?p=367637&rl=1

comment SQLite permet d echanger des donnees ? en envoyant le fichier representant la base de donnees c est cela ? je signale que la meme chose etait faisable avec access (sic)
il est donne deux utilisations totalement incompatibles comme argument... si SQLite n est plus suffisant alors on change vers Oracle et du coup on ne peut plus utiliser l idee (pas si astucieuse de mon point de vue) de la transmission de donnees...
plus efficace ? plus simple ? plus interessant ? pardon ???
et cette bibliotheque en C est tres standardisee probablement... et elle est d une simplicite telle que si le modele de donnees evolue... dommage...
j imagine qu il n y a rien de tel que quelques requetes SQL dans le code pour recuperer des parametres...
et elle est probablement parfaitement adaptee aux problemes documentaires (conversion pour presentation, donnees structurees faiblement (multiplication de para), donnees hierarchisees dynamiques (elements optionnels))...
et, pour reprendre l argument, c est un bonheur de l avoir en controle de version
et je ne vois pas le rapport avec l utilisation qui est faite d xml

quant au dernier exemple il frise la mauvaise foi (si cela venait de quelqu un d autre que vous j en serais absolument sur... la je pense plutot a un leger manque de profondeur) : quel objet utilisez vous donc pour parser ce document a plat ? quelle est la representation retrouvee en memoire ? peut on la parcourir facilement ? ajoutez donc un tableau (type liste de choix de textes) dans ce fichier a plat et on verra s il est plus court...
la seconde solution peut repondre au besoin mais elle n offre pas la flexibilite d xml (c est a dire l ajout reflechi de fonctionnalites avec l evolution du besoin vis a vis de ce fichier)
comme il vaut mieux prevenir que guerir autant utiliser la meme solution pour tous ces 'petits' problemes
(et ne revenez pas me dire qu xml empiete sur les bdd... cela n est pas son role et je serai toujours d accord pour dire qu une telle utilisation est incorrecte)

Ce que je veux dire, c'est que tant qu'a faire xml un format d'échange de données avec de toute façon la nécessité d'utiliser un parseur pour la lecture des données, pourquoi enregistrer ces données encodé en texte, pourquoi ne pas directement enregistrer un entier pour ce qu'il est, parce même si le xsd type tes données, elle reste quand même enregistrée sous forme de texte... et même si le xml évite d'avoir à typer les données ce qui le rends plus extensible, un format binaire et bien plus extensible encore.
En plus, enregistrer les données dans leurs plus simple appareil permettrait de réduire leurs tailles.

Xml est une bonne idée d'agencements de données et possède des parseurs qui s’en trouvent simplifiés.
J'aurai plus trouvé ca comme une révolution si les données étaient enregistrées dans leurs formats d'utilisation... sans besoin de conversion.

En faite, ce que je reproche le plus au XML, c'est cette nécéssité d'avoir une représentation visuel directe et de vouloir confondre mécanique et carburant (dans la syntaxe) dans sa volonté de séparer les deux.
Pour un langage de prog, se baser sur les standards XML, ok, le programmeur à besoins de règles et d'une représentation texte de son langage.
Pour des données, la ou on trouve un atout au XML, moi je ne trouve pas. XML permet de stocker des dates sous des formes multiples et variées… mais ca reste une date, pour vouloir stocker une date n’importe comment pour au final retransformer, avoir des Pb de compatibilités de formats…..
L’exemple le plus flagrant à mon sens est la représentation d’un booléen : oui/non, vrai/faux, true/false, yes/no… pour récupérer ca et transformer ca en 0 ou 1…. Aye, je crois pas que stocker un « true » et un 0 soit la même chose…. Et en plus, faut analyser cette chaine de caractères pour dire c’est true quand : vrai, oui, true ou yes…. Voir même d’autres forme falquinotentesque (j’aime bien je viens d’inventer lol)… le forcing des formats n’est pas une mauvaise chose, surtout qu’on a vite fais le tout des formats (texte, numérique, booléens, date et binaire)

on se retrouve avec toutes les questions deja posees et resolues avec xml

XML résoud le problème de typage des données ? :-.
Là j'ai un doute, franchement.

(cf.l'exemple de Lust: True/False, 0/1, yes/no, etc.)

Dans tous les cas - que ce soit XML ou fichier à plat - on échappe pas à un contrôle des formats et un transtypage des données.

Certes XML avec ses outils (XSD) permet de faire certains contrôles, mais ça reste limité
(par exemple, XSD ne permettra pas de s'assurer que le numéro d'une annulation de commande correspond à celui d'une commande existantes. ça ne résoud donc que très partiellement les choses.)


si on me dit que pour traiter un fichier de parametres je dois ecrire un parseur alors je reponds 'j ai autre chose a faire'

Quand on te demande d'extraire des données d'un fichier XML, tu n'as rien à développer ?
Pas même des appels à SAX, DOM ou XPath ?
Ou encore un XSLT ?

Quant à un parseur de fichier config paramètre=valeur, ça se fait en quelques ligne et c'est réutilisable sur beaucoup de fichiers de ce type.


autrement dit xml / SQLite = pas le meme combat (ils n adressent pas les memes problemes)

Generalement, oui, je suis d'accord.
Mais dans le cas d'échange de gros volumes de données, la question peut être pertinente.

Or l'un des buts premiers d'XML, c'est l'échange. (Et j'ajoute: voir la remarque ci-dessous sur l'XML binaire).


pardon ? compilation des patterns ca dit quelque chose ?

Ok, ok. +1.

Mais l'utilisation des patterns compilés ne nécessite-elle DOM (ou équivalent), c'est à dire le chargement intégral du fichier XML en mémoire ?
160 Mo de mémoire consommée d'un coup ?
C'est faisable, mais ça n'est pas forcément acceptable dans toutes les situations.


je signale que la meme chose etait faisable avec access (sic)

oui, mais Access était une base propriétaire, à source fermés, mono-plateforme et sous license non libre.
Ce n'est pas le cas de SQLite.


plus efficace ? plus simple ? plus interessant ? pardon ???

Je maintiens ce que j'ai dit sur SQLite.
Moins d'espace disque utilisé, structuré, totalement portable, typage, méthodes d'accès standardisées (SQL-92).
Elle réunit tous les critères nécessaires à l'échange automatisé de données.


et cette bibliotheque en C est tres standardisee probablement... et elle est d une simplicite telle que si le modele de donnees evolue... dommage...

C'est vrai.
Mais est-ce que la migration sera moins lourde dans le cas d'un changement de schéma XML ?



c est un bonheur de l avoir en controle de version
et je ne vois pas le rapport avec l utilisation qui est faite d xml

L'argument "contrôle de version" concernait les fichiers texte.
Dans un contrôle de version, on peut facilement suivre les modifs des fichiers de config à plat.
Suivre des modifs de fichiers de config XML n'est pas génial, parceque le retour à la ligne n'est pas une information pertinente en XML, et les gestionnaires de version ne savent pas comparer des fichiers XML.

Difficile, donc, de faire un suivi des modifications d'un fichier XML.


il frise la mauvaise foi (si cela venait de quelqu un d autre que vous j en serais absolument sur

Oh il m'arrive d'être de mauvaise foi des fois :-)



la je pense plutot a un leger manque de profondeur)

Non je suis sérieux.
Pourquoi prendre un marteau-pilon pour écraser une fraise ?
Oui XML peut faire mieux, peut faire plus, mais est-ce vraiment nécessaire ?

J'aime le principe du KISS.


quelle est la representation retrouvee en memoire ? peut on la parcourir facilement ?

Une hashtable fait l'affaire, généralement. L'accès est donc très rapide.


ajoutez donc un tableau (type liste de choix de textes) dans ce fichier a plat et on verra s il est plus court...

blacklisted_checksums=3c5454ab|5537ab3d|2174bdfe|5eca35bd

Le parseur n'en est pas beaucoup plus compliqué.


a noter un groupe de reflexion qui se penche d ailleurs sur la possibilite d avoir du 'xml binaire'

Justement, ça ne te met pas la puce à l'oreille que ce besoin se fasse ressentir ?
(On semble se rapprocher de fichiers du type RIFF ou IFF, mais en plus évolué (qui en soit étaient de bonnes idées)).




Je ne suis pas un adversaire absolu de l'XML.

C'est juste que je trouve qu'il ajoute une complexité qui est parfois utile, mais dans la très grande majorité des cas XML est mal maîtrisée, mal utilisé et abusé, et aboutit à une complication inutile des programmes et des interfaces.

XML a ses usages, mais dans la pratique, il complique souvent des solutions qui pourraient être simples.


je dis aussi que du fait de la simplicite il est utilise a tort et a travers sans les competences requises (notamment en architecture de donnee) donc il est facile de se planter avec

Voilà, tout à fait.
XML en soit n'est pas mal du tout.

Mais cet argument me fait penser aux critiques sur l'Agile Programming: Quand on montre aux défenseur de l'Agile Programming l'énorme quantité d'échecs dans la pratique, ils rétorquent que c'est parceque la méthode a été mal utilisée.
Mais si 95% des utilisateurs ne parviennent jamais à maîtriser correctement la méthode, est-ce qu'il ne vaut pas mieux choisir une autre méthode ? (Quitte à ce qu'elle soit moins "pure" ?)

C'est un peu le cas pour XML, je trouve.




(Merci pour les liens, c'est intéressant)
“Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++

personnellement je pesne qu on ne peut pas dire qu on connaisse xml sans connaitre les technologies autour (DOM, SAX, xsd, xsl...)

Tout à fait !

Et c'est pas simple, d'ailleurs: http://www.wdvl.com/Authoring/Languages/XML/XMLFamily/BigPic­ture/bigpix20a.html
“Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++

Bonjour
j'ai ce fichier xml
<?xml version="1.0" encoding="UTF-8"?>
<usecase>
<titre>Retirer de l'argent</titre>
<resume> permettre à tous client de la banque porteur de carte bancaire de retirer de l'argent
si son solde hebdomadaire le permet</resume>
<listedesacteurs>
<acteur>client</acteur>
<acteur>ATM</acteur>
<acteur>receveur de banque</acteur>
</listedesacteurs>
<version>1.0</version>
<datedecreation>14 juin 2006 11:44:26</datedecreation>
<datedemiseajour>14 juin 2006 11:44:26</datedemiseajour>
<precondition>Caisse du ATM alimentée</precondition>
<postcondition>Diminution de la somme d'argent</postcondition>
<listrelationship >
<Include>
<Source>retirer de l'argent</Source>
<Destination>authentification</Destination> </Include>
<Extend>
<Source>controler solde</Source>
<Destination>retirer de l'argent</Destination>
</Extend>
</listrelationship >
<NbreSA>4</NbreSA>
<NbreSE>3</NbreSE>
<ScenarioNominal>
<action>
<numN>1</numN>
<preconditionN>lecteur de carte libre</preconditionN>
<acteurN>client</acteurN>
<nomN>le client introduit sa carte dans le lecteur des cartes</nomN>
</action>
<action>
<numN>2</numN>
<preconditionN>lecteur de carte libre</preconditionN>
<acteurN>ATM</acteurN>
<nomN>l'ATM vérifie que la carte introduite</nomN>
</action>
<action>
<numN>3</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>l'ATM demande au client de saisir son code d'identification</nomN>
</action>
<action>
<numN>4</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>client</acteurN>
<nomN>le client saisit son code d'identification</nomN>
</action>
<action>
<numN>5</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>l’ATM compare le code d’identification avec celui qui est codé sur la puce de la carte </nomN>
</action>
<action>
<numN>6</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>L’ATM donne son accord et indique le solde hebdomadaire </nomN>
</action>
<action>
<numN>7</numN>
<preconditionN> caisse alimentée </preconditionN>
<acteurN>ATM</acteurN>
<nomN>l’ATM demande au client de saisir le montant de retrait désiré</nomN>
</action>
<action>
<numN>8</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>client</acteurN>
<nomN>le client saisit le montant désiré du retrait</nomN>
</action>
<action>
<numN>9</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>L’ATM contrôle le montant demandé par rapport au solde
hebdomadaire </nomN>
</action>
<action>
<numN>10</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>L’ATM delivre l’argent </nomN>
</action>
<action>
<numN>11</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM </acteurN>
<nomN> L’ATM registre la transaction </nomN>
</action>
<action>
<numN>12</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM </acteurN>
<nomN> L’ATM modifie le compte de client</nomN>
</action>
<action>
<numN>13</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM </acteurN>
<nomN> L’ATM délivre un ticket</nomN>
</action>
<action>
<numN>14</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM</acteurN>
<nomN> L’ATM éjecte la carte</nomN>
</action>
</ScenarioNominal>

<SAlternatif1>
<num>1</num>
<NomScenarioA> montant desiré supérieur au solde hebdomadire</NomScenarioA>
<EvenementA> montant désiré </EvenementA>
<ActionDebutA>9</ActionDebutA>
<SequenceA1>
<NumA>13</NumA>,
<SystemeA>ATM</SystemeA>
<NomA>indique au client que le montant demandé est superieur au solde hebdomadaire</NomA>
<Reprendre> Le scénario nominal reprend au point 3</Reprendre>
</SequenceA1>
</SAlternatif1>
<SAlternatif2>
<num>2</num>
<NomScenarioA> ticket refusé</NomScenarioA>
<EvenementA> ticket refusé</EvenementA>
<ActionDebutA>9</ActionDebutA>
<SequenceA1>
<NumA>14</NumA>,
<SystemeA>ATM</SystemeA>
<NomA>indique au client que le montant demandé est superieur au solde hebdomadaire</NomA>
<Reprendre> Le scénario nominal reprend au point 3</Reprendre>
</SequenceA1>
</SAlternatif2>

<SErreur1>
<NomScenarioE>carte non valide </NomScenarioE>
<EvenementE> le client entre une carte non valide </EvenementE>
<ActionDebutE> SErreur1 commence au point 2 du scénario nominal </ActionDebutE>

<SequenceE>
<NumE>3</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM indique au client que la carte n’est pas valide </Nom>
</SequenceE>
<SequenceE>
<NumE>4</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM, confisque la carte et le cas utilisation se termine</Nom>
</SequenceE>
</SErreur1>
<SErreur2>
<NomScenarioE>retrait non autorisé </NomScenarioE>
<EvenementE> le client n’est pas autorisé de retirer argent</EvenementE>
<ActionDebutE> SErreur2 commence au point 9 du scénario nominal </ActionDebutE>

<SequenceE>
<NumE>10</NumE>
<PreconditionE/>
<ActeurE>receveur de banque</ActeurE >
<Nom> receveur de banque interdit tout retrait</Nom>
</SequenceE>


<SequenceE>
<NumE>11</NumE>
<PreconditionE/>
<ActeurE>ATM</ActeurE >
<Nom>L’ATM ejecte la carte</Nom>
</SequenceE>

</SErreur2>
<SErreur3>
<NomScenarioE>carte non reprise </NomScenarioE>
<EvenementE> le client ne prend pas sa carte</EvenementE>
<ActionDebutE> SErreur3 commence au point 14 du scénario nominal </ActionDebutE>
<SequenceE>
<NumE>15</NumE>
<PreconditionE>Après 15 secondes</PreconditionE>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM confisque la </Nom>
</SequenceE>
<SequenceE>
<NumE>16</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM informe la receveur de banque ;le cas d’utilisation se termine </Nom>
</SequenceE>
</SErreur3>
<SErreur4>
<NomScenarioE>ticket non pris</NomScenarioE>
<EvenementE> le client ne prend pas le ticket</EvenementE>
<ActionDebutE> SErreur3 commence au point 13 du scénario nominal </ActionDebutE>
<SequenceE>
<NumE>14</NumE>
<PreconditionE>Après 30 secondes</PreconditionE>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM confisque le ticket </Nom>
</SequenceE>
<SequenceE>
<NumE>15</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM informe le receveur de banque ;le cas d’utilisation se termine avec echec</Nom>
</SequenceE>
</SErreur4>
</usecase>



et je vais extraire les balises nomN


j'ai ce programme
import java.io.FileReader;

import org.xml.sax.InputSource;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLReaderFactory;

import com.sun.org.apache.xalan.internal.xsltc.runtime.Attributes;


public class recherche extends DefaultHandler
{

public static void main (String args[])
throws Exception
{
XMLReader xr = XMLReaderFactory.createXMLReader();
recherche handler = new recherche();
xr.setContentHandler(handler);
xr.setErrorHandler(handler);
xr.parse("usecase.xml");

// Parse each file provided on the
// command line.
for (int i = 0; i < args.length; i++) {
FileReader r = new FileReader(args[i]);
xr.parse(new InputSource(r));
}

}

public recherche ()
{
super();
}


////////////////////////////////////////////////////////////////////
// Event handlers.
////////////////////////////////////////////////////////////////////


public void startDocument ()
{
System.out.println("debut de l'analyse");
}


public void endDocument ()
{
System.out.println("fin de l'analyse");
}


public void startElement (String uri, String name,
String qName, Attributes atts)
{
if (qName.equals ("nomN"))
{ System.out.println("ouverture de la balise " + qName);

System.out.println("valeur:" + uri + "}" + atts);
}}


public void endElement (String uri, String name, String qName)
{
if (qName.equals ("nomN"))
System.out.println("fermeture de la balise: " + qName);
else
System.out.println("fermeture de la balise:" + name);
}


public void characters (char ch[], int start, int length)
{
System.out.print("attribut:");
for (int i = start; i < start + length; i++) {
switch (ch[i]) {
case '\\':
System.out.print("\\\\");
break;
case '"':
System.out.print("\\\"");
break;
case '\n':
System.out.print("\\n");
break;
case '\r':
System.out.print("\\r");
break;
case '\t':
System.out.print("\\t");
break;
default:
System.out.print(ch[i]);
break;
}
}
System.out.print("\"\n");
}

}

il me donne pas les attributs comment je peux le corriger
pouvez vous me corriger s'il vous plait