XML effizient analysieren

Antwort erstellen

BBCode ist eingeschaltet
[img] ist ausgeschaltet
[url] ist eingeschaltet
Smileys sind ausgeschaltet
Die letzten Beiträge des Themas
   

Ansicht erweitern Die letzten Beiträge des Themas: XML effizient analysieren

Re: XML effizient analysieren

von Karolus » Mi, 17.02.2016 22:46

Hallo
Hast Du eine Antwort in Basic?
Nee, `lxml.etree` ist ja eine python-lib, und da hab ich gestern schon einige Haare verloren bis ich diesen verflixten xml-Kram ein wenig kapiert hab, das tue ich mir jetzt nicht nochmal mit den kruden api-methoden an.

Wenn ich in der Richtung mehr machen müsste würde ich einen Blick auf odfpy werfen.

Re: XML effizient analysieren

von Stephan » Mi, 17.02.2016 20:50

Ja das steht doch im node:... text:anchor-type="page"


oh je bin ich unaufmerksam. Ja, stimmt das steht dort und dessen war ich mir eigentlich auch bewusst.

Du hast somit völlig recht, zumal dieses Herangehen ja schon im Grundsatz besser ist, denn damit werden automatisch wirklich nur die richtigen draw-frame erfasst.
im Beispielscode oben frage ich diese Eigenschaft ab mit der Zeile
Hast Du eine Antwort in Basic? Probieren brauchst Du nicht das kann ich auch selbst, also nur wenn Du es direkt weist. (Das quasi Rahmenmakro für den Zugriff auf die Nodes steht oben im Thread)



Gruß
Stephan

Re: XML effizient analysieren

von Dreh-Gel » Mi, 17.02.2016 14:51

Hallo Stephan,
Stephan hat geschrieben:@Dreh-Gel

Deine Aussagen öffnen mir die Augen das es mit Reg-Ex ganicht bzw. nur sehr sehr kompliziert geht (bisher war ich der Meinung es ginge relativ leicht, meine Gründe Reg-Ex eher nicht zu wollen waren Andere)
Ganz generell: RegEx sind dann gut, wenn es sich um eine "Reguläre Grammatik" handelt, das ist der am wenigsten komplexe Fall der Chomsky Hierarchie. Das ist bei XML-Dateien generell nicht der Fall. Genau so eignen sich RegExe nicht zum Parsen von HTML. Jedenfalls nicht den gesamten Sprachumfang. Allerdings gelegentlich will man gar nicht XML oder HTML parsen, sondern nur ein paar Informationen rausholen. So wie bei Dir. Dann kanns durchaus gehen.

Kurz gesagt, wenn du geschachtelte Regeln hast, zb. Draw-Frame im Draw-Frame, dh man muss das Ende-Tag dem Anfangs-Tag zuordnen, (also Schachtelung oder Sequenz unterscheiden) dann geht das über einen RegEx hinaus und man muss tricksen, bzw den Rest des Parsers um den RegEx drumherum schreiben. Geht es nur ein bisschen über die Reguläre Grammatik hinaus, dann kanns noch gehen, aber es wird schnell kompliziert. Es gibt ja XML-Parser, sei es der aus Open Office oder SAX. Leider habe ich mit denen keine Erfahrungen.

Hat man jedoch einen Sprachteil, der nicht geschachtelt ist oder es gibt sonstige Vereinfachungen, dann können RegExe doch in Betracht kommen. Das hängt davon ab, welcher Grammatik der erzeugte Text entspricht. Der OpenOffice Generator wird nicht den gesamten Sprachumfang von XML erzeugen, dh dass auch der Parser einfacher ist. Allerdings muss man dazu wissen, was der Generator nun genau erzeugt und ggf überprüfen, ob das in der nächsten Version auch noch so ist.
Stephan hat geschrieben: nochmals zur Erklärung, das RegEx müsste (im ersten Schritt) folgenden (hier allgemein codiert/beschrieben) Abschnitt finden (rot markiert):

<draw:frame [...] </draw:frame> [...] <draw:frame [...] </draw:frame> [...] <text:p> [...] </text:p>

