XML Parser - Wer die Wahl hat ... hat die Qual ...

[moelski]

Moin !

Nunja, ich bin mir bewusst das es hier schon öfter mal Anfragen gegeben hat welchen Parser man denn nehmen könnte, aber daraus konnte ich für uns noch keine Lösung "ableiten". Auf der Suche nach einem Parser bin ich über 4 Kandidaten gestolpert:

1) Microsoft MSXML
2) DIXml - http://www.yunqa.de/delphi/xml/
3) NativeXml- http://www.simdesign.nl/xml.html
4) OpenXML - http://www.philo.de/xml/

Nach welchen Kritierien müsste man bei der Auswahl denn vorgehen? Oder warauf sollte man achten. Ich denke dabei vor allem an die weitere Verfügbarkeit / Weiterentwicklung eines Parsers. Da würde sich aus meiner Sicht MSXML anbieten, oder?
Auf der anderen Seite wird der MSXML nicht allzuoft empfohlen.

Wie als den Parser für uns finden? In Anlehnung an die hier beschriebene Struktur:
http://www.delphipraxis.net/internal...t.php?t=131722

[Muetze1]

Hast du dich denn nun schon geeinigt ob du einen DOM oder SAX Parser haben willst?

[merlin17]

www.destructor.de hat auch noch einen schönen XML-Parser (sehr schnell)

:-) thomas

[Muetze1]

Wenn es nur um eine Liste der Delphi XML Parser geht, die habe ich auch verlinkt: XMLLib am Ende der Seite: Andere Implementationen.

[moelski]

Moin !

Zitat:

Hast du dich denn nun schon geeinigt ob du einen DOM oder SAX Parser haben willst

Kann ich im Moment noch nicht genau sagen. Am besten wäre ein Parser der beide Methoden unterstützt.

Mir gehts hier auch nicht um eine Parser Liste ...
Interessanter wäre eben nach welchen Kriterien man aussortieren sollte.

Ich denke wir werden auf jeden Fall auch XPath verwenden.

Also wären die Kriterien bis hierher:
- DOM & SAX Support
- XPath Support
- DTD Unterstützung
- validierender Parser

[Bernhard Geyer]

MSXML
Nachteil: Muß installiert werden (ist jedoch oft installiert) und ergibt sich damit die Gefahr der DLL-Hölle
Vorteil: Mit sicherheit einer der mächtigesten Parser der alle möglichen Features um XML herum bietet

OpenXML
Vorteil: Full Native Pascal. Keine DLL's nötig, Keine DLL-Hölle, 100% an Standard angelehnt
Nachteil: Bietet nicht alles Features eines vollständigen Parsers. Entwickung primär von einem Entwickler getrieben


Ich würde versuchen den XML möglichst gut zu kapseln so das ein Wechsel des Parsers sich nicht in jeder Unit niederschlägt.

[moelski]

Moin Bernhard,

Zitat:

ergibt sich damit die Gefahr der DLL-Hölle

Nunja, ich denke das ist noch halbwegs überschaubar.

Allerdings müsste ich schon auf MSXML 4.0 gehen. Denn 6.0 geht (laut MS) nicht mehr unter 98. Und wir ham noch 98 User ...

OpenXML..

Zitat:

Nachteil: Bietet nicht alles Features eines vollständigen Parsers.

Was fehlt denn da ?


Generell denke ich findet man zum Thema MS XML Parser mehr Informationen. Aber beim MS Parser habe ich schon mehrfach von Unzulänglichkeiten gelesen (welche auch immer das sind).

Aber ich vermute mal das Rennen entscheidet sich zwischen diesen beiden ...

[Bernhard Geyer]

Zitat:

Zitat von moelski

Allerdings müsste ich schon auf MSXML 4.0 gehen. Denn 6.0 geht (laut MS) nicht mehr unter 98. Und wir ham noch 98 User ...

Wir auch und tasten Win98 nicht an.

Zitat:

Zitat von moelski

Zitat:

