Bloss eine Idee

[Roland Henkel]

Lieber Herr Hoeppner,

> Einverstanden, einverstanden, nur müssen wir deshalb gleich das
> eigentliche interne Speicherformat in XML machen? Was gewinnen
> wir dadurch? Wer XML für eine Weiterverarbeitung haben möchte,
> kann das im Prinzip ja haben.
>
Immerhin würde, sofern XML das Datenformat ist, auf dem Wege zur Anzeige und
zum Druck oder ganz allgemein zum Export  eine Konvertierung (etwa durch
d-1.apr) entfallen. Wenn XML einmal die lingua franca in der DV ist, wäre
das doch ganz praktisch - übrigens auch für den Import.
Die Bedingung, XML würde lingua franca, ist abe eigentlich  das Axiom meiner
Überlegungen, das heißt, mit ihr stehen und fallen sie. Ist XML bloß wieder
so eine Mode, erübrigt sichs.

Als Scriptsprache böten sich bei Verwendung von XML vielleicht die Objekte
und Funktionen des Document Object Models an. Soweit ich weiß, erlauben
diese, ziemlich in die Tiefe zu gehen und in Abhängigkeit von den
Eigenschaften von Tags alles mögliche zu machen.

>Also, es ist ja wohl bekannt, dass ich kein ausgebildeter Bibliothekar
>bin, und RAK steckt mir auch nicht im blut,

Mir auch nicht (außerdem zähle ich RAK zu den heiligen Kühen :-) ) ich kann
also mit Beispielen nicht dienen. Ich wollte mit der Erwähnung von CDATA und
Entities darauf hinweisen, daß es innerhalb der manchem vielleicht starr
scheinenden XML Normierung doch noch ein paar Freiheitsgrade gibt.


Ich habe inzwischen mal versucht, das mir vorschwebende Endprodukt vage zu
umschreiben:

1. Start der DB-Anwendung als Exe File (oder Anklinken eines Browserlinks)

2. Bei Auswahl eines oder mehrerer Indexschlüssel erhalte ich einen oder
mehrere Datensätze in XML, die entsprechend einer ebenfalls auszuwählenden
Stilbeschreibung als Bildschirmausgabe, Druckliste, CDROM-Inhalt usw. zur
Verfügung gestellt werden können

3. Für die Erfassung existiert ein lokaler oder serverbasierter XML-Editor,
der wahrscheinlich gegenüber den Allroundwerkzeugen abgespeckt sein kann.

4. Die produzierten Ausgaben kann ich sofort weiter verschicken oder in
anderen Anwendungen (wenn diese XML verstehen) weiter verarbeiten.

5. Auf Grundlage des Document Object Models verfüge ich außerdem über ein
API, mit dem ich auch "von außen" her an die Datenbank heran komme. Daß die
DB-Anwendung ihrerseits von díesem API ausgiebig Gebrauch macht, versteht
sich von selbst.

6. Ich könnte auch andere Anwendungen mit Allegro Datenbanken kommunizieren
lassen und inzwischen einen Kaffee trinken gehen :-).

8.. Die Datenbankanwendung ist grundsätzlich serverbasiert, der Server kann
aber auch localhost oder 127.0.0.1 heißen. Avanti und a99 verschmelzen also
gewissermaßen. Vielleicht lassen sich sogar ein paar vermittelnde Scripte
einsparen, wenn XML das "native" Datenformat ist, wenn also der avanti-Enkel
XML "spricht". Auch hier wäre ja das DOM die Grundlage - was vielleicht doch
in die Richtung "eine Scriptsprache für viele Aufgabenstellungen" ginge.

9. Alternativ zum Index kann ich mit einer XQL-Anfrage Datensätze anfordern.

10. Für internationale und historische Zeichensätze habe Entities.
---------------------------------------------

Gewiß besteht zu Recht der mögliche Einwand, X-n.cPR wäre schließlich auch
eine Art Stilbeschreibung. Nur:

- wenn ich eine X-n.cPR schreiben kann, hilft mir das außerhalb von Allegro
nicht weiter.

- gerade die optische Aufbereitung ist doch eher mühselig, das *wie* der
Darstellung nicht ganz so flexibel wie das *was*, oft exportiert man erst in
eine Textverarbeitung und überläßt dieser den Feinschliff.

Wie es scheint, ist derzeit Java mit am besten für die XML-Verarbeitung
ausgestattet, außerdem wäre wenigstens annähernd Plattformunabhängigkeit
gewährleistet. Daß Java noch Performanzprobleme hat, wird aller Orten
beklagt, was zu der Hoffnung berechtigt, daß dieses Manko einmal behoben
sein wird.


 MfG
R. Henkel