dürfte aber NICHT Folgenden finden (die Rotmarkierung betrifft hier nur das was man wohl FÄLSCHLICH als zu finden ansieht):

<draw:frame [...] <draw:frame [...] </draw:frame><text:p> [...] </text:p> [...] </draw:frame>

Gruß
Stephan
Hier sind geschachtelte Draws möglich. Das geht über einen RegEx hinaus. In deinem Beispiel ganz oben hast du geschrieben:
<!-- Abschnitt B -->
Das hätte man sehr gut mit RegEx erkennen können. Aber sowas ist nicht im Text drinnen. Man könnte über RegExe nachdenken, wenn man sowas reinkriegen könnte. Zb wenn man wüsste, in welcher Reihenfolge er alle Draws nacheinander in die Datei schreibt und man wüsste, was man tun muss, um danach ein Element mit einem bestimmten Namen zu erzeugen. Ich würde schon erwarten, dass das möglich sein sollte. Wie das mit dem Aufwand ist, ist aber eine andere Frage.

Aber das hängt alles davon ab, was du vor hast, wo die Dokumente herkommen und wie langlebig und stabil die Lösung sein soll.

In Summe scheint mir, dass Axels und Karolus' Vorschlag der bessere und langlebigere ist. Wenn die Schachtelung so ist und eventuell noch andere Unwägbarkeiten im Generator sind, dann ist es sicherer über das Objektmodell zu gehen.

Gruss
DG

Gerade erst gelesen:
Stephan hat geschrieben:Oder die faktische Gesamtaufgabe (nicht alles aber 99% davon):
wie mache ich aus den content.xml mehrerer odt-Dokumente eine content.xml die zu einer Darstellung des Gesamtdokumentes führt als würden die aneinandergereihten Teildokumente am Bildschirm so aussehen als verhielten sie sich als DTP-Dokumente, d.h. absolut verankerte Elemente werden an den nun quasi neuen, richtigen Positionen dargestellt.
Du willst nicht nur Informationen extrahieren, sondern auch noch ein neues Dokument generieren, syntaktisch und semantisch richtig zusammenbauen und es geht um ziemlich viel Text. Karolus hat recht; das geht definitiv deutlich über RegEx hinaus.

Re: XML effizient analysieren

von Karolus » Mi, 17.02.2016 12:27

Hallo

Code: Alles auswählen

    if elem.get('{%s}anchor-type'%ns['text']) == 'page':
das erklär ich nochmal ausführlicher - am Anfang der xml-Datei befindet sich ein mapping von `kurzen_namen` auf vollständige "bezeichner" hier mal etwas formatiert:

Code: Alles auswählen

xmlns:office= "urn:oasis:names:tc:opendocument:xmlns:office:1.0" 
xmlns:style= "urn:oasis:names:tc:opendocument:xmlns:style:1.0"
xmlns:text= "urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0"
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0"
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0"
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0"
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0"
xmlns:math="http://www.w3.org/1998/Math/MathML"
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0"
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0"
xmlns:ooo="http://openoffice.org/2004/office"
xmlns:ooow="http://openoffice.org/2004/writer"
xmlns:oooc="http://openoffice.org/2004/calc"
xmlns:dom="http://www.w3.org/2001/xml-events"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:rpt="http://openoffice.org/2005/report"
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:grddl="http://www.w3.org/2003/g/data-view#"
xmlns:tableooo="http://openoffice.org/2009/table"
xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0"
office:version="1.2"
grddl:transformation="http://docs.oasis-open.org/office/1.2/xslt/odf2rdf.xsl"
elem.get(...) benötigt als Argument diesen vollen Bezeichner zum Namen `Text` eingefasst in {}geschweiften klammern und gefolgt von Variablen-namen selbst.

Code: Alles auswählen

'{%s}anchor-type' %ns["Text"] #ersetzt `%s`durch den Bezeichner zu `Text` aus dem mapping oben 

Re: XML effizient analysieren

von Karolus » Mi, 17.02.2016 11:32

Hallo
Falls Du also ein anderes Kriterium kennst wie sich in einer Content.xml eindeutig die "An der Seite" verankerten draw-frame (und NUR diese) identifizieren lassen wäre das prima.
Ja das steht doch im node:... text:anchor-type="page"

