xpath Parser

[Wildcard]

Hi!

Das Projekt an dem ich arbeite bietet dem Anwender an einer bestimmten Stelle die
Möglichkeit xpath befehle zu verwenden.
Das Problem ist jetzt, das er dabei unterstützt werden soll, also das schon bei der Eingabe
die Syntax überprüft wird. Da man xpath aber schon fast eine Programmiersprache nennen
kann ist das leichter gesagt als getan.
Also muss IMO ein Scanner und ein Parser her.
Ich hatte jetzt erstmal an JLex gedacht (hab ich noch dunkel von der Uni in erinnerung),
muss jedoch zugegeben das ich davon keine Ahnung mehr habe.
Die Frage ist jetzt ob JLex eine sinnvolle Möglichkeit ist, und wenn ja
währe ich um jeden Tip/Link dankbar wie man an so etwas rangeht.

 

[0xdeadbeef]

Kenne mich jetzt nicht mit xpath aus und bin auch kein Fan von Parsergeneratoren. Grundsätzlich sollte aber folgendes Vorgehen möglich sein.

String in Tokens zerlegen (Token = Variable/Operator/Keyword etc.). Üblicherweise gibt es in einer Sprache Delimiter, die Tokens voneinander trennen (aber durchaus selber Tokens oder Bestandteile davon sein können). In Java gibt beispielsweise folgende Delimiter: Whitespace, Zeilenumbruch, Operatoren, Klammern, Komma, Semikolon. Für die weitere Verarbeitung ist es meist sinnvoll/notwendig, die Stringdarstellung in eine Form von Syntaxbaum zu überführen. Im einfachsten Fall ein Stack. Die Tokens müssen natürlich auch identifiziert werden. Beispiel Java: numerische Literale beginnen mit Zahl oder "." (Sonderfälle Hexzahlen, "e" usw. beachten), Stringliterale mit '"' etc. Erlaubte Schlüsselwörter/Operatoren usw. muß man mit internen Listen überprüfen etc.
Bei komplexen Ausdrücken (Prioritäten usw.) kann eine rekurisve Erzeugung des Syntaxbaums sinnvoll sein. Bei einem klassichen Parser würde man danach zur Auswertung schreiten, aber Dir geht es ja nur um die Syntaxprüfung.

In Deinem Fall wäre das letzte Token unsicher. Anhand des Syntaxbaums sollte sich aber klarstellen lassen, welche Art von Token es es ein kann (falls das bei xpath überhaupt zweifelhast ist). Dann könnte man mit einer internen Liste prüfen, welche möglichen Werte es annehmen könnte.

Wesentlich mehr ins Detail könnte ich nur mit etwas Kenntnis über xpath gehen, die ich aber leider nicht habe.

Ein spezieller Fall ist natürlich die Erkennung beim Eintippen. Einfacher ist es sicher, den Ausdruck bei jedem Tastendruck komplett neu zu parsen. U.U. wäre es aber perfomanter, einen Zustandsautomaten zu benutzen, der bei jedem Tastendruck geupdatet wird. Bei einem Java-ähnlichen Ausdrucksparser könnte ich hilfreicher sein

 

[Wildcard]

Erstmal vielen Dank für die Anregungen!
Kann gut verstehen warum du kein Fan von Parser Generatoren bist, hab's
ja jetzt am eigenen Leib erfahren. :?
Bin auf den Trichter gekommen das ich den Parser wohl selbst schreiben muss.
Das kleinste Problem sind eigentlich dir Tokens. Das läuft soweit.
War eigentlich immer der Meinung, das man Parser und Auswertung voneinander trennen sollte?
Ich hab hauptsächlich noch meine Schwierigkeiten damit die Grammatiken zu übertragen
und den Syntaxbaum aufzubauen.
Hab jetzt schon diverse Varienten gesehen, ist es besser solche Sachen wie Funktionen
(concat(string, string, ...),contains(string),...) schon beim Parsen durch Symbole zu unterscheiden,
oder sollte man sie als Literal expr werten und erst in der Auswertung weiter unterscheiden
(Funktionstyp, Paramter,...)?

Bei einem Java-ähnlichen Ausdrucksparser könnte ich hilfreicher sein

Wie lang hast du dafür gebraucht? So als ungefähre Aufwandsabschätzung?

 

[Bleiglanz]

Also muss IMO ein Scanner und ein Parser her.

dürfte nicht so einfach sein, versuchs doch erstmal mit xalan, nimm direkt die Klassen aus org.apache.xpath.XPath?

 

[Wildcard]

nimm direkt die Klassen aus org.apache.xpath.XPath

Hier wird soweit ich weiß aber mit dem Kontext eines XML-Dokuments gearbeitet?
Ich möchte den xpath Ausdruck aber isoliert als String betrachten.
Auserdem seh ich noch nicht so ganz wie ich damit unvollständige Ausdrücke wie in
Eclipse vervollständigen kann.

 

[Bleiglanz]

nimm direkt die Klassen aus org.apache.xpath.XPath

Hier wird soweit ich weiß aber mit dem Kontext eines XML-Dokuments gearbeitet?
Ich möchte den xpath Ausdruck aber isoliert als String betrachten.
Auserdem seh ich noch nicht so ganz wie ich damit unvollständige Ausdrücke wie in
Eclipse vervollständigen kann.

ja, das geht natürlich nicht

aber wie willst du was vervollständigen? Soll dein Parser auch noch die DTD/das Schema deines Dokuments "kennen"?

 

[Wildcard]

aber wie willst du was vervollständigen? Soll dein Parser auch noch die DTD/das Schema deines Dokuments "kennen"?

Nein. Da ich keine Auswertung vornehme ist mir der Rest des Dokuments egal.
Im ersten Schritt möchte ich den xpath Ausdruck isoliert betrachten, und die Referenzen
auf Variablen und das Dokument als korrekt annehmen solange sie syntaktisch und
semantisch richtig sind.
Hab mir jetzt überlegt das ich nach dem Zerteilen in Tokens für jedes Token eine Liste mit korrekten
nachfolgetokens erstelle. Wenn eine Klammer kommt möchte ich eine rekursive Funktion starten die
die Klammer, und alle inneren Klammern in ihren Rückgabetyp umwandeln.
Problematisch wird es da allerdings dadurch das ich ja die Paramter der Funktionen mitschleppen müsste.
Bin mir auch nicht sicher ob damit eindeutig sagen kann ob ein Ausdruck korrekt ist,
da diese Methode ja nur mit einem lookahead arbeiten würde.

 

[Bleiglanz]

Das jakarta commons Projekt JXPath
hat schon einen eingebauten Parser/Compiler
dabei, wird aber möglicherweise "zuviele" Ausdrücke
korrekt werten

When JXPath is asked to evaluate an expression for the first time, it compiles it and caches its compiled representation. This mechanism reduces the overhead caused by compilation. However, in some cases JXPath's own caching may not be sufficient- JXPath caches have limited size and they are automatically cleared once in a while.

Here's how you can precompile an XPath expression:


CompiledExpression expr = context.compile(xpath);
...
Object value = expr.getValue(context);

Use compiled expressions if you need to satisfy any of the following requirements:

* There is a relatively small number of XPaths your application works with, and it needs to evaluate those XPaths multiple times.
* Some XPaths need to be precompiled at initialization time for speed.
* The syntax of some XPaths needs to be checked before they are used for the first time.

 

[Wildcard]

wird aber möglicherweise "zuviele" Ausdrücke korrekt werten

nicht weiter schlimm. Ist nicht unbedingt ein Prog für DAU's. Wenn das Gros erkannt wird ist
das völlig ausreichend.
Wenn das klappt würde mir das eine menge Arbeit ersparen.
Werds mir gleich mal ansehen.
THX a lot :toll: