Inhalt
Topic:.ZBNF2Xml.
Topic:.ZBNF2Xml..
Informationen lassen sich in XML sehr gut verarbeiten. Für die Erfassung der Informationen ist aber XML-direkt nicht unbedingt die erste Wahl. Programmierer sind es gewohnt, mit flach-textuell Dinge zu formulieren und dann zu compilieren. Dieser Stil ist trotz aller Grafischen Benutzeroberflächen immer noch weit verbreitet. Auch Nicht-Programmierer bevorzugen manchmal die einfache Art etwas zu formulieren und dann die Verarbeitung einem Parser zu überlassen.
Der Zbnf2Xml-Konverter verbindet die Welt der flachtextuellen Formulierungen mit denen von XML. Letzlich ist auch die Verarbeitung beispielsweise von Headerfiles der C-Programmierung zwecks Konvertierung nach XMI, Dokumentation oder Java eine wichtige Anwendung. Aber auch die Generierung dieser Dokumentation ist damit realisiert. Anstatt HTML zu schreiben sind die Informationseinheiten in einfachen Textfiles nach Wikipedia-like Formatierungen enthalten, über Zbnf2Xml und Weiterverarbeitung über XSLT ist dieser hier sichtbare HTML-Text entstanden.
Topic:.ZBNF2Xml.invokeCmd.
Mit dem Java-Programm javadoc:_org/vishia/zbnf/Zbnf2Xml enthalten in download:_xslt.jar oder download:_vishia.jar ist es möglich, mit Hilfe eines ZBNF-Scriptes beliebige textuelle Daten in XML zu wandeln. Liegen diese Daten dann in XML vor, steht der Weiterverarbeitung die Welt der XML-basierenden Verarbeitung offen (XSLT und weiteres).
Der Aufbau des erzeugten XML-Baumes richtet sich unmittelbar nach der Syntax, die im ZBNF-Script angegeben ist. Für die Semantik gilt im ZBNF-Script allgemein, dass die Semantik-Angabe aus beliebigen Zeichen bestehen kann. Für die Konvertierung nach XML sind die Regeln, die für Tagnamen in XML gelten, zu beachten. Dabei gibt es die Möglichkeit, mit bestimmten Semantikangaben die Ausgabe in XML zu steuern.
Der Aufruf erfolgt einfach per Kommandozeile nach folgender Form (Windows-Kommandozeile):
java -cp %XML_TOOLBASE%/xslt.jar;%XML_TOOLBASE%/jdom.jar org.vishia.zbnfXml.Zbnf2Xml -i:input.txt -s:syntax.zbnf -y:output.xml -a:name="value" --report:rpt.txt --rlevel:336
Das Argument -a kann mehrfach auftreten oder nicht vorhanden sein. Mit dem Argument -a ist es möglich, zusätzliche Informationen
in den erzeugten XML-File einzubringen, die weder in der Syntaxvorschrift stehen noch im Input enthalten sind. name ist dabei die Bezeichnung entweder eines XML-Elementes oder in der Form @name die Bezeichnung eines Attributes zum erzeugten top-level-Element.
Für die Konvertierung wird zusätzlich die JDOM-Library benötigt. Diese ist unter Beachtung der Lizenzbestimmungen des Herstellers http://www.jdom.org ebenfalls hier downloadbar: download:_jdom.jar. Beim Aufruf werden inputfile, outputfile und syntaxfile als relativer oder absoluter Pfad angegeben. Die Angabe von Reportfiles ist optional.
Dieser kommandozeilenorientierte Aufruf lässt sich sowohl in eine Graphische Bedienoberfläche einbauen, falls gewünscht, als auch in ein Build-System mit eclipse-ant. Letzteres ist empfehlenswert, wenn mehrere Files zu konvertieren sind.
Topic:.ZBNF2Xml.Semantic.
Es wird ein XML-Element mit dem angegebenem Tag-Namen erzeugt. Der Text oder die Zahl, die der Semantik zugeordnet ist, wird als Inhalt in das Element geschrieben. Wenn es sich um eine Syntaxkomponente handelt, dann wird der darin enthaltene Inhalt mit weiteren Elementen in dieses Element geschrieben.
Das hat fast die gleiche Bedeutung wie die einfache Angabe von tag. Der Unterschied liegt darin, dass in das Element der geparste Text geschrieben wird, wenn kein anderer Inhalt erkannt wird.
Beispielsweise ist das notwendig, bei
[<?whichOption/.> a | b |]
Mit dieser Schreibweise erscheint also entweder a oder b im XML als Wert des Elementes.
Es wird das Element tag erzeugt, aber es wird kein textueller Inhalt hineingeschrieben. Das Element wird in der Regel deshalb erzeugt, weil es sich
um eine Syntaxkomponente handelt, die weitere child-Elemente enthält. Beispielsweise ist das notwendig, bei
{<?tag/> <$=@name> = <$=@value> }
Es wird bei jeder Wiederholung ein Element <tag> erzeugt, dass dann die Attribute name und value bekommt. Mit der Schreibweise <?tag> würde als Text zum Element die Nummer der Wiederholung gespeichert werden, denn das steht in dem erzeugten Parserergebnis.
Es wird ein XML-Element mit dem Namen tag1 und darunter ein weiteres XML-Element mit tag2 erzeugt. Unterhalb dieses Elementes wird der Inhalt gespeichert. Diese Form ist in Sonderfällen notwendig.
Der geparste Text oder Wert wird in das Attribut des neu erzeugten Elementes geschrieben. Das ist eine typische Anwendung.
Der geparste Text oder Wert wird in das Attribut des aktuellen Elementes geschrieben. Das ist eine typische Anwendung.
Der geparste Text wird expandiert nach den Regeln der Konvertierung der Wikipedia-Schreibweise, und zwar unterhalb des dafür erzeugten Elementes tag. Innerhalb des Elementes werden xhtml-Elemente <xhtml:p> und dergleichen angelegt.
Topic:.ZBNF2Xml.syntaxError.
Die Anzeige von Syntaxfehlern ist eine wichtige und interessante Sache, für den Benutzer sollte sie möglichst einfach sein. Wer aber die Syntaxfehleranzeige üblicher C-Compiler kennt, weiß aber, das dies nicht leicht zu bewerkstelligen ist. Das liegt daran, dass ein Parser grundsätzlich nicht das angeben kann, was der Benutzer ursächlich falsch gemacht hat, sondern nur das, was dem Parser an dieser Stelle auffällt. Nicht anders ist es beim ZBNF-Parser.
In den meisten Fällen wird man bei Syntaxfehlern in den zu parsenden Daten mit einem kritischen Blick auf die Fehlerstelle unter Beachtung von Mustern, wie es richtig an dieser Stelle auszusehen hat, den Fehler erkennen. Meist ist ein Trennzeichen falsch geschrieben und dergleichen. Das wichtigste ist also die Angabe genau der Position, an der der Parser nicht weiter kam. Dabei ist aber zu beachten, dass der Parser möglicherweise in einen Zweig hineingelaufen ist, der nicht gewollt ist. Die eigentliche Fehlerstelle kann sich also in Wahrheit auch schon davor befinden, die angezeigte Stelle ist dann ein Folgefehler.
Daher zeigt der Parser bei einem Syntaxfehler folgende Informationen an:
den Quelltext (einige Zeilen), bis zu dem der Parser am weitesten vorgedrungen ist.
die erwartete Syntax an dieser Stelle. Daraus ist entnehmbar, was sich der Parser gedacht hat (exakter: in welchen Syntaxzweig er hineingelaufen ist).
Die letzten bis zu dieser Stelle erzeugten Parserergebnisse. Insbesondere damit ist oft erkennbar, dass der Parser evtl. aufgrund eines davorliegenden Fehlers in den falschen Zweig hineingelaufen ist.
Diese Ausgaben sind recht umfangreich und werden sowohl in den Reportfile geschrieben als auch auf die Fehlerausgabe der Kommandozeile.
Zu unterscheiden sind folgende zwei Situationen:
Die Syntax steht fest, es handelt sich um einen Fehler in den Eingangsdaten. Diese Situation ist leichter zu beherrschen, auch von weniger syntaktisch denkenen Bedienern (Otto-Normalanwendern).
Das Syntax-ZBNF-File wird entwickelt, möglicherweise wird damit erst die Syntax festgelegt oder man muss sich nach einer vorhandenen gegebenenfalls komplexen Syntax richten. Beispiel dafür ist das Parsen eines Headerfiles, oder auch das Parsen von textuellen Ausgaben eines anderen Programmes.
Vollständige Auskunft über den Ablauf des Parsens geben die Ausgaben im Reportfile. Entsprechend den möglichen Reportlevelangaben.