im Beispielscode oben frage ich diese Eigenschaft ab mit der Zeile:

Code: Alles auswählen

...
    if elem.get('{%s}anchor-type'%ns['text']) == 'page':
        ...

Re: XML effizient analysieren

von Stephan » Mi, 17.02.2016 10:12

Du suchst nach den`text:p` tags die unmittelbar auf `draw.frame` tags folgen die wiederum an der Seite verankert sind?
jein. Ich suche die draw.frame die "An der Seite" verankert sind und text:p ist nur das Unterscheidungskriterium dafür das ich diejenigen draw.frame habe die ich will.

Falls Du also ein anderes Kriterium kennst wie sich in einer Content.xml eindeutig die "An der Seite" verankerten draw-frame (und NUR diese) identifizieren lassen wäre das prima.
@Stephan: egal was du jetzt eigentlich machen willst, versuch es nicht per RegEx und wenns unbedingt BASIC sein muss dann folge den Vorschlägen von Axel Richter
So ist auch mein Gefühl, ich bin nur damit bisher nicht weitergekommen, denn ich schaffe es bisher nur durch die Nodes zu 'interieren' kriege aber nicht den 'Text innerhalb der Nodes'.

Was ich brauche ist eine Lösung um die einzelnenen zutreffenden draw-frame-Abschnitte zunächst in eine Variable zu kriegen, z.B. also:

<draw:frame draw:style-name="fr3" draw:name="Grafik1" text:anchor-type="page" text:anchor-page-number="1" svg:x="12.966cm" svg:y="3.625cm" svg:width="1.789cm" svg:height="1.143cm" draw:z-index="2"><draw:image xlink:href="Pictures/10000000000004000000030010393590.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/></draw:frame>

(die Teile "<draw:frame" und "</draw:frame>" können auch entfallen denn ich weiß ja das sie da sind)


Oder etwas erweitert damit Du es besser verstehst (diese Erweiterung ist aber nicht Teil meiner ursprünglichen Frage):

Ich will in allen draw-frame-Abschniten die meinen Kriterien entsprechen die Tags draw:z-index ändern, so das alle draw:z-index-Tags 'gegeneinander konsistent' sind.

Verbal beschrieben:
öffne ein odt-Dokument das einen an der Seite verankerten Rahmen enthält in OpenOffice, wähle nun Einfpügen-Datei (imm menü) und wähle die Datzei die schon geöffnet ist.
Nun wird der Inhalt der Datei nochmal an die offene datei gehängt, aber die Rahmen liegen übereinander. WEnn man nun die Datei speichert und in der content.xml die Tags draw:z-index und page-number bearbeitet kann man die Rahmen in die 'richtige' Position bringen. (richtige in '', weil es hier kein richtig und falsch gibt sondern richtig nur die irrige menschliche Erwartung meint das Fliesstexte sich verhalten sollen wie DTP-Texte)


Oder die faktische Gesamtaufgabe (nicht alles aber 99% davon):
wie mache ich aus den content.xml mehrerer odt-Dokumente eine content.xml die zu einer Darstellung des Gesamtdokumentes führt als würden die aneinandergereihten Teildokumente am Bildschirm so aussehen als verhielten sie sich als DTP-Dokumente, d.h. absolut verankerte Elemente werden an den nun quasi neuen, richtigen Positionen dargestellt.

(Das Ganze darf deshalb nicht auf 'odt-Ebene' stattfinden sondern muss auf 'content.xml-Ebene' getan werden weil auf odt-Ebene letztlich das Rendern des Dokuments nicht völlig zu unterdrücken ist und das bei vielen (hundert, tausend) aneinanderzureihenden Dokumenten zuviel Zeit braucht.
Möglicherweise ist das mit dem Rendern allein ungenau beschrieben dann sei gesagt das sich OO/LO einfach nicht mehr verlässlich stabil verhalten, weil das Ganze unter Praxisbedingungen funktionieren muss und es nicht reicht wenn das bei einer gerade frisch geöffneten soffice-Sitzung gerade so noch stabil läuft.)




Gruß
Stephan

Re: XML effizient analysieren

von Stephan » Mi, 17.02.2016 09:41

@Dreh-Gel

Deine Aussagen öffnen mir die Augen das es mit Reg-Ex ganicht bzw. nur sehr sehr kompliziert geht (bisher war ich der Meinung es ginge relativ leicht, meine Gründe Reg-Ex eher nicht zu wollen waren Andere)


nochmals zur Erklärung, das RegEx müsste (im ersten Schritt) folgenden (hier allgemein codiert/beschrieben) Abschnitt finden (rot markiert):

<draw:frame [...] </draw:frame> [...] <draw:frame [...] </draw:frame> [...] <text:p> [...] </text:p>

dürfte aber NICHT Folgenden finden (die Rotmarkierung betrifft hier nur das was man wohl FÄLSCHLICH als zu finden ansieht):

<draw:frame [...] <draw:frame [...] </draw:frame><text:p> [...] </text:p> [...] </draw:frame>


Gruß
Stephan

Re: XML effizient analysieren

von Stephan » Mi, 17.02.2016 09:39

Es ist eigentlich schade das Du keine Beispieldatei angehängt hast, aber auch so lässt sich damit arbeiten.
eigentlich habe ich eine Beispieldatei, denn die 'zitierte' Datei kann ja doppelt genuztzt werden, speichere sie ab und Du hast eine Beispieldatei. (Das war auch Sinn der Sache um mir zu ersparen einmal die DAtei sichtbar zu 'zitieren' damit sie meine Aussage illustriert und sie zweitens in Kopie beizufügen das man damit arbeiten kann.)
Aber ob das ein Leerzeichen ist, bezweifle ich jetzt doch mal im aktuellen Falle.
Im aktuellen Falle folgt sichtbar kein Leerzeichen, aber das muss nicht in allen Fällen so sein. Sorry, nur ich weiß auch nicht wie ich mich verhalten soll um ein Problem welches generell zu sehen ist bestmöglich zu verdeutlichen, ich habe eine Beispieldatei zur Ansicht beigefügt damit das Ganze leichter verständlich ist, ABER die Beispieldatei beschreibt nur einen konkreten Fall und nicht alle möglicherweise vorkommenden Fälle.
• Ein Draw-Frame beginnt immer mit "<draw:frame>" und endet immer mit "</draw:frame>".
ja
• Auf das Ende eines Draw-Frame folgt mal ein weiteres Draw-Frame "</draw:frame><draw:frame", und zwar in der gleichen Zeile.
nein, weil eine Zeile irgendwann voll ist und der Draw-Frame dann nicht in derselben Zeile sein kann, außerdem beschreibst Du dass Verhalten von OpenOffice/LibreOffice, das jedoch ist nicht zwingende Vorrausetzung sondern die Formatdefinition

Letztere aussage hört sich spitzfindig an, ist es aber nicht. Ich selbst hatte diesbezüglich mit den Programmieren von OOo einmal eine diskussion weil ich bemerkte das bei exakt gleichen DAteien die content.xml leicht verschieden aussehen können und die Aussage der Entwickler dazu war eindeutig, nämlich das es kein Fehler ist solange es nicht gegen die Formatdefinition verstösst.
z.B.
wenn ich in eine, ansonsten gleiche, content.xml eine leere Zeile einfüge (also auf XML-Ebene leer, nicht die XML-DEfinition für die Anzeige einer solchen ZEile bzw. Absatz im Dokument) dann ist das xml verändert ohne das sich die Darstellung des Dokuments ändert.
• Oder auf das Ende eines Draw-Frame "</draw:frame>" folgt ein Zeilenumbruch mit anschließendem "<text:p>".
• Oder aber auf das Ende eines Draw-Frame "</draw:frame>" folgt unmittelbar ein "<text:p>"
ja, aber das sind nicht alle denkbaren Fälle
• Und ergänzend:
• Das Ende einer Draw-Frame Zeile endet entweder mit "draw:z-index="0">" plus Zeilenumbruch.
• Oder es endet mit "draw:z-index="2"><draw:image/>" plus anschließendem Zeilenumbruch.
Nein. Denn das sind nur die zufällig in der Beispieldatei auftretenden Fälle.
Denn was willst Du nun wirklich genau?
Es kann in einem Dokument viele Draw-Frame-Abschnitte geben, ich suche jedoch nur diejenigen Abschnitte die sich vor dem Teil des XML befinden, welcher den Fliesstextinhalt des Dokuments kodiert, also nur die Draw-Frame-Abschnitte die statisch verankerte Objekte beschreiben (=Verankerung "An der Seite").

(Ich suche also NICHT die Draw-Frame-Abschnitte die Objekte mit Verasnkerung "Am Zeichen", "Als Zeichen" und "Am Absatz" und ggf. "Am Rahmen" beschreiben)

Deine 'Verwirrung' entsteht wo daraus das Du bisher nicht verstandedn hast das meine verbale Defnition (die die Du zitiert hast) deshalb so ist wie sie ist weil es auch innerhalb der Draw-Frame-Abschnitte den <text:p-Tag geben kannn, aber dieser Tag nicht gemeint ist.

z.B. genügt das Folgende der Definition '"<text:p" folgt auf "</draw:frame>"', aber trotzdem ist es NICHT das was ich suche weil hierbei "<text:p" gleichzeitig innerhalb eines Draw-frame-Abschnitts ist:

<draw:frame [...] <draw:frame [...] </draw:frame><text:p> [...] </text:p> [...] </draw:frame>



Gruß
Stephan

Re: XML effizient analysieren

von Karolus » Mi, 17.02.2016 01:16

Hallo

Du suchst nach den`text:p` tags die unmittelbar auf `draw.frame` tags folgen die wiederum an der Seite verankert sind?
Richtig? - oder war das andersrum.

Egal, ich hab mich mal mit schwierigem Stoff aus `lxml` befasst, dabei ist jetzt erstmal dieser Entwurf entstanden:

Code: Alles auswählen

from lxml import etree

f = etree.parse("stephan.xml")
root = f.getroot()
ns = root.nsmap

drawnodes = root.findall(".//draw:frame", ns)
ptextnodes = root.findall(".//text:p", ns)
out = []
for elem in drawnodes:
    if elem.get('{%s}anchor-type'%ns['text']) == 'page':
        nexxt = elem.getnext()
        out.append(nexxt)
        
schnittmenge = list(set(ptextnodes) & set(out))
for textnode in schnittmenge:
    print(textnode.values()) 
@Stephan: egal was du jetzt eigentlich machen willst, versuch es nicht per RegEx und wenns unbedingt BASIC sein muss dann folge den Vorschlägen von Axel Richter

Re: XML effizient analysieren

von Dreh-Gel » Di, 16.02.2016 14:30

Stephan hat geschrieben: ich habe jetzt beide reguläre Ausdrücke ausprobiert und beide funktionieren nicht wie gewünscht.

Der erste Ausdruck funktioniert dann eingeschränkt wenn ich verwende:
(<draw:frame draw:.*?/draw:frame><text:p)

was aber im praktischen Gebrauch viel zu unzuverlässig wäre weil es vorausetzt das das Ende des gesuchten Textes immer begrenzt wäre durch:
"/draw:frame><text:p"
schon ein zusätzliches Leerzeichen:
"/draw:frame> <text:p"
führt zum Versagen des regulären Ausdrucks.
Du hast recht. Das ist eines der Probleme bei der Lösung mit Regulären Ausdrücken. Wenn da ein Leerzeichen sein darf, dann muss das auch im RegEx berücksichtigt sein. [ ]* bedeutet Null oder mehrere Leerzeichen. \s ist ein Whitespace, also auch Zeilenumbruch oder Tab. Das könnte man mit \s* berücksichtigen. Die Frage ist, welche Konstrukte vorkommen können. Solange es nur Leerzeichen oder Wortgrenzen sind, lassen sich recht einfach berücksichtigen.

(<draw:frame draw:.*?/draw:frame>\s*<text:p)