Nachteil: Bietet nicht alles Features eines vollständigen Parsers.

Was fehlt denn da ?

Ich glaube bei unseren eingesetzten Version war noch kein XPath dabei.

Zitat:

Zitat von moelski

Aber beim MS Parser habe ich schon mehrfach von Unzulänglichkeiten gelesen (welche auch immer das sind).

Teilweise soll er nicht gerade 100% W3C-Konform laufen. MS hat halt immer so die eigenen Vorstellungen von Standard.

[mirage228]

Zitat:

Zitat von Bernhard Geyer

Ich würde versuchen den XML möglichst gut zu kapseln so das ein Wechsel des Parsers sich nicht in jeder Unit niederschlägt.

Er hat doch (laut Profil) Delphi 7 Professional. Da könnte man doch TXMLDocument/IXMLDocument verwenden als Kapselung. Die hat ja die Eigenschaft DomVendor, die sich an anderen Implementierungen anpassen lässt...

mfG
mirage228

[Bernhard Geyer]

Zitat:

Zitat von mirage228

Er hat doch (laut Profil) Delphi 7 Professional. Da könnte man doch TXMLDocument/IXMLDocument verwenden als Kapselung. Die hat ja die Eigenschaft DomVendor, die sich an anderen Implementierungen anpassen lässt...

Die Frage ist a, Wie weit sind XPath etc. darüber abrufbar und b, kann man neuere Versionen des Parsers einhängen. Ich denke bei beiden Punkte wird die Antwort negativ ausfallen.

[marabu]

Moin,

die Borland-Interfaces sind einfach nur anders zugeschnitten - XPath ist vorhanden, nur nicht an der von MSXML her gewohnten Stelle.
Was die Versionen betrifft, so sind im Auslieferungszustand naturgemäß keine neueren DOM-Versionen unterstützt. Die Nachrüstung sollte aber bei vorhandenem Quelltext machbar sein.

Freundliche Grüße

[bernau]

Zitat:

Zitat von merlin17

www.destructor.de hat auch noch einen schönen XML-Parser (sehr schnell)

Jep. Den verwende ich auch. Ist nichts, was man mal eben zusammenklickt. Aber dafür sehr flexibel.

Muss sagen, es ist schon lange her, daß ich mich zu XML-Parsern informiert habe. Der entscheidene Vorteil für mich war, daß ich die ausgelesenen Daten direkt während dem Parsen in meine interne Datenstruktur gelesen habe. Andere Parser haben erst mal die kompletten Daten eingelesen und dann konnte ich die Daten erst in meine Datenstruktur kopieren. Dies bedeutete, daß die Daten 2 mal im Hauptspeicher waren. Das war für mich ein grosses Kriterium, weil ich teilweise sehr grosse XML-Datenmengen einlesen muss.

Dafür gehen andere Sachen nicht.

Gerd

[moelski]

Moin !

Also es stehen nur noch OpenXML und NativeXML zur Auswahl.

openXML hat den Vorteil das es hier scheinbar weit(er) verbreitet ist und auch Stylesheets / DTD und XPath unterstützt.
Nachteil ist wohl die Doku ...

NativeXML ist ein recht schmaler Parser ohne Stylesheets / DTD und XPath. Dafür mit eigenem Forum.

[moelski]

Moin !

Was ist denn nun eigentlich TXMLDocument? Ist das eine Delphi Klasse die auf den M$ Parser aufsetzt? Oder ist das ein komplett eigener Parser von Delphi?

[Bernhard Geyer]

TXMLDocument ist eine Wrapperklasse die u.a entweder den MS Parser oder OpenXML verwendet

[Namenloser]

Sorry für das Aufwärmen des Themas. Ich entwickle hier gerade ein Programm, das unter Win9x und wichtiger, unter WINE funktionieren soll, was es aber nicht tut. Ich habe das Programm im Kompatiblitätsmodus für Win98 debuggt und festgestellt, dass es am XML-Parser liegt, der wohl unter Win98 nicht vorhanden ist. Daher dachte ich daran, als DOMVendor OpenXML auszuwählen.

