Bloss eine Idee

[Dierk Hoeppner]

On 26 Sep 2000, at 17:26, Roland Henkel wrote:

> zukünftiges Format der Allegrodatenbank XML, Kategorien als Tags
> Konfiguration DTD, ein XML-Parser (es sind, so weit ich weiß, einige
> frei erhältlich) könnte dann die Prüfung der Konsistenz zwischen
> Daten und Konfiguration übernehmen. Anzeige mit Hilfe von CSS oder
> XSL. Und zwar könnte das so geschehen, daß aus der XML-Datenbank mit
> Hilfe der Exportsprache eine temporäre XML-Seite für den
> anzuzeigenden Datensatz erstellt wird, die den Formatangaben
> unterworfen wird. Damit würden sich vielleicht auch die
> Formatierungsmöglichkeiten erweitern lassen.

XML als internes Datenbankformat hat div. Nachteile:

Start-Tags und End-Tags nehmen unnötig Platz weg. In dieser 
Hinsicht sind wir sehr eigen ;-) Sie bringen für die automatische
Verarbeitung nichts, wenn man das Format kennt.

Ein Datenbank als XML-Datei ist von der Struktur her ein _sehr_ 
flacher Baum. XML-Programme, insbesondere Validatoren müssen 
sich die ganze XML-Datei reinziehen, damit sie die Syntax 
überprüfen können. Z.Zt. ist das jedenfalls so. Bei kleinen 
Datenbanken keine Problem, wenn Sie es mit 2,6 Mio. oder so 
Datensätzen zu tun haben, schon. Für einen PC ist das nix mehr.


Die Verarbeitung mit XSL, CSS und Konsorten können Sie jetzt 
schon haben. Man muss nur mal einen Export für sein Format 
erstellen und macht alles weitere dann mit den div. XML-Tools. In der
Web-Anwendung wäre das gut einzubauen, und wer sich dransetzt mit
avanti und eigener Programmierung einen eigenen Datenbankbrowser zu
programmieren, kann das heute auch schon haben: In der Windows-Welt
kann man sehr gut den IE als Active-X- Element in sein Programm
einbauen. Ich seh da schon die Augen so manches EDV-Spezialisten
aufleuchten, der nur wenig von allegro versteht, nur - es hilft
nichts, Das Problem, aus den Grunddaten eine formatierte ISBD-Anzeige
beispielsweise mit korrekter(!) Zeichensetzung hinzubekommen, bleibt.
Wem da ein Bibliothekar im Nacken sitzt  und wer selbst nichts von RAK
etc versteht, dem nützt XML auch nichts. Der größte Teil der Arbeit
steht ihm oder ihr noch bevor. Da ist das Lernen der allegro-Struktur
ein Klacks.

> Für die bloße Anzeige könnte dann (auch) ein XML-fähiger Browser
> oder Viewer verwendet werden. (den wird es vemutlich in absehbarer
> Zeit geben, ist ja ohnehin alles Zukunftsmusik).

Ginge jetzt schon, wie oben angemerkt. Nur tun muss es mal 
jemand. Mit avanti habt ihr doch alles, was man für den recht 
einfachen Zugriff auf eine allegro-Datenbank braucht. Und der IE-5
kann schon weitestgehend XML-Daten verarbeiten.

> M.E. müßte sich gar nicht so viel ändern :-). Auf den Index wollen
> wir wohl alle nicht verzichten. "Nur" der Teil, der in irgendeiner
> Weise das interne Satzformat betrifft, sähe anders aus.

D'accord. Nur vom kompakten Satzformat gehen wir nicht ab. 
Unsere Datenbank wird im normalen Dateisystem gespeichert und 
da ist eine kompakte Speicherung fast gleichbedeutend mit 
schnellem Zugriff, weil kein Platz verschwendet wird. Wer jetzt 
einwendet, dass die großen Datenbankhersteller ja auch alle XML 
als Datenbankformat einsetzen wollen, dem sein gesagt, dass es 
imme noch so ist, dass Datenbanken, die einen hohen Durchsatz 
erfordern auf sog. Raw-Devices angelegt werden. Das sind Platten, die
_nicht _ formatiert sind. Die Ablage der Daten organisiert dann das
Datenbankmodul komplett selbst. An diese Daten kommt man mit normalen
Programmen nicht ohne weiteres ran, weil das Betriebssystem sich
meistens sperrt, wenn es um den Zugriff auf eine unformatierte Platte
geht. Ich bezweifele auch, dass dort XML- gespeichert wird, wegen der
Platzverschwendung. Vielmehr bieten die eine Schnittstelle, die aus
den Daten XML als ein Exportformat machen. Aber genau das geht mit
allegro jetzt auch schon.

> Auch vom Umfang her, würde nicht viel dazu kommen, zumal man ggf.
> beim Schreiben komprimieren und beim Lesen dekomprinieren könnte -
> XML sind ja reine Texte.

Gut, aber dann haben Sie sich gerade fast widersprochen, denn 
dann haben Sie ein internes unsesbares Format, das man nur mit 
geeigneten Programmen lesbar machen kann. Wer die Codierung 
nicht kennt und die Programme nicht hat, ist aufgeschmissen. XML macht
ja gerade jeder, weil die Daten dann noch für einen Menschen lesbar
sind. Da ist das allegro-Internformat mindestens genau so gut.

> Probleme, die absehbar sind: Z.B. Durch was wird die jetzige
> Satznummer ersetzt, das heißt, das Bindeglied zwischen TBL und
> Index?

Im Index steht hinter einem Eintrag die logische Satznummer. In der
TBL steht dazu der physikalische Offset in einer Datei und damit
positioniert dann das Programm in der Datendatei. Mit der XML- Datei
kann man sich die TBL vielleicht sparen, wenn jeder Datensatz seine
eigene Nummer hat. Die XML-Parser bisher müssen allerdings bei der
Suche nach einem bestimmten Element mit einer bestimmten Id den Baum
von Anfang an durchsuchen - jedenfalls, soweit ich informiert bin.
Vielleicht gibt es ja bessere Möglichkeiten.

> Export/Import müßte sich nur insofern ändern, als daß das neue
> "interne Dateiformat" berücksichtigt wird. Vielleicht sind auch XML
> basierte Werkzeuge/Routinen einsetzbar.

Für den Entwickler, der ein neues Datenbankschema in einer 
Anwendung umsetzen muss, ändert sich vom Arbeitsaufwand her 
gar nichts, nur die Mittel ändern sich. Aber eine etwas komplexere
XSL-Datei ist mindestens ebenso schwer zu verstehen, wie eine
allegro-Parameterdatei. Auch für diejenigen, die das schon mal gesehen
haben.

> Vorteil: 
> - Kompatibilität der neuen Allegro-Daten mit allen möglichen
> (zukünftigen)    lokalen und netzweiten Anwendungen. - normierte
> Regeln und Schnittstellen. - gute Lesbarkeit der Datenbank

Der letzte Punkt wäre nicht gegeben, wenn Sie die Daten, wie von Ihnen
vorgeschlagen, komprimieren würden. 

Was die kompatibilität angeht: Die ist auch nicht gegeben. Ein XML-
Parser kann die Daten vielleicht einlesen und die syntaktische
Korrektheit bestätigen, mehr aber nicht. Sie haben dann immer noch das
Problem, sich die korrekten Elemente für ihre Anwendung
heruaszufischen, Elemente zu kombinieren, oder sogar zu trennen,
bleibt als Programierer Aufgabe. Das läuft auch mit XML nicht
automatisch. IE kann sowas ja einlesen, WordPerfect ebenso. Damit gibt
es aber immer noch nicht den Knopf 'Neuerwerbungsliste'. Den
zuerstellen und die Funktionalität dahinter ist die Hauptarbeit.

> Nachteil (wenn es sich denn machen läßt): keine.

Aber auch keine direkten Vorteile, meiner Meinung nach.

> Natürlich ist das alles sehr vage und kein fertiges Porjekt. Es kann
> sich auch gut und gerne erweisen, daß dies nicht realisierbar oder
> überflüssig ist.

Realiseirbar: Jetzt schon, es mur nur mal einer machen. (Es hat 
immer noch niemand ein "besseres" Zugriffsprogramm als Ersatz 
für a99 für allegro-Datenbanken gebaut, obwohl alle Mittel dafür zur
Verfügung stehen.

> Aber als Anregung zum Feierabend taugt es vielleicht etwas. Es ist
> ja zuweilen auch eine Entspannung, vom Tagewerk abzusehen und ein
> wenig zu spinnen.

Jo. Über XML und seinen Einsatz mache ich mir schon seit einiger Zeit
Gedanken. Wir sehen die Vorteile für allegro noch nicht, um mit
fliegenden Fahnen alles auf XML umzustellen. Für andere, hausinterne
Projekte verdwende ich es schon. z.B. in unserem
Digitalisierungsprojekt. Da benutzen wir (noch) nicht allegro. Kommt
aber. Ich bin da auf ein Progrämmchen gestoßen, das für die
Verarbeitung von XML-Daten einfach genial ist: gslgen von iMatix
(www.imatix.com) Und ich will auch mal testweise unseren Katalog in
XML aufbereiten und gslgen damit zum Platzen bringen. Mal sehen, was
daraus wird.

Wie könnten allegro-Daten in XML aussehen? Weiß ich noch nicht 
genau. Ein Vorgeschmack bietet aber MARC SGML. Die DTDs 
kann man sich von www.loc.gov/marc/ herunterziehen. Und wenn 
ich an das PICA-Format oder HANS in diesem Zusammenhang 
denke, wird mir ganz anders.

Viele Grüße
Dierk Hoeppner
Universitaetsbibliothek
Pockelsstr. 13
D-38106 Braunschweig
Germany
Tel: +49-531-391-5066 Fax: -5836
E-Mail: d.hoeppner at tu-bs.de