Schwieriger würde es, falls doch irgend ein <text:p innerhalb von Abschnitt B vorkommen könnte.
Stephan hat geschrieben: Außerdem ist es ja das eigentliche Ziel im ersten Schritt den Textabschnitt zu finden der begrenzt ist durch vorne das erstmalige Auftreten von "<draw:frame" und hinten durch das erstmalige Auftreten von "<text:p" außerhalb eines Tags <draw:frame [...]> [...] </draw:frame>.

Wer kann mir bei den regulären Suchausdrücken helfen?

Gruß
Stephan
Oh, AUßERHALB eines Draw-Frames. Das heißt, der RegEx müsste erkennen, ob er sich innerhalb eines Draw-befindet. Das geht an die obere Grenze dessen, was ein RegEx leisten kann. Man kann das zb. machen, in dem man alle Draw-Frames findet (und deren Start-und Endposition) und anschließend alle Text-Frames und deren Start-und Endposition. Das war jetzt mein erster Schuss und bestimmt gehts auch noch einfacher. Wichtig wäre es natürlich noch zu wissen, ob nicht noch weitere Bedingungen für das Ende von Abschnitt B ergeben. Außerdem könnte es ja sein, dass man innerhalb des Dokuments dafür sorgen könnte, dass etwas hineingeschrieben wird, mit dem man das Ende von Abschnitt B erkennen kann. Zb. als letztes ein Objekt mit einem bestimmten Namen. Das würde die Sache wieder leichter machen.

Sollte das nicht der Fall sein, dann müsste man um die RegExe was programmieren. Klar ist das portierbar, aber eine 1:1 Kopie wird nur dann gehen, wenns Open Office ist UND Open Office die RegExe ausreichend unterstützt.

Ich selbst hab mir ein paar Testfunktionen geschrieben, mit denen ich mir RegExen rumspielen kann und ein Formular zum leichten Ändern und natürlich muss man auf eine Datei zugreifen können, die man einliest usw. Dann kann man in dem RegEx durch Klammern innerhalb eines Matches ein Submatch bekommen. Zb. finde <draw ... bis /draw> und gib mir den Ihnalt, also ohne die Draw-Tags. Das ist syntaktisch bei verschiedenen Sprachen etwas unterschiedlich.

Ich kann dir mit Regulären Ausdrücken helfen.
Die Programmiersprache macht schon was aus,
Ob RegEx eine schöne Lösung ist und wie viel Aufwand es ist, hängt von deinen Dokumenten ab ...

Edit: hab noch eine Testdatei hinzugefügt, die einen regulären Ausdruck über das Dokument laufen lässt. Schön isses noch nicht, aber kann ja noch werden.
Dateianhänge
xmltest.odt
(27.77 KiB) 193-mal heruntergeladen

Re: XML effizient analysieren

von balu » Di, 16.02.2016 13:56

Hallo Stephan,

ein sehr interessantes Problem das Du da hast. Mal schaun ob ich dir auf meine Art und Weise behilflich sein kann.

Es ist eigentlich schade das Du keine Beispieldatei angehängt hast, aber auch so lässt sich damit arbeiten.

Der gepostete xml Inhalt ist so natürlich extrem schwer zu lesen. Also habe ich eine Blanko odt erstellt, entzippt, die content.xml durch deine Passage ersetzt, gespeichert, gezippt und dann in OOo 3.2.1 angeschaut. Dadurch bekam ich ein besseres Verständnis um was es geht, da ich jetzt ein Textdokument vor mir hatte.

Aber da fiel mir wieder ein, das dein xml Inhalt irgendwie komisch aussah. Also in den Optionen (Laden/Speichern Allgemein) nachgeschaut, und die Option "ODF Format auf Größe optimieren" das Häkchen rausgenommen. Danach gespeichert und dann das übliche entzippen und dann die content.xml mir noch mal angeschaut.

Für das anschauen solcher Dateien nehme ich immer wieder sehr gerne den Notepad++, allein schon wegen dem Syntax-Highlighting. Und auf einmal sah der Inhalt schon bedeutend besser aus, war viel leichter zu lesen. Doch ganz zufrieden war ich immer noch nicht, es fehlte eine Kleinigkeit. Und richtig! Es fehlte die Anzeige von Steuerzeichen, wie z.B. Zeilenumbruch (LF). Also diese Anzeige aktiviert, und "Taraaa!", schon besser. Und mit eingeschaltetem "Automatischem Zeilenumbruch" im Notepad++ war ich nun enlich zufrieden. :)

Hier jetzt mal ein Screenshot vom Notepad++
xml-screenshot_0.png
xml-screenshot_0.png (89.12 KiB) 8330 mal betrachtet
was aber im praktischen Gebrauch viel zu unzuverlässig wäre weil es vorausetzt das das Ende des gesuchten Textes immer begrenzt wäre durch:

"/draw:frame><text:p"

schon ein zusätzliches Leerzeichen:

"/draw:frame> <text:p"

führt zum Versagen des regulären Ausdrucks.
Teilweise hast Du recht, aber teilweise hast Du auch unrecht.
Denn das ende vom Draw-Frame endet wohl immer mit "/draw:frame>", aber nicht immer folgt ein "<text:p". Es kann ja auch sofort ein neues Draw-Frame folgen, wie es im aktuellen der Fall ist "</draw:frame><draw:frame". Also da hast Du recht.

Aber ob das ein Leerzeichen ist, bezweifle ich jetzt doch mal im aktuellen Falle. Denn wie auf dem Screenshot (hoffentlich) zu sehen ist, ist das kein Leerzeichen sondern ein Zeilenumbruch.
Da habe ich eben gesehen, das es doch noch die Kombination "</draw:frame></text:p>" und zwar in einer Zeile gibt. Leider nicht auf dem Screenshot zu sehen.

Wie auch immer. Ich glaube eigentlich fest daran, das dieser Zeilenumbruch die Suche mittels reguläre Ausdrücke stört, irretiert.


Noch mal meine Beobachtung eindeutig zusammengefasst.
  • Ein Draw-Frame beginnt immer mit "<draw:frame>" und endet immer mit "</draw:frame>".
  • Auf das Ende eines Draw-Frame folgt mal ein weiteres Draw-Frame "</draw:frame><draw:frame", und zwar in der gleichen Zeile.
  • Oder auf das Ende eines Draw-Frame "</draw:frame>" folgt ein Zeilenumbruch mit anschließendem "<text:p>".
  • Oder aber auf das Ende eines Draw-Frame "</draw:frame>" folgt unmittelbar ein "<text:p>"
  • Und ergänzend:
  • Das Ende einer Draw-Frame Zeile endet entweder mit "draw:z-index="0">" plus Zeilenumbruch.
  • Oder es endet mit "draw:z-index="2"><draw:image/>" plus anschließendem Zeilenumbruch.
Daraus folgt dann, das ich aus dieser deiner Aussage nicht wirklich schlau werde:
In "Abschnitt B" müssen alle "<draw:frame [...]> [...] </draw:frame>" gefunden und zur weiteren Bearbeitung zwischengespeichert werden.
Der Beginn von "Abschnitt B" ist begrenzt durch das erste Auftauchen von "<draw:frame [...]>" und das Ende ist unmittelbar vor dem ersten Aufttauchen von "<text:p [...]>" (auf gleicher Hirarchieebene wie "<draw:frame [...]>").
Denn was willst Du nun wirklich genau?
  • Willst Du alle Draw-Frames?
  • Oder willst Du nur die Draw-Frames die vor einem "<text:p [...]>" stehen, egal ob mit vorherigem Zeilenumbruch oder ohne?
Ist alles ein wenig irretierend, so das ich jetzt selbst den Überblick verloren habe. :roll:
Aber vielleicht solltest Du deine Suchstrategie irgendwie überdenken, und zwar so, das auch Zeilenumbrüche mit berücksichtigt werden.

Vielleicht konnte ich dir eine andere Sicht auf die Lage verschaffen.



Gruß
balu

Re: XML effizient analysieren

von Stephan » Di, 16.02.2016 10:04

unter Windows?


nein, leider unter beliebigen Betriebssystem
ich habe ein paar Dinge mit Regulären Ausdrücken mit VBS - Windows probiert. Auch die anderen Funktionen mit entzippen, usw. könnte man scripten - Auch wenn VBS/HTA ein bisschen angestaubt ist, aber es sollte schnell genug sein. Nur Lookbehind geht in VBS nicht, sollte aber verschmerzbar sein. RegEx in Open Office hab ich noch nicht ausprobiert, auch nicht unter Dotnet. Aber zumindest unter Dotnet sollte alles gehen. Dort sind auch schwerere Geschütze möglich (ParserGenerator).
ich sehe keinen Grund hier auf VBS oder andere Script-/Programmiersprachen zurückzugreifen, denn das Ganze funktioniert auch mit Basic und da die eigentliche Suche ja über vorgegebene API-Routinen erfolgt ist das an dieser Stelle mutmaßlich auch nicht zu langsam.

Das ich hingegen Basic nutzen will ist nur der Tatsache geschuldet das es die einzige Programmiersprache ist die ich selbst unter OpenOffice direkt anwenden kann. Prinzipiell spräche nichts gegen Python, Java, C++ & Co. nur kann ich selbst damit nicht umgehen und was ich hier im Thread frage ist ja nur ein Teil der Gesamtaufgabe d.h. auch eine Komplettlösung für dieses Teilproblem müsste ja dann weiter verarbeitet werden, was ich nur in Basic kann.


Gruß
Stephan

Re: XML effizient analysieren

von Stephan » Di, 16.02.2016 09:55

hast du schon einen Regulären Ausdruck probiert? Ich war schon mal etwas fitter darin. Aber hier ein Ansatz:
mit: [...]
ich habe jetzt beide reguläre Ausdrücke ausprobiert und beidfe funktionieren nicht wie gewünscht.

Der erste Ausdruck funktioniert dann eingeschränkt wenn ich verwende:

(<draw:frame draw:.*?/draw:frame><text:p)

was aber im praktischen Gebrauch viel zu unzuverlässig wäre weil es vorausetzt das das Ende des gesuchten Textes immer begrenzt wäre durch:

"/draw:frame><text:p"

schon ein zusätzliches Leerzeichen:

"/draw:frame> <text:p"

führt zum Versagen des regulären Ausdrucks.

Außerdem ist es ja das eigentliche Ziel im ersten Schritt den Textabschnitt zu finden der begrenzt ist durch vorne das erstmalige Auftreten von "<draw:frame" und hinten durch das erstmalige Auftreten von "<text:p" außerhalb eines Tags <draw:frame [...]> [...] </draw:frame>.


Wer kann mir bei den regulären Suchausdrücken helfen?



Gruß
Stephan

Re: XML effizient analysieren

von Dreh-Gel » Mo, 15.02.2016 09:28

Stephan hat geschrieben: Ich muss nochmal nachdenken ob mir dieses Vorgehen vielleicht doch gefallen könnte.


Gruß
Stephan
Hallo Stephan,

unter Windows?
ich habe ein paar Dinge mit Regulären Ausdrücken mit VBS - Windows probiert. Auch die anderen Funktionen mit entzippen, usw. könnte man scripten - Auch wenn VBS/HTA ein bisschen angestaubt ist, aber es sollte schnell genug sein. Nur Lookbehind geht in VBS nicht, sollte aber verschmerzbar sein. RegEx in Open Office hab ich noch nicht ausprobiert, auch nicht unter Dotnet. Aber zumindest unter Dotnet sollte alles gehen. Dort sind auch schwerere Geschütze möglich (ParserGenerator).

Gruss
DG

Re: XML effizient analysieren

von Stephan » Mo, 15.02.2016 06:34

ich weiß zwar nicht, was Du da genau vor hast


ich will sehr große Dokumente ändern/erweitern und wenn ich das auf odt-'Basis' mache ist das faktisch immer dadurch verlangsamt das OO die Dokumente bei Änderungen neu rendert, was ich in der GUI noch unterdrücken kann aber spätestens beim Speichern nicht mehr.

Ich schaue mir Deine HInweise noch genauer an, Diese gehen in die Richtung die ich wollte, mit der ich bisher nur nicht zurechtkam.


Gruß
Stephan

Nach oben