Delphi-Quellcode:

txmldocument(xml).DOMVendor := GetDOMVendor('OpenXML');
{ Der Typecast erfolgt hier, weil xml ein IXMLDocument, aber kein TXMLDocument ist. IXMLDocument besitzt die Eigenschaft aber nicht. Ich hoffe, dass das so funktioniert, bin nämlich im Umgang mit Interfaces nicht sehr erfahren }

Allerdings sagt mir dann eine Fehlermeldung, dass "kein entsprechender DOM-Hersteller: OpenXML" gefunden werden könne. Muss ich irgendwelche Units dafür einbinden? Wenn ja, welche?

Danke im Voraus!

[Bernhard Geyer]

Das Problem sollte sich lösen wenn du den MSXML-Parser installierst. Am einfachsten mit der letzten noch für Win98 verfügbaren IE-Version. Ansonsten mußt du bei MS nach einem passenten MSXML-Download suchen.

[Namenloser]

Das Programm ist aber nicht nur für mich, und kann von mir selber sagen, dass ich es hasse, wenn ich für ein kleines Programm eine riesige Bibliothek herunterladen muss. Und wie sich die Installation unter Wine verhält weiß ich auch nicht.
Mein Programm braucht XML auch nur zum Speichern und Laden einer Ressource und später vielleicht mal der Einstellungen. Großartige XML-features wie XPath etc. benötige ich also gar nicht. Von daher wäre mir ein nativer Parser der ohne DLLs auskommt sowieso lieber.

[Muetze1]

Da wurden hier im Thread genug genannt. In meiner Signatur sind am Ende des XMLLib Links auch genug andere gelistet. Und wenn es nur ein paar kleine Dateien und Einstellungen geht, genau dafür hatte ich meine XMLLib mal erstellt.

[Namenloser]

Hmm, da müsst ich allerdings einige Stellen neu schreiben... und genau das wollte ich eigentlich vermeiden, indem ich einfach den Parser im TXMLDocument auswechsle. Andererseits ist es auch keine Riesenklasse. Ich schau es mir nachher/morgen mal an. :)

Edit: Ich habe mich jetzt für deine XMLLib entschieden. Die paar zeilen waren dann auch schneller umgeschrieben als ich dachte. Der Code ist obendrein auch noch geschrumpft, und ich meine acuh, dass der Programmstart sich beschleunigt hat.

Vielen Dank! :thumb:

[Muetze1]

Vielen Dank für das Lob.

[moelski]

Moin !

Auch wenn ich es glaube ich schon per Mail geschickt habe.

Ich bedanke mich auch nochmal bei Thomas für die LIB (die wir jetzt einsetzen).
Die ist einfach nur Klasse und es macht Spass damit zu arbeiten.

Many thx ! :thumb:

[Muetze1]

Ja, auch nochmal vielen Dank.

Wir setzen sie hier in der Firma auch nur ein und von daher hat sich eine neue Anforderung ergeben: es muss ein recht grosse Datei geöffnet werden und ein bestimmter Knotenpfad bzw. Struktur muss ausgelesen werden. Da die LIB zur Zeit noch als DOM Parser angelegt ist, werde ich eine Zwischenlösung demnächst implementieren, damit man große Dateien öffnen, aber dabei direkt einen Knotenpfad mitgeben kann, so dass die Lib alles überspringt und ab dem gefundenen Knoten die Struktur ab diesem parst bis dieser wieder geschlossen wird. Damit sollte sich die Verarbeitung von großen Dateien ohne eine Umstellung von DOM zu SAX verarbeiten lassen und grundlegend ändert sich vom Interface nichts. Auch werde ich dazu das MMF nochmal besser umstellen, da er bisher immer das gesamte File mappt und nicht den Teil den er liest/schreibt.

Nur mal so als Info zur nahen Zukunft. Also es geht voran...

[moelski]

Thumbs up :thumb: