XML Schnellkurs

Hier soll es nur um die elementaren, um die allerwichtigsten Dinge gehen!  Damit man den Wald erblickt und nicht nur lauter Bäume...

Jeder weiß: Daten bestehen aus Datenelementen oder -feldern. (Wer's nicht weiß, kann es in einer Einführung nachlesen.)

Ein typisches allegro-Datenfeld sieht so aus: (durch die Farben unterscheiden wir echte Daten von Steuerzeichen)

#40 Goethe, Johann Wolfgang ¬von¬

Ein typisches XML-Datenelement sieht so aus:

<Verfasser>Goethe, Johann Wolfgang <nichtsort>von</nichtsort></Verfasser>

Es könnte aber auch so aussehen:

<Author>

   <FirstName>Johann Wolfgang</FirstName>

   <nonsort>von</nonsort>

   <LastName>Goethe</LastName>

</Author>

Oder noch gänzlich anders - die Möglichkeiten sind unbegrenzt. Die Bezeichnungen zwischen <...> heißen "Tags" und dienen als Namen für die eingeschlossenen Datenelemente. Auf deutsch heißt "tag" soviel wie "label". Es gibt keine festgelegten Elementbezeichnungen für Bibliothekszwecke oder für irgendwelche anderen Zwecke. Jeder, der XML anwendet, kann sich seine Elemente selber ausdenken - das ist es gerade, was viele so charmant finden an XML. Und verbale Bezeichnungen suggerieren leichter als Nummern (die für sich genommen nichts aussagen und deshalb gelernt werden müssen!), man verstünde, was gemeint ist. Verspielt wird nur der große Vorteil der Nummern: sie sind sprachunabhängig und damit von Hause aus international.

Man hat bei XML nur eine ganz einfache Grundregel einzuhalten, die so aussieht:

<tag>irgendwelche Daten</tag>

Dabei ist Groß-/Kleinschreibung wichtig: <author>, <Author> und <AUTHOR> wären drei verschiedene Elemente! Aber alles andere ist beliebig.
Die Daten, nebenbei gesagt, sollen aus Unicode-Zeichen bestehen (UTF-8).

Noch eine zweite Grundregel ist wichtig: Ein Tag kann durch ein oder mehrere Attribute erweitert werden. Wenn man etwa mehrere Typen von Personen unterscheiden will, ohne dafür mehrere verschiedene Tags einzuführen, könnte das z.B. so aussehen:

<Person typ="author">Lessing, Gotthold Ephraim</Person>

Eine dritte Sache (oben beim Goethe-Beispiel schon zu sehen) erhöht das Potential von XML dann ins wahrhaft Astronomische: Tags können ineinander verschachtelt werden: Der Inhalt zwischen dem öffnenden und schließenden Tag kann wiederum weitere XML-Datenelemente umfassen. Aber vollständig umfassen! Es darf nicht ein öffnendes Tag innerhalb des Inhalts liegen und das zugehörige schließende dann außerhalb. Ansonsten ist die Reihenfolge von Elementen in keiner Weise geregelt. Man könnte somit haben:

<Person typ="author"><Nachname>Lessing</Nachname><Vorname>Gotthold Ephraim</Vorname></Person>

<Personen>
<Person typ="author"><Vorname>Gotthold Ephraim</Vorname><Nachname>Lessing</Nachname></Person>

<Person typ="author"><Nachname>Schiller</Nachname><Vorname>Friedrich</Vorname></Person>
</Personen>
Konventionelle bibliothekarische Formate haben dazu keine Entsprechung. So etwas löst Begeisterung aus - bis man anfängt, mit solchen Daten irgend etwas zu programmieren oder zu parametrieren... Andererseits muß man ja nicht alles ausreizen, was XML im Prinzip ermöglicht! Übrigens ist XHTML eine modernere Variante von HTML und richtet sich streng nach den Formalien von XML.

Wie auch immer, man erkennt leicht: Die interne Struktur einer allegro-Datenbank hat mit XML nichts zu tun. Das wird auch so bleiben. XML ist als Arbeitsformat in einer Datenbank unpraktisch, zum Eingeben von Hand sowieso. Das braucht einen auch nicht zu verwundern, denn für solche Zwecke wurde es nicht geschaffen. Sondern für das Strukturieren von Dokumenten im weitesten Sinne und erst später dachte man an den Datenaustausch zwischen Systemen und Programmen, nicht jedoch an das Speichern im Innern einer Datenbank. Austausch-Standards sollen nur die unterschiedlichsten Systeme miteinander verbinden. Intern können die alle machen, was sie wollen, daran ändert sich auch durch XML nichts.

Für die traditionellen bibliothekarischen Austauschformate MARC21 und MAB2 existieren inzwischen XML-Varianten: MARCXML und MABXML. Beispiele siehe unten. Diese definieren keine neuen, verbalen Labels für die Datenelemente, sondern verpacken die altbekannten Formatnummern nur als Attribute. Damit ändert sich an der Inkompatibilität der Formate überhaupt nichts. XML ist nicht gleichbedeutend mit Kompatibilität. Was XML vereinheitlicht, das ist nur die formale Art der Datenauszeichnung: die alten Nummern sind nun mit spitzgeklammerten Labels ausgezeichnet statt mit bestimmten Steuerzeichen. Dadurch kann man nun mit allgemein üblichen Werkzeugen auf die Daten losgehen, statt immer neue Spezialprogramme dafür zu schreiben. Mehr aber nicht. Mit anderen Worten: Es wird nicht MARC oder MAB durch XML ersetzt, das wäre eine grob unsachliche Aussage, sondern nur die bisherigen Steuerzeichen (eine Norm namens ISO2709) durch XML-Spitzklammern. Eine Neuentwicklung der Library of Congress, MODS, ersetzt die Nummern von MARC durch verbale Tags, englische natürlich. MODS ist, anders als MARCXML, nicht mehr 100% mit MARC21 kompatibel, sondern bildet nicht alle MARC-Einzelheiten ab.

Es ergeben sich nun für allegro zwei Fragen:

1.       Wie bekommt man XML-Daten in eine allegro-Datenbank hinein?

          Drei Möglichkeiten stehen zur Wahl:

          1. Umwandlung mit der Importsprache, Einspeisen mit dem Programm UPDATE

              Die mächtigste, aber schwierigste Methode; nur für fortgeschrittene allegrologen

   2. Mit FLEX: geeignet, wenn nur einzelne, nicht allzu viele Felder aus XML-Fremddaten zu übernehmen sind und die Feldinhalte mehr oder weniger unverändert übernommen werden können. Die Importsprache bietet dagegen mehr Funktionen für das Manipulieren einzelner Datenfelder.
Ab V29 gibt es den Manipulationsbefehl x (für var und write). Wenn in der "internen Variablen" ein XML-Text steht, der das oben gezeigte Datenfeld mit Lessing enthält, kann man es mit  var (x'Person type="author"')  herausziehen.

          3. Vorher die XML-Daten mit eigenen Programmen in die allegro-Externstruktur umwandeln, dann mit dem Menü "Datei / Weitere Offline-Datei laden" einlesen. Welche Software man für die externe Umwandlung benutzt, das spielt natürlich für allegro keine Rolle.

2.       Wie kann man Daten mit XML-Struktur aus einer allegro-Datenbank herausbekommen?

          Dazu gibt es jetzt (ab V24.4) ebenfalls drei Wege:

          1. Export mit Hilfe der Exportsprache

              Die mächtigste, aber schwierigste Methode. Jedes kleinste Detail kann damit programmiert werden. Dieser Weg ist zu wählen, wenn die Daten einem von außen vorgeschriebenen XML-Schema entsprechen sollen, wie etwa MARCXML oder MABXML. Bei solchen Schemata ist es typisch, allegro-Elemente in einer vorgeschriebenen Reihenfolge in mehrere Teile auseinanderzunehmen oder auch anders zusammenzusetzen oder ineinander zu verschachteln.

          2. Ausgabe der Daten mit Hilfe von FLEX-Makros

              Schnell und relativ einfach zu realisieren, etwas weniger mächtig in den Details der Umwandlung. Diese Methode kommt in Betracht, wenn man einige  Datenelemente für nicht allzu komplizierte externe Verwendungszwecke braucht, wie etwa für statistische Auswertungen.

          3. Den neuen FLEX-Befehl  xml  einsetzen

              Wandelt einen Datensatz als Ganzes um in vier verschiedene Standard-Strukturen. Das macht kaum Arbeit, allenfalls kleinere Eingriffe in die Konfigurationsdatei (.CFG-Datei) sind nötig, in der die Feldbezeichnungen stehen. Dieses Verfahren ist sinnvoll, wenn die Daten extern gebraucht werden und es nicht so genau auf deren Struktur ankommt, sondern darauf, ob man sie dann mit XML-Werkzeugen bearbeiten kann.

Der neue FLEX-Befehl

xml modus

Wandelt den aktuellen Datensatz um in einen XML-Datensatz, also eine Folge von Datenelementen, die mit Tags versehen sind in der XML-typischen Weise:

<tag>Text des Datenfelds</tag>

Der XML-Text steht dann als Ganzes in der internen Variablen! Das ist aber nur eine Zugabe. Er wird in derselben Form sogleich in die Ausgabedatei geschrieben, denn das wird in aller Regel der Sinn der Sache sein. Damit in der Ausgabedatei aber Unicode ankommt (intern ist normalerweise kein Unicode!), sind zusätzlich vorher die folgenden drei Befehle zu geben, damit die Akzentvertauschung und die Unicode-Umcodierung ausgeführt werden:
xport p p-xml
dow a
dow wX

Ferner die nötigen write-Befehle vorher und nachher, um den Datensatz angemessen in umschließende Tags einzubetten, denn der Befehl selbst produziert nur die nackten Datenelemente, kein Drumherum. Das Drumherum kann aber genausogut in die Exportparameter eingebaut werden, unter der Sprungmarke #-X !  Als Komplettbeispiel kann man sich den FLEX  xmlexp.flx ansehen, mit dem man die aktuelle Ergebnismenge in eine Datei mit XML-Struktur überführt. Dieser wird aktiviert über den neuen Menüpunkt "XML-Ausgabe" auf dem Exportmenü (in den "Komfort-Methoden").

Wenn man tatsächlich NUR das XML-Produkt in der internen Variablen haben will: vorher   open x nul  geben und hinterher close x, dann unterbleibt die Dateiausgabe.

Die Export-Parameterdatei  p-xml.apr  kann für jede CFG benutzt werden. Sie leistet die Umwandlung des internen Zeichensatzes in Unicode (UTF-8), wie es für XML empfohlen wird, einschl. Ersatz der Sonderzeichen (s.u.).
Anschließend kann jeder XML-Kenner mit solchen Daten etwas anfangen, auch wenn die tags keinem existierenden Schema genau entsprechen - und es gibt bislang kein etabliertes und standardisiertes XML-Schema für Bibliotheksdaten. Es gibt aber Werkzeuge, vor allem XSLT, mit denen man die exportierten XML-Daten, falls nötig, noch in ganz andere Formen verwandeln kann.

Sonderfall hierarchische Sätze: Jeder Untersatz wird automatisch in <subrec level="i">...</subrec> eingeschlossen, wobei i die Hierarchiestufe ist (1 für #01 , 2 für #02 usw.).

Wie aber sehen die Tags aus, d.h. was steht innerhalb der spitzen Klammern? Braucht man dafür Exportparameter? Eben nicht, das ist das Sympathische an diesem Befehl. Das Geheimnis: Die Tags stehen schon längst in der CFG, mit der man arbeitet! Daraus werden sie entnommen. (Standardfall: Datei $A.CFG.)

Der modus  ist eine Ziffer: 0,1,2,3

0 :   <label>...</label>

       Hier ist label die Bezeichnung, die sich aus der CFG ergibt.  Wenn das Datenfeld eine Mehrfachkennung hat, wird zuerst die Abfrageliste von oben nach unten nach der Kategorienummer durchsucht. Wird dort nichts gefunden, oder steht Spatium hinter der Kategorienummer, wird die Deskriptorenliste durchsucht (die Zeilen, die mit # anfangen).

1 :   <feld nr="knum">...</feld>

       knum ist die Kategorienummer

2 :   <feld lb="label">...</feld>

       Wie 0, aber statt der Kategorienummer wird im Attribut  lb  das Label angegeben

3 :   <feld nr="knum" lb="label">...</feld>

       Kombination aus 1 und 2

Je nach Verwendungszweck kann man sich also aussuchen, wie die Daten herauskommen sollen. Bei Modus 0 gibt es so viele Tags wie man verschiedene Felddeskriptoren hat, bei den anderen Fällen gibt es nur ein Tag namens <feld>, zu dem die Kategorienummer und/oder das Label als Attribut ergänzt werden.

Die zentrale Rolle für den xml-Befehl spielt also die CFG, die man verwendet. Mit ihrer Hilfe kann man das Ergebnis stark beeinflussen. In der Standarddatei $A.CFG wurden die Labels in den Deskriptorenzeilen alle XML-gerecht gestaltet: ohne Leer- und Sonderzeichen.

Hinweise zur CFG

Stellen Sie drei Dinge sicher:

1.  alle vorkommenden Felder müssen eine Bezeichnung in ihrer Deskriptorzeile haben

          Das sind die Zeilen, die mit # anfangen, z.B.

          #20"Titel"...

2.  Felder, die mit bestimmten Wiederholungszeichen eine andere als die Grundbedeutung haben, müssen mit einer eigenen Bezeichnung in der Abfrageliste vorkommen, z.B. so (ohne # vorne):

          57i"  Interpret: "

3.  die Feldbezeichnungen dürfen in jedem Fall nur aus Buchstaben, Ziffern, Bindestrich oder Unterstrich bestehen, das erste Zeichen darf nur ein Buchstabe sein.

          Nur Grundbuchstaben, keine Umlaute etc.!   (Die Bezeichnung wird am ersten Leer- oder Sonderzeichen abgeschnitten!)

Beispiel:

#57"anderePerson"       Deskriptorzeile für #57

57d"Dirigent:"                    Abfragezeile für #57d

Wenn man die Abfrageliste ansonsten nicht braucht, ist es einfach: man listet unterhalb der Deskriptoren alle Felder in der zweiten Form auf.

Und die Reihenfolge? Die Felder kommen in der Reihenfolge heraus, wie sie im Datensatz stehen - und das ist die Reihenfolge der Deskriptorzeilen in der CFG.

Will man eine andere: schnell eine abgewandelte CFG machen mit Deskriptorzeilen in der gewünschten Reihenfolge, ansonsten alles gleich, kein Eingriff in die Daten nötig. Eine so modifizierte CFG kann gefahrlos eingesetzt werden auch beim Bearbeiten von Sätzen! Den Namen dieser Datei einsetzen in die Befehlszeile Konfiguration= in der INI-Datei.

Wenn aber bestimmte Felder NICHT mit ausgegeben werden sollen?

Dann schreibt man im FLEX vor den xml-Befehl die Liste der betreffenden Felder, die Reihenfolge ist dabei beliebig.

Wenn z.B. #81, #99e und #99n nicht mit ausgegeben werden sollen;

#99n

#81

#99e

xml 1

undo

Denn die Felder werden dadurch aus dem aktuellen Satz im Arbeitsspeicher gelöscht! Durch undo wird das wieder rückgaengig gemacht. Genauer gesagt: der unveränderte, in der Datenbank befindliche Satz wird wieder gültig gemacht, der verkürzte im Arbeitspeicher ungültig.

Ausprobieren:

Geben Sie im Schreibfeld ein:   x xml 0\sho IV

und dann statt der 0 hintereinander 1,2,3. Sofort sehen Sie, was gemeint ist. In der Doku-Datei xxml.rtf ist das für jeden Modus als Flip eingebaut.

Drei Details müssen noch beleuchtet werden:

Teilfelder  (in MAB  "Unterfelder" genannt)

Damit wird immer in derselben Weise umgegangen:

Aus   #nnn Text▼aTeilfeld a▼bTeilfeld b   wird 

<label>Text<uf code="a">Teilfeld a</uf><uf code="b">Teilfeld b</uf></label>

Nichtsortierzeichen

Auch damit wird immer in derselben Weise umgegangen:

Aus   #20 ¬Die¬ Erkenntnis der Natur  wird 

<Titel><ns>Die </ns>Erkenntnis der Natur</Titel>

Die Nichtsortierzeichen können an jeder beliebigen Stelle in jedem Datenfeld vorkommen!

In beiden Fällen sind dieselben Abkürzungen verwendet, ns und uf, die in MABXML definiert wurden.

XML-Steuerzeichen
XML kommt mit ganz wenigen Steuerzeichen aus: <, > und & . Diese drei Zeichen dürfen deshalb nicht als solche innerhalb der Daten vorkommen. Sie werden automatisch ersetzt durch &lt; , &gt; bzw. &amp; , wie es allgemein üblich ist.