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

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