XML analysieren und einlesen

[Bernd Hohmann]

aber ... als ich 12 war, habe ich mich gefreut, als

10 PRINT "64 * 46"
20 PRINT "ergibt"
30 PRINT 64*64

in der letzten Zeile wirklich 4096 ausgegeben hat

Wann war das?

Bernd

Noctarius: Verschoben in diesen Thread aus http://www.java-forum.org/xml-co/145453-neuer-xml-parser-2.html

 

[Marco13]

[ot]
Grob geschätzt ... naja, jedenfalls >20 Jahre her, auf diesen schönen Monitoren die nur "Grün oder nicht Grün" kannten (Hey, da fällt mir ein, ich muß noch eine Alternativantwort für www.java-forum.org/awt-swing-swt/144713-komplett-gruen-schwarzer-filechooser.html schreiben :joke: )
[/ot]

 

[Bernd Hohmann]

[ot]
Grob geschätzt ... naja, jedenfalls >20 Jahre her, auf diesen schönen Monitoren die nur "Grün oder nicht Grün" kannten (Hey, da fällt mir ein, ich muß noch eine Alternativantwort für www.java-forum.org/awt-swing-swt/144713-komplett-gruen-schwarzer-filechooser.html schreiben :joke: )
[/ot]

Grün? Ui! Ich bin erst bei Bernstein eingestiegen - den Titel "Alter Sack" trete ich freiwillig an Dich ab :bae:

Bernd

 

[Robokopp]

Naja also er ist nunmal trotzdem erst 12. Über Sinn und Unsinn wurde ja nun genug geprochen.

Was willst denn du jetzt? Das bezog sich auf den Spruch den ich im selben Post zitiert habe und weder auf das Alter des TO noch auf dessen Projekt. Unglaublich wieviel manche aus smileys raus interpretieren können.

 

[Marco13]

[ot]

Grün? Ui! Ich bin erst bei Bernstein eingestiegen - den Titel "Alter Sack" trete ich freiwillig an Dich ab :bae:

