[java] XML JAXP DOM SAX discussie/vragen

[Alarmnummer]

Ik ben even door een aantal artikels van Sun aan het struinen en ben er nu een beetje achter wat JAXP DOM en SAX zijn. Ik wil graag weten of ik goed zit dus iedereen die commentaar heeft die is van harte uitgenodigd


DOM is een XML parser die een boom structuur oplevert, SAX werkt met events en levert geloof ik een lijst met element op.

JAXP is een soortement van wrapper om DOM en SAX heen zodat e als programmeur niet meer voor een specifieke implementatie ontwerpt. Dus eigelijk is JAXP dan het meest interessante voor een programmeur omdat je eenvoudig tussen implementatie kan wisselen. Ik maak op dit moment een reader/writer klasse die een hele object structuur leest/schrijft dus het is ook nog relatief eenvoudig om een andere parser erop te zetten.

Verder heb je nog JDOM die ik zelf gebruik. JDOM is een java document object model. het is niet zozeer een parser zoals SAX en DOM maar hij kan wel een SAX of DOM parser gebruiken (Hij gebruikt standaard een SAX parser op de achtergrond).

Snelheid:
SAX is de snelste en gebruikt het minste geheugen. Hij is daarom geschikt voor grote documenten, maar progt minder fijn.

Gemak:
DOM is het langzaamste en gebruikt veel geheugen omdat hij dus zelf eerst het hele document in het geheugen zet. Hierdoor progt hij het fijnste.

Hierdoor lijkt me dat JDOM als meest positieve uit de bus komt omdat je er ok SAX parser achter kan plakken en dus snelheid hebt. Maar doordat het een Tree oplevert kan je er makkelijk mee proggen.

[edit] wijziging aan JDOM

[grhmpf]

Volgens mij heb je in het geval van DOM ook een SAX parser. De uitvoer van SAX komt in de DOM structuur terecht ipv dat je die zelf opvangt in je prog (in een of andere structuur misschien).

[mbravenboer]

Ik ben even door een aantal artikels van Sun aan het struinen en ben er nu een beetje achter wat JAXP DOM en SAX zijn.

Mooi .

DOM is een XML parser die een boom structuur oplevert, SAX werkt met events en levert geloof ik een lijst met element op.

Als je een XML file gaat parsen met SAX levert deze eigenlijk helemaal niets op. Dat is juist de event gebaseerd aanpak. Alle content van de XML file (characters, elementen etc) worden doorgegeven aan de gebruiker van de parser dmv de ContentHandler interface. Hierin zitten methoden zoals startElement, endElement en dergelijke. De ContentHandler (die je zelf moet implementeren) krijg de content van de file dus op een eenvoudige lineaire wijze binnen. De ContentHandler is zelf verantwoordelijk voor het 'onthouden' van de locatie in de structuur en de opslag van deze structuur zelf.

'DOM' zegt eigenlijk niets over de parser zelf. Het is gewoon het output-formaat waarin jij het resultaat van het parse-proces aangeleverd krijgt. Vaak is het zo dat deze DOM opgebouwd wordt door middel van een simpele ContentHandler. Hierbij is er dus eigenlijk niets anders dan een SAXParser.

JAXP is een soortement van wrapper om DOM en SAX heen zodat e als programmeur niet meer voor een specifieke implementatie ontwerpt. Dus eigelijk is JAXP dan het meest interessante voor een programmeur omdat je eenvoudig tussen implementatie kan wisselen.

Dat klopt helemaal .

Verder heb je nog JDOM die ik zelf gebruik. JDOM is me niet geheel duidelijk want je kan een document gewoon aanspreken als een Tree (zoals DOM) maar hij gebruikt zelf een SAX implementatie??

Dat je JDOM niet begrijpt komt waarschijnlijk doordat DOM niet helemaal duidelijk was. De W3C DOM is slechts een output van een parse-proces en zegt dus helemaal niets over de techniek die de parser zelf gebruikt. JDOM is ook een output-vorm die een variant is van de W3C-DOM, maar veel beter in het Java Platform past. JDOM is een parser-onafhankelijke implementatie van een output-vorm en je kunt hem dus op basis van allerlei bronnen opbouwen. De belangrijkste is op basis van een SAX parser. Je koppelt hierbij dus eigenlijk zelf de DOM output-vorm op de SAX.

SAX is de snelste en gebruikt het minste geheugen. Hij is daarom geschikt voor grote documenten, maar progt minder fijn.

Het parse-onderdeel van SAX is niet sneller dan die van een parser-proces met een DOM output. SAX bouwt gewoon helemaal geen structuur op en daardoor is het snel.

Overigens programmeert SAX voor veel XML documenten juist veel prettiger dan DOM. Het is gewoon een andere interface die zowel voor- als nadelen heeft .

DOM is het langzaamste en gebruikt veel geheugen omdat hij dus zelf eerst het hele document in het geheugen zet. Hierdoor progt hij het fijnste.

Het opbouwen van de DOM kost dus het meeste tijd. De hele structuur opbouwen om alleen maar je XML file te begrijpen een nogal een dure zaak, zeker als object-create duur is zoals in Java. DOM kan in combinatie met XPath prettig werken, maar het kan ook hele vervelende code opleveren.

Hierdoor lijkt me dat JDOM als meest positieve uit de bus komt omdat je er ok SAX parser achter kan plakken en dus snelheid hebt. Maar doordat het een Tree oplevert kan je er makkelijk mee proggen.

Ik hoop dat je nu dus snapt dat je dit verkeerd ziet. Er wordt ook hier gewoon een structuur opgebouwd en dat is juist het snelheids probleem. De communicatie met het parse-proces vindt plaats via de SAX interface. Deze interface is dus wel snel. Overigens schijnt de JDOM structuur wel efficienter te zijn dan de W3C DOM.

[Alarmnummer]

Thanx voor de goeie uitleg

Ik begrijpt dat een DOM niets anders is dan een tree vorm van je document en dat het niets met de parser heeft te maken. Maar ik hoor zoveel over dat er 2 vormen van parsers zijn, DOM parsers en SAX parsers. Het verschil tussen beide is niet zozeer de parser maar eerder het resultaat? Een DOM parser die levert meteen een DOM tree op die je daarna verwerkt maar bij een SAX parser moet je zelf beslissen wat je ermee doet?

ps: ik heb nog een wijziging gemaakt bij JDOM in mijn 1e message

[mbravenboer]

Overigens:

Je moet de zaken wel in zijn perspectief zien. SAX is dan wel efficienter dan DOM, maar je moet voor jouw situatie natuurlijk wel nagaan of die efficientie noodzakelijk is en of jij goed met SAX kunt werken voor een bepaalde toepassing. Als SAX voor een bepaalde situatie lastiger zou werken kan je misschien beter DOM gebruiken en op andere plaatsen aan het optimaliseren slaan.

Feit is in ieder geval wel dat je in een hele dynamische situatie met veel requests (dynamische XML generatie in servlets bijvoorbeeld) wel heel zeker van je zaak moet zijn als je DOM wilt gaan gebruiken. Heel veel XML RPC mechanismen gebruiken bijvoorbeeld intern SAX omdat DOM niet aan de eisen zou kunnen voldoen.

Als je geen situatie hebt met veel requests en bijvoorbeeld gewoon 1 keer per applicatie run een XML file moet inlezen zijn de efficientie verschillen eigenlijk niet relevant... Je kunt dan beter kijken naar de verschillen in aanpak en beslissen wat voor jou het beste werkt. Verbazend vaak komt bij mij SAX er toch als absolute winnaar uit de bus....

[Alarmnummer]

Op zondag 17 februari 2002 18:47 schreef mbravenboer het volgende:
Overigens:

Je moet de zaken wel in zijn perspectief zien. SAX is dan wel efficienter dan DOM, maar je moet voor jouw situatie ...

Maar JDOM dan? Ik vind die DOM structuur makkelijk werken en aangezien JDOM ook gebruikt maakt van SAX. Oke, je hebt natuurlijk wel wat overhead, maar JDOM is toch ook snel?

[mbravenboer]

Alarmnummer: Maar ik hoor zoveel over dat er 2 vormen van parsers zijn, DOM parsers en SAX parsers. Het verschil tussen beide is niet zozeer de parser maar eerder het resultaat?

Yep, voor deze twee gevallen wel ja.

Er zijn wel nog meer soorten interfaces tot XML parsers en die hebben eigenlijk wel een ander parse-proces nodig. Ook kan een XML parser via SAX soms niet alles valideren, waardoor de DOM interface soms niet bovenop de SAX interface is gebouwd...

Een DOM parser die levert meteen een DOM tree op die je daarna verwerkt maar bij een SAX parser moet je zelf beslissen wat je ermee doet?

Inderdaad. Een SAX parser is heel lui. Hij flikkert gewoon alles uit de XML file door het raam en jij moet maar uitzoeken wat je opvangt en wat je daarmee doet. De DOM methode pakt alles in 1 keer in en levert dat netjes aan jou af.

ik heb nog een wijziging gemaakt bij JDOM in mijn 1e message

Ik zag het later ja. Dat klopt .

[Alarmnummer]

en welke specifieke implementatie(s) zijn aan te raden?

Ik gebruik op dit moment JDOM en Crimson (de parser dus). Ik doe verder niets met XSLT via java dus ik hoef geen java transformeer tool (bv xerces). Ik heb die 1.5 mb grote xerces.jar eruit gegooit want die nam echt te veel ruimte in beslag.

ps:
met scrable raak ik al die x`en echt wel kwijt

[Alarmnummer]

oeh.. dit had ik eerder moeten ontdekken

Xerces:
XML parsers in Java, C++ (with Perl and COM bindings)

Xalan:
XSLT stylesheet processors, in Java and C++

Cocoon:
XML-based web publishing, in Java

AxKit:
XML-based web publishing, in mod_perl

FOP:
XSL formatting objects, in Java

Xang:
Rapid development of dynamic server pages, in
JavaScript

SOAP:
Simple Object Access Protocol

Batik:
A Java based toolkit for Scalable Vector Graphics (SVG)

Crimson:
A Java XML parser derived from the Sun Project X Parser.

[mbravenboer]

Alarmnummer: Maar JDOM dan? aangezien JDOM ook gebruikt maakt van SAX. Oke, je hebt natuurlijk wel wat overhead, maar JDOM is toch ook snel?

Voor JDOM gelden nog steeds dezelfde methode bezwaren. JDOM voert de DOM methode alleen wat efficienter en prettiger uit dan de standaard W3C DOM. Het benadert echter nog steeds bij lange niet de voordelen van de SAX methode.

Bij een normale W3C DOM methode zit de DOM implementatie in de parser zelf. JDOM is dus een parser-onafhankelijke andere DOM implementatie. Hierdoor wordt de methode niet verbeterd, sterker nog: hij kan zelfs langzamer zijn omdat een er altijd via een standaard interface moet werken. Gekoppelde implementaties (DOM + parser) zouden wellicht een efficientere shortcut kunnen nemen.

Dat JDOM kan werken op basis van SAX betekent dus absoluut niet dat het de voordelen van SAX meeneemt. Het enige voordeel van deze SAX interface is dat je heel erg veel parsers in samenwerking met JDOM kunt gebruiken.

[JDOM]Ik vind die DOM structuur makkelijk werken

Gebruik je het ook samen met XPath? Dat werkt ook erg prettig vind ik .

[Alarmnummer]

Ik zie dus dat xerces helemaal geen transformeer tool is maar een parser... pfff.. wat een namen zeg

[Alarmnummer]

Op zondag 17 februari 2002 19:05 schreef mbravenboer het volgende:
Gebruik je het ook samen met XPath? Dat werkt ook erg prettig vind ik .

Ik weet wat het is maar ik heb het nog nergens voor nodig gehad. Ben tot dusverre alleen geinteresseerd in het volledig inlezen van XML bestanden ipv gedeeltes.

[mbravenboer]

Alarmnummer: en welke specifieke implementatie(s) zijn aan te raden?

Xerces (liefst 2.0).

Xerces zal de opvolger worden van de huidige XML parser in JAXP: Crimson. Crimson ondersteunt bijvoorbeeld geen validatie tegen XML Schema. In de laatste early-access van JAXP zit Xerces er al in. Dit is noodzakelijk voor alle web-services libraries die eraan komen.

De oorspronkelijke codebase van Xerces was al behoorlijk goed (was van IBM afkomstig) maar de v2 schijnt nog behoorlijk wat sneller te zijn. Voor mij werkt hij prima, dus gebruik ik die tegenwoordig. Bench-marks heb ik niet gedaan.

Voor XSLT heb je inderdaad Xalan nodig. Xerces is gewoon een XML parser .

[Alarmnummer]

Op zondag 17 februari 2002 19:10 schreef mbravenboer het volgende:

[..]

Xerces (liefst 2.0).

Xerces zal de opvolger worden van de huidige XML parser in JAXP: Crimson. Crimson ondersteunt bijvoorbeeld geen validatie tegen XML Schema. In de laatste early-access van JAXP zit Xerces er al in. Dit is noodzakelijk voor alle web-services libraries die eraan komen.

De oorspronkelijke codebase van Xerces was al behoorlijk goed (was van IBM afkomstig) maar de v2 schijnt nog behoorlijk wat sneller te zijn. Voor mij werkt hij prima, dus gebruik ik die tegenwoordig. Bench-marks heb ik niet gedaan.

Voor XSLT heb je inderdaad Xalan nodig. Xerces is gewoon een XML parser .

Maar 1.5 mb is toch wel erugh groot vind ik. Het zal zijn redenen wel hebben maar als je je applicatie via webstart laat draaien dan

[mbravenboer]

Alarmnummer: [XPath]Ik weet wat het is maar ik heb het nog nergens voor nodig gehad. Ben tot dusverre alleen geinteresseerd in het volledig inlezen van XML bestanden ipv gedeeltes.

Je kan met een XPath implementatie heel eenvoudig allerlei nodes uit je JDOM vissen zonder dat je expliciet hoeft te navigeren (wat vrij vervelende code oplevert). Het heeft dus niet zozeer te maken met inlezen van gedeeltes. Je kunt gewoon makkelijk de nodes uit de JDOM vissen die je nodig hebt .

Efficientie is goed om het gewoon op het object-model (de DOM) werkt. Het heeft niets met parsen en XML syntax te maken...

[Alarmnummer]

Op zondag 17 februari 2002 19:14 schreef mbravenboer het volgende:

[..]

Je kan met een XPath implementatie heel eenvoudig allerlei nodes uit je JDOM vissen zonder dat je expliciet hoeft te navigeren (wat vrij vervelende code oplevert). Het heeft dus niet zozeer te maken met inlezen van gedeeltes. Je kunt gewoon makkelijk de nodes uit de JDOM vissen die je nodig hebt .

Efficientie is goed om het gewoon op het object-model (de DOM) werkt. Het heeft niets met parsen en XML syntax te maken...

Ik maak gewoon een recursieve aanroep inlezer/wegschrijver en ik vind dit erugh plezierig werken. En voor ieder object maak ik een aparte inlees/wegschrijf methode die ik onder elkaar zet zodat het lekker overzichtelijk blijft. Ik heb verder over het inlezen/wegschrijven geen klachten. Alleen die eeuwige validatie problemen (locatie van schema/dtd)

[mbravenboer]

Alarmnummer: Maar 1.5 mb is toch wel erugh groot vind ik. Het zal zijn redenen wel hebben maar als je je applicatie via webstart laat draaien dan

Vandaar dat het standaard in Java komt .

Overigens is hier inderdaad wel een groot probleem: vrijwel alle XML tools leveren zelf hun parser mee die je steeds opnieuw moet downloaden. Er is denk ik dringend behoefte aan een centraal en georganiseerd systeem voor libraries met een versioning en een vorm van lazy-downloading...

Op zich kan dit verwezenlijkt worden bovenop Java, dus het hoeft helemaal niet van Sun te komen....

[Alarmnummer]

Op zondag 17 februari 2002 19:17 schreef mbravenboer het volgende:

[..]

Vandaar dat het standaard in Java komt .

Overigens is hier inderdaad wel een groot probleem: vrijwel alle XML tools leveren zelf hun parser mee die je steeds opnieuw moet downloaden. Er is denk ik dringend behoefte aan een centraal en georganiseerd systeem voor libraries met een versioning en een vorm van lazy-downloading...

Op zich kan dit verwezenlijkt worden bovenop Java, dus het hoeft helemaal niet van Sun te komen....

Ik had al gezien dat mensen er goed kwaad om zijn geworden. Je hebt geloof ik vanaf 1.4 een 'override' dir is waarin je libs kan zetten die systeem libs overriden. Maarja, dit is ook niet echt fijn omdat je het soms applicatie gebonden wilt doen. En wat als je een applicatie hebt die bij een eind gebruiker komt en een nieuwere lib nodig heeft. Je kan toch moeilijk van hem verwachten dat hij files loopt te copieren.

Copieren? Hoe doe ik dat?

Daarvoor moet je bv je dosprompt of explorer openen

Dosprompt?? explorer???