Bloss eine Idee

[Dierk Hoeppner]

Hallo Herr Berger, Herr Henkel

natürlich sind in XML sehr gut Schachtelungen möglich, man 
bekommt aber Schwierigkeiten, wenn man andere Sichtweisen 
haben möchte. Z.B in meiner Subito-Datenbank sind im 
wesentlichen drei Typen von Datensätzen drin: Bestellungen, 
Rechnungen und Kundensätze. Den einen interessieren nur die 
Bestellungen als Einzelobjekte. Den anderen die Rechnungen. Da 
sind dann aber der oder die Bestellungen ein Teil der Rechnungen, 
müßten idealerweise also als Unterlement der Rechnungen 
gespeichert werden. Die Kundenadresse sind aber sowohl Teil der 
Rechnung als auch der Bestellung. Und da hätte ich schon ein 
Problem, diese Bezeiungen in XML darzustellen. Es sei denn man 
macht drei Datenbasen mit den einzelnen Satztypen, aber dann hat 
man wieder das Verknüpfungsproblem.
 
> wiederholbaren Feldern, Teilfeldern, wiederholbaren
> Teilfeldern und einem Zoo von Wiederholungszeichen
> (" ; ", " * ", "¶" etc. je nach Anwendung) von denen
> einem ganz schlecht wird, wenn man darueber nachdenkt,
> ob in einer Kategorie mit Unterfeldern jetzt die

Da wäre eine Straffung wirklich nicht schlecht. Auch würde ich mir 
manchmal im Standardschema wünschen, dass Folgezeichen 
wirklich Folgezeichen sind.

> und Gesamtzusammenhaenge zu entwickeln. Ausserdem kann
> man einzelne Records bearbeiten, ohne die ganze Datenbank
> als "Dokument" betrachten zu muessen.

Nach meinen Informationen, aber so tief stecke ich 
zugegebenermaßen auch nicht drin, wollen die gängigen Parser 
gerne ein Root-Element haben und darunter dann die einzelnen 
Elemente. Und das ziehen die sich immer komplett rein. Ich sehe da 
echte Schwierigkeiten bei einer Datenbank von mehreren 100.000 
Datensätzen.

> einen Link ein und hofft auf die Software, die eine
> geeignete Navigations- oder Nachlade/Zusammenanzeige-
> Funktionalitaet bereitzustellen hat.

Richtig. Das ist aber nach meinen Erfahrungen aus Gesprächen mit 
EDV-Fachleuten der Knackpunkt. Viele wissen selbst wohl noch 
nicht so richtig über XML-Bescheid, scheinen aber zu glauben, 
dass das Format die Probleme von alleine löst. Tut es aber nicht. 
Das Hauptproblem ist die Erstellung der Anwendung. Das ist mit 
allegro-Grunddaten genauso groß wie mit XML-Daten.

> Man hofft dabei immer auf den uebernaechsten Standard der
> Style-Sprachen. Am Rande waere es natuerlich nett, die
> Exportsprache von allegro ueber Bord zu werfen ,vorausgesetzt
> es gibt etwas allgemeingueltigeres, was dasselbe kann...

Ja, die Hoffnung bleibt, ist aber trügerisch meiner Meinung nach. 
Bibliographischen Daten sind einfach komplex.

> Im Rahmen von MALVINE (http://www.malvine.org/) wurde
> ein bibliothekarisches Datenformat als XML fast "neu" entwickelt. Fuer
> das Projekt gibt es dann Konversionsskripte, die HANS-Daten,
> SGML-Daten (TEI?), MARC-Daten etc. der verschiedenen Teilnehmer
> umwandeln. Es scheint (wie auch bei den Ueberlegungen zu RDF), dass

Schön, aber das Grundproblem bleibt trotzdem: Wenn ich mit 
meiner eigenen Datei komme, die XML-Daten enthält, und die 
keines der genannten Formate enthält sondern ein eigenes, kann 
keines der Scripte diese Daten korrekt in das Zeilformat wandeln. 
Da muss jemand ran, die Quellstruktur analysieren und eine 
Konversionsprogrammsc schreiben, in welcher Sprache auch 
immer. Das ist doch der Knackpunkt, nicht das Datenformat. Ob ich 
dem Programmiere nun sage, dass 20 ....\x00 das Titelfeld ist, oder 
<20></20> das Titelfeld ist völlig egal. Ich muss es ihm in jedem Fall 
sagen, weil er sonst nicht weiß, wohin mit dem Feldinhalt. Ein 
allgemeiner XML-Parser kann das auch nicht. (Ich könnte natürlich 
auch <verfasser> nehmen, aber ein Programmierer in Inden hätte 
auch wieder das Problem) Ich sehe bei dieser Problematik wirklich 
nicht den Vorteil von XML

Zu Herrn Henkel:

Sie schrieben: Aber das mit dem erhöhten
Platzbedarf einer solchen Datei eigentlich nicht. Es wird sicher 
mehr,
aber ich finde, nicht so dramatisch, wie Sie zu fürchten scheinen.

Also, ich weiß nicht. Der baC hat 1,85 Mio-Datensätze Jeder 
Datensatz hat im Schnitt 10 Kategorien. Er paßt jetzt gerade noch 
als lebende Datenbank auf eine CD. Wenn ich mal ganz einfach 
annehme dass der Datensatz in XML mit <record></record> 
beginnt und endet, sind es schon ~31MB mehr. Für eine Kategorie 
benötige ich zusätzlich 7 Zeichen, wenn sie ungefähr so aussähe: 
<20>...</20> Das sind nochmal ~129MB mehr. Als wenig empfinde 
ich das nicht. Auf einer Festplatte ist es wohl tragbar, Herrn Greins 
Projekt wäre schon lange nicht mehr mit einer CD erledigt.

Sie meinten, bei flachen Bäumen müßte man den Geschäftsgang 
überdenken. Nun ist es aber das Wesen einer Datenbank, dass sie 
nur aus einer langen Kette von prinzipiell gleichen Datensätzen 
besteht. Das ist nun extrem flach. Da beißt keine Maus den Faden 
ab. Es gab früher mal Datenbanken, die die Daten hierarchisch 
recht tief speicherten, die waren aber sehr unflexibel. Man ist da 
aus guten Gründen von abgegangen.

Zur Prüfung der Wohlgeformtheit und Gültigkeit durch die Parser, 
stimmt es für das erste, für das letztere nur bedingt. Das 
Hauptproblem bei bibliothekarischen Datensätzen ist die Besetzung 
der Felder mit den korrekten Inhalten. Unsere Institute liefern uns 
Daten, in denen enorm viel von N.N. geschrieben wurde, und der 
_persönliche_ Herausgeber schon mal die SPD sein kann. Diese 
inhaltliche Korrektheit kann kein XML-Parser überprüfen. (allegro 
auch nicht: "Der Spion, der mich liebte" in das Verfasserfeld 
eingetragen, wird klaglos akzeptiert. Ein XML-basiertes Programm 
würde es auch aktzeptieren. Nur finden tut man den Titel im 
Titelregister nicht mehr und damit ist der Titel sogut wie weg)

Das mit den Raw-Devices ist auch kein historisches Problem, 
sondern brandaktuell. Ich war früher auch anderer Meinung, bis ich 
vor ein paar Monaten in der iX eine interessante Zuschrift von einem 
echten Datenbankspezialisten gelesen habe. Der wartete mit 
etlichen Zahlen auf, die für Höchstperformante Datenbanken, wo es 
auf extrem großen Durchsatz ankommt, nur eine Lösung zulassen 
(auch heute noch): Raw-Devices und Mainframes mit 
Arbeitsspeicher ohne Ende und am liebsten noch mehr Prozessoren 
und MHz.


Es ist wirklich gut, dass sie dieses Thema aufgebracht haben, ich 
bin selbst in letzter Zeit am Herumprobieren mit XML, sehe aber 
immer noch nicht, dass es der Bringer ist.

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