;( Der PC war aber auch schon sehr alt, als ich ihn benutzt habe ueh:

[/ot]

EDITl, um vielleicht noch ein bißchen on-topic zu bleiben: Ich finde auch, dass XML "unbequem" ist. Mit XStream ist das Lesen ja vielleicht recht "kompakt" möglich (wenn auch nicht einfach), aber spätestens beim Schreiben wird's immer kramfpig. Ich habe bisher keine andere praktikable Möglichkeit zur XML-Verarbeitung gefunden, als manuell den DOM-Baum durchzulaufen und mit nodeName, nodeValue und viel geparse die Inhalte daraus zusammenzupflücken :noe: Aber (daran würde der vorgestellte Parser nichts ändern und) es ist eben ein Standard und eine der strukturiertesten, eindeutigsten Möglichkeiten, Objektorientierte Datenstrukturen standardisiert und Menschenlesbar in eine Datei zu bringen. CSV ist für Tabellendaten. Damit irgendeinen Objekt-Baum zu repräsentieren wäre ja unsinnig...

 

[Bleiglanz]

Etwas OT:

Das XML-Bashing ist doch Käse.

Die Rückkehr zu CSV ist eine Einladung zum alten Gehacke, wer kümmert sich schon um Escapes und die Frage, ob ein Eintrag in so einer CSV-Datei Strichpunkte und/oder Anführungszeichen enthält. Dazu kommt das Theater um die Codierung usw.

Zugegeben DTDs waren nicht wirklich leistungsfähig, aber wenn man gelernt hat wie ein Schema funktioiniert und dann mit JAXB den Boilerplate-Code generiert, da gibt es doch nichts zu meckern?

Große Dokumente kann man immer noch mit SAX durchackern, besser als das CSV (das nur auf den ersten Blick Vorteile hat) ist das allemal.

Das Problem dürfte eher sein, dass viele IT Senior Architekten zu blöd sind, korrektes XML zu erzeugen und mit System.out.println herumwursteln.

 

[Marco13]

IT Senior Architekten - bashing ist auch Käse Ich habe JAXB noch nicht in der Praxis verwendet. Der Grund dafür ist, dass nach dem, was ich bisher weiß und gelesen habe, es scheint als sei der Weg über JAXB erstmal NOCH (viel!) komplizierter und aufwändiger und würde zu mehr doppelten Strukturen führen, als wenn man seinen Kram per DOM zerpflückt. Zumindest finde ich Builder, Static Factory Methods und Immutable Classes besser als public Konstruktoren und Pojos/Beans, und falls ich das richtig verstanden habe, kommt man dann kaum drumherum, eine Programmatische Beschreibung des XML-Inhaltes zu erstellen, der dann DOCH wieder manuell auf die eigentlichen Programmstrukturen umgebogen werden muss. Aber mir das mal näher anzusehen steht schon auf der TODO Liste ...

 

[Bleiglanz]

Zumindest finde ich Builder, Static Factory Methods und Immutable Classes besser als public Konstruktoren und Pojos/Beans, und falls ich das richtig verstanden habe, kommt man dann kaum drumherum, eine Programmatische Beschreibung des XML-Inhaltes zu erstellen, der dann DOCH wieder manuell auf die eigentlichen Programmstrukturen umgebogen werden muss.

Daran führt leider kein Weg vorbei, zumindest kenne ich keinen.

Ich will ja eigentlich mit dem XML gar nichts zu tun haben, das sollte vollkommen transparent für mich sein. Brauchen tut man das ja eh nur an Schnittstellen beim Lesen/Schreiben - und oft gibt es dafür fertige Schemas die man direkt in JAXB hineinfüttern kann. Wenn nicht muss sich eins selbst schreiben (eine (!) Datei) und lässt dann JAXB drüberlaufen als Teil des builds. Dann kann man wenigstens mit den Daten arbeiten und kriegt vom eigentlichen "parsing" nichts mehr mit. Dafür nehme ich das erzeugte Java "as is" in Kauf

 

[Marco13]

Ich dachte einen Moment lang, dass XStream interessant sein könnte: Das schreibt und liest beliebige Objekte als XML - ohne Schemadefinition, ohne manuelles parsen, alles automatisch. Für manche Zwecke ist das natürlich sau-cool. Aber für "Langzeitpersistenz"... ???:L ich weiß nicht: Natürlich stehen dann da im XML irgendwelche Klassennamen der Instanzen, von denen die Objekte eben waren. Nichts mehr mit Interfaces und versteckten Implmenentierungen :bahnhof:


@TheCreeper202/Mods: Das hier driftet(e) ja schon weit vom eigentlichen XML-Parser ab (auch wenn es immernoch um XML geht). Vielleicht könnte man überlegen, den Teil seit gestern 21:04 oder Heute 10:29 abzuzwacken, falls TheCreeper202 das wünscht.

 

[pL4Gu333]

und oft gibt es dafür fertige Schemas die man direkt in JAXB hineinfüttern kann. Wenn nicht muss sich eins selbst schreiben (eine (!) Datei) und lässt dann JAXB drüberlaufen als Teil des builds. Dann kann man wenigstens mit den Daten arbeiten und kriegt vom eigentlichen "parsing" nichts mehr mit. Dafür nehme ich das erzeugte Java "as is" in Kauf

[OT]Ich benutze JAXB erst seit kurzem und finde es auch sehr einfach, besonders wenn man sich von XJC die JAVA Klassen per Schema erstellen lässt. Kacke wirds erst, wenn die XML- Dateien zu groß werden, um sie direkt einlesen zu können (z.b. im GB- Bereich). Da hab ich dann mit Stax gearbeitet und jeweils kleinere Teile mit JAXB eingelesen um nicht alles verarbeiten zu müssen (Wenn wer Alternativen hat immer her damit ). Aber irgendwie gefällt mir das noch nicht wirklich . Für kleinere XML finde JAXB aber ganz gut, außer die Annotation Flut aber die hat man ja fast überall[/OT]

 

[Marco13]

Nachdem das jetzt ohnehin ein eigener Thread ist, vielleicht mal die Frage an JAXB-Fans: Sehe ich es richtig, dass es in der Praxis nicht direkt vorgesehen (und insbesondere nicht sinnvoll) ist, JAXB bzw. die automatisch generierten Klassen für etwas anderes zu verwenden, als daraus seine eigentlichen Modellklassen zu bauen? Stimmt es also, dass diese Klassen NUR eine programmatische Repräsentation des XML sind? Die ganzen Strukturen, die durch das Schema und dessen Verarbeitung entstehen, und insbesondere die Annotations WILL (und kann?) man ja nicht in seinen mühevoll minimalistisch-sauber entworfenen Modellklassen haben (die ja sowieso nur Modell-Interfaces sind, und man für das Mapping dann irgendwelche Manuellen Handler schreiben müßte) ...?

 

[pL4Gu333]

Also wie gesagt ich beschäftige mich noch net sehr lang damit, hatte zu dem Thema diesen Post hier gefunden/gelesen :

Do Domain Classes usually get JPA or JAXB Annotations or both? - Stack Overflow

Es soll wohl keine Probleme damit geben wenn man 1 Model dafür verwendet bloß gibt das auf jeden Fall Annotation Chaos

Ich benutze atm auch 2 verschiedene Models... also für JAXB wirklich nur eine Objekt- Repräsentierung des XML. Dazwischen muss dann wieder ein Konverter existieren, was mich auch etwas ankotzt

 

[Marco13]

Kleine Zwischenfrage: Wie stellt man ein, dass das, was von JAXB generiert wird (Kommentare) auf Englisch sind und nicht auf Deutsch?

( :autsch: Da war ja jemand """ganz schlau""" und hat sich """ganz viel Mühe gegeben""" :autsch: Und... warum zum :autsch: findet man dazu nichts (aber wirklich gleich GAR nichts :noe: im Web?!)

 

[pl4gu33]

( :autsch: Da war ja jemand """ganz schlau""" und hat sich """ganz viel Mühe gegeben""" :autsch: Und... warum zum :autsch: findet man dazu nichts (aber wirklich gleich GAR nichts :noe: im Web?!)

Ist der Abschnitt auch auf die Sprache der Kommentare bezogen ?
Also ich find auch mal gar nix dazu ... aber ich schau morgen früh nochmal nach.

 

[Bernd Hohmann]

Das Problem dürfte eher sein, dass viele IT Senior Architekten zu blöd sind, korrektes XML zu erzeugen und mit System.out.println herumwursteln.

Das hab ich jetzt nicht verstanden: Bislang dachte ich, dass die XML Tools dafür sorgen dass korrektes XML erzeugt wird.

Was den "blöden IT Senior Architekt angeht": in 20 Jahren gibts was (angeblich) viel besseres als XML und dann darfst Du dir die dummen Sprüche der Kiddies hier anhören warum Du noch an diesem altertümlichen Format klebst.

Bernd

PS: Mir ist das Wurscht in welchem Format die Daten ankommen - am liebsten aber so, dass ich nur 1 Stunde Arbeiten aber 1 Manntag fakturieren kann und da ist CSV bei dem üblichem Datenkram hier einfach unschlagbar :toll:

 

[Marco13]

Ist der Abschnitt auch auf die Sprache der Kommentare bezogen ?

Jupp, der generiert halt so 'nen Dreck wie

   /**
     * Legt den Wert der links-Eigenschaft fest.
     * 
     * @param value
     *     allowed object is
     *     {@link LinksType }
     *     
     */
    public void setLinks(LinksType value) {
        this.links = value;
    }

aber zwischendrin sind auch einige Teile auf Englisch :autsch:

@Bernd Hohmann: Ich glaube, dazu ist es zu spät. XML ist zu verbreitet, als dass es noch ersetzt werden könnte. Faktisch ist es ja auch so, dass man eine Hierarchische Information kaum anders beschreiben kann (ggf. etwas weniger "verbose" aber dafür mit mehr Sonderzeichen, aber rein konzeptuell). Das ändert aber nichts daran, dass es mit heutigen Mitteln IMHO aufwändig zu verarbeiten ist, und das leichter sein sollte.

 

[Bernd Hohmann]

@Bernd Hohmann: Ich glaube, dazu ist es zu spät. XML ist zu verbreitet, als dass es noch ersetzt werden könnte.

Ich habe in die Zukunft gedacht. Wenn wir beide in Rente gehen ist Bleiglanz dort, wo wir heute sind. Und in der Zwischenzeit wird irgendeine durchs Dorf getriebene Sau tatsächlich die Ziellinie erreichen und die Nachfolge von XML antreten.

Faktisch ist es ja auch so, dass man eine Hierarchische Information kaum anders beschreiben kann (ggf. etwas weniger "verbose" aber dafür mit mehr Sonderzeichen, aber rein konzeptuell). Das ändert aber nichts daran, dass es mit heutigen Mitteln IMHO aufwändig zu verarbeiten ist, und das leichter sein sollte.

Ich habe hier recht selten hierarchische Informationen. Oder besser gesagt: sollte das vorliegen, wirds einfach mit dem dickem Hammer platt geklopft. Habe es hier überwiegend mit Tabellendaten zu tun (also Export von Reports, Import von irgendwelchen Artikellisten, EDI). Das ist entweder CSV (wird dann letztendlich irgendwo in einem Excel-Template ausgewertet) oder sowas wie SEDAS, DTA und Konsorten mit eigenem (Binär)Format wo Datenknauserei angesagt ist.

Natürlich gibt es immer mal Versuche XML einzuführen (insbesondere wenn die IT-Abteilung wieder Frischfleisch eingekauft hat), da es bei bestehenden Datenstrukturen aber nur Kosten und kaum Nutzen bringt fällt das ganz schnell wieder unter den Tisch.

Es gibt paar Anwendungsfälle, wo hier XML tatsächlich zum Einsatz kommt und auch einen Vorteil bietet - aber das liegt eher im Promillebereich.

Bernd

 

[Noctarius]

Jupp, der generiert halt so 'nen Dreck wie

   /**
     * Legt den Wert der links-Eigenschaft fest.
     * 
     * @param value
     *     allowed object is
     *     {@link LinksType }
     *     
     */
    public void setLinks(LinksType value) {
        this.links = value;
    }

aber zwischendrin sind auch einige Teile auf Englisch :autsch:

Sicher, dass die nicht schon im XSD stehen?

 

[pL4Gu333]

also ich hab nun nochmal bei mir geschaut,.... bei mir sind alle Kommentare etc. auf Englisch

 

[Bleiglanz]

Wenn Ihr in Rente geht bin ich schon in der Grube

CSV ist eine Krankheit und funktioniert genau so lange, bis es eben abstürzt. Ich kann mit Leuten, die mir sagen, dass das Daten einlesen "jetzt funktioniert", aber nicht berücksichtigt haben, was passiert, wenn Daten mit Strichpunkten und/oder Anführungszeichen daherkommen nichts anfangen. Es funktioniert halt wenn die Daten so sind "wie bisher" und "so wie die Beispieldaten", was in der Praxis vier Monate später zum Problem wird.

XML ist sicher nicht das Ende aller Formate, aber zumindest hat man eine gewisse Kontrolle und Robustheit (das ist viel wichtiger als alles andere). Daten zeilenweise einlesen, mit String.split(";") auftrennen kann man machen, wenn es schnell gehen muss und eine einmalige Sache ist. Ansonsten ein no go.

OT: Ich verarbeite gerade eine Excel Datei mit 10000 Zeilen, die eine numerische Spalte hat. Die ersten 2000 Zeilen sind wirklich Zahlen, dann hat jemand "8/8/8" eingetragen! Zieht man das Ding mit dem Jet-ODBC Treiber in eine SQL-Datenbank, dann erscheint statt "8/8/8" die Zahl 4 (Grund: Datum-Zahl-Formattier-Wahnsinn). Ich hasse sowas.

 

[Marco13]

@Bernd Hohmann: Wie schon weiter oben gesagt: CSV ist für Tabellendaten, und zu versuchen, so etwas in XML zu pressen, ist mindestens genauso albern, wie zu versuchen, eine Objekthierarchie in CSV darzustellen (außer wenn es "viele" Objekte sind, und man damit quasi eine "Structure of Arrays" repräsentieren will, aber das ist ein Sonderfall).

@Noctarius/pL4Gu333: In der XSD stehen keine Kommentare... und irgendwas spezielles eingestellt habe ich auch nicht. Wie gesagt: In einigen Dateien stehen auch (nur) Englische Kommentare, aber zwischendrin diese Halb-Deutschen Brocken...

 

[gasssssssst]

Hi,

Große Dokumente kann man immer noch mit SAX durchackern, besser als das CSV (das nur auf den ersten Blick Vorteile hat) ist das allemal.

Nicht wirklich: das wahre Problem liegt darin, dass ich XML nämlich nicht mal ohne Umstände parallel verarbeiten kann. CSV (oder noch besser TSV) kann ich einfach alle paar 1000 Zeilen splitten und dann auf meine Nodes verteilen. XML? Kaum eine Chance, es sei denn ich gehe die Datei irgendwie manuell durch und splitte das Dokument bei bestimmten Tags. Wenn ich ganz bescheuert bin bastel ich mir aus den Einzelteilen dann wieder ein neues Dokument von jeweils n XML Nodes auf und verteil die dann wieder auf die Maschinen. In der Zeit hab ich TSV Datei 3mal durchgearbeitet.

CSV ist eine Krankheit und funktioniert genau so lange, bis es eben abstürzt. Ich kann mit Leuten, die mir sagen, dass das Daten einlesen "jetzt funktioniert", aber nicht berücksichtigt haben, was passiert, wenn Daten mit Strichpunkten und/oder Anführungszeichen daherkommen nichts anfangen. Es funktioniert halt wenn die Daten so sind "wie bisher" und "so wie die Beispieldaten", was in der Praxis vier Monate später zum Problem wird.

Das Argument ist Unsinn, wenn ich CSV verarbeite benutze ich einen CSV Parser, genauso wie ich für XML einen XML Parser benutze und mir die Daten nicht mit substring() oder split() raushole, damit ist das Problem schon erledigt. Oder ich bin schlau und benutze direkt TSV und brauche mich um sowas gar nicht mehr zu kümmern.

Es ist kein Wunder, dass für große Daten inzwischen wieder TSV oder CSV Standard für den Datenaustausch/-verarbeitung sind.

 

[Marco13]

Bin ich der einzige, der findet, dass der Vergleich zwischen XML und CSV NOCH unpassender ist, als der zu Unrecht als unpassend verschrieene Vergleich zwischen Äpfeln und Birnen? Ja, beides sind Dateiformate (bzw. Obst), aber ... XML verwendet man für hierarchische Daten, und CSV für tabellarische Daten. Jeweils das andere ist für die jeweils anderen Daten natürlich Bockmist :noe: :bahnhof:

 

[Bernd Hohmann]

Bin ich der einzige, der findet, dass der Vergleich zwischen XML und CSV NOCH unpassender ist, als der zu Unrecht als unpassend verschrieene Vergleich zwischen Äpfeln und Birnen? Ja, beides sind Dateiformate (bzw. Obst), aber ... XML verwendet man für hierarchische Daten, und CSV für tabellarische Daten. Jeweils das andere ist für die jeweils anderen Daten natürlich Bockmist :noe: :bahnhof:

Du siehst das schon richtig.

Mein persönliches Problem besteht darin, dass XML an Stellen eingesetzt wird wo es überhaupt nichts zu suchen hat und nur Nachteile bringt (Ersatz für .ini-Dateien, Massenauslagerung von pseudohierarchischichen Daten). Und dass XML den Finger auf Probleme zeigt, die eher nicht vorhanden sind.

Ordentlich eingesetzt hab ich mit XML überhaupt keine Probleme - rein in den Parser und gut ist. Wenn der Import dann aber 2 Stunden statt 2 Minuten dauert werde ich mäkelig

Vielleicht sollte man mal ein RFC 4711 "XSV" schreiben - eine Mischung aus XML und CSV. Vorne eine XML-Beschreibung der Felder und dann Zeilenweise den Datenschrott wegkloppen.

Bernd

 

[Marco13]

Ja, wie heißt es so schön?

Java is a DSL for converting large XML files into Stack Traces

( Java Language )

Insbesondere der letzte Punkt ist aber recht wichtig: So eine CSV ist ziemlich "nackt". Manchmal hat man nichtmal Spaltennamen, und z.B. den Datentyp einer Spalte festlegen ist nicht möglich - von Wertebereichen und "Missing Value"-Indikatoren ganz zu schweigen. Den Use-Case, eine CSV mit Daten zu haben, und zusätzlich eine XML, wo drinsteht, was in der CSV drinsteht, ist gar nicht unrealistisch.

 

[Kratzer]

Nicht unrealistisch ist eine Möglichkeit es auszudrücken. "Mein täglich Brot" wäre da so meine formulierung

 

[Nametat]

Hey,

ich "wühle" jetzt mal in den Tiefen des Forums und wollte eig. nur wissen, ob eine Möglichkeit gefunden wurde, die Kommentare, die von JAXB automatisch generiert werden, entweder zu löschen oder auf Englisch zu stellen.