public void startElement(String uri, String localName, String gName, Attributes attributes)

I primi tre sono il namespaceURI, il local name ed il nome completo dell'elemento.
Per il nostro esempio basterà considerare il local name.
L'ultimo parametro che viene passato dal parser è un oggetto Attributes che contiene, ovviamente, gli attributi (se ve ne sono).
Il metodo characters accetta per argomento un array di caratteri (con i relativi start e length) che contiene il testo incluso nell'elemento corrente

public void characters(char[] ch, int start, int length)

Link al codice di SaxDocumentParser.java

[Utilizzo: java SaxDocumentParser libro.xml]

Fig. 1  Output completo di SaxDocumentParser

L'approccio di DOM è totalmente diverso da quello di SAX. Abbiamo visto che SAX scorre il documento con un reader e, man mano che intercetta i vari tags, lancia degli eventi chiamando i metodi in cui è contenuta la logica operativa del nostro parser.
Con DOM, invece, tutto l'albero del documento viene caricato in memoria e su di esso possiamo effettuare un'esplorazione seguendo l'algoritmo che più ci aggrada.
In questa struttura ogni elemento del documento xml diventa un nodo dell'albero rappresentato da una classe che implementa l'interfaccia org.w3c.dom.Node. Questa interfaccia fornisce metodi per esplorare o modificare l'albero e per conoscere le proprietà di ogni nodo.

Link al codice di DomDocumentParser.java

[Utilizzo: java DomDocumentParser libro.xml]

La nostra classe di esempio scorre l'albero ricorsivamente e stampa a video tutte le informazioni relative a tutti gli elementi del documento xml.

Fig. 2 Output parziale di DomDocumentParser

Eseguendo il codice dell'esempio possiamo notare che l'output è alquanto diverso da quello del parser SAX. Questo è dovuto al fatto che DOM considera gli elementi del documento in modo più esteso rispetto a SAX. Un'idea di come l'albero degli elementi viene visto da DOM è visibile in figura 3:

Fig. 3 Struttura ad albero degli elementi secondo DOM

Ogni carattere contenuto nel documento è accessibile come se fosse un elemento a sé di tipo Text.
Quindi per ottenere un risultato più leggibile e coerente con l'output ritornato dal parser SAX bisogna necessariamente selezionare gli elementi.
La classe DomDocumentCleanParser realizza il nostro scopo.

Link al codice di DomDocumentCleanParser.java

[Utilizzo: java DomDocumentCleanParser libro.xml]

Considerazioni e confronto fra i due parser

Ambedue le implementazioni presentano, ovviamente, vantaggi e svantaggi che dipendono dalla situazione che il nostro parser deve fronteggiare.
Nel caso di file di dimensioni importanti (per esempio nel caso di export di database) bisogna considerare che DOM carica TUTTO il documento in memoria e lo trasforma in una struttura ad albero quindi, in questo caso, bisogna necessariamente fare i conti con le risorse del nostro sistema: pensare di caricare un intero database in memoria non è una grande idea.
Quindi, in questo caso, forse è meglio rivolgere la nostra attenzione verso SAX.
Di contro, SAX non permette un controllo agevole sulla struttura del documento e, cosa importante, non consente la modifica diretta del nostro file xml. DOM, infatti, oltre a permettere la lettura e la navigazione del documento, ne permette anche la modifica.
Se volessimo modificare un file xml con SAX dovremmo creare un altro file ed effettuare i cambiamenti che ci interessano man mano che il primo documento viene letto (ossia man mano che vengono intercettati gli eventi).

In definitiva possiamo dire che se ci serve una struttura completa del documento in memoria (a patto che il documento non abbia dimensioni mostruose) su cui poter lavorare, DOM può essere la scelta conveniente.
Se dobbiamo lavorare con files di grandi dimensioni e non ci interessa avere un controllo completo sulla struttura del file possiamo tranquillamente optare per SAX.