Bloss eine Idee

[Thomas Berger]

Lieber Herr Henkel,


> 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.

wuerde nicht: Allerdings ist das Verb dann glaube ich "stylen"
und nicht mehr "konvertieren" (oder ist "stylen" der Akt der
Entwicklung eines Styles?)


> 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.

Ich denke, dass es bleiben wird. Wichtig ist ja vor allem
der *Transport* als Grundlage fuer Export und Import. Im 
Gegensatz zu bibliothekarischen Datenformaten und 
tabellarischer Information aus relationalen Datenbanken 
kann man einzelne XML-Saetze oder Sammlungen davon als
Text transportieren und hat die Gewaehr, dass man sie
am anderen Ende zwar vielleicht nicht verstehen (auch
das eigentlich besser als vorher) aber auf jeden Fall
verarbeiten kann.

 
> 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.

Etwas merkwuerdig formuliert. Jede Style- oder Scriptsprache
fuer diese Daten braucht ein Objektmodell und kennt typischerweise
das XML-DOM. Wird der Baum traversiert, passiert halt was.
Aktionen lassen sich an Elemente und an andere Objekte
(etwa Tags) "binden".


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

ich setze einmal den Ist-Zustand dagegen:
 
> 1. Start der DB-Anwendung als Exe File (oder Anklinken eines Browserlinks)

genauso.
 
> 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

...Datensaetze in einem allegro-Format...
...auszuwaehlenden Exportparameterdatei...

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

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

identisch. Bei Ihnen liest es sich optimistisch, ich fuerchte,
es wird hier keine Verbesserung geben, was die Verarbeitbarkeit
angeht. Wenn Sie aber (das meta-meta) RDF betrachten sehen Sie,
dass es Ansaetze gibt von: "jeder nimmt sich was er braucht und
packt seinen Privatkram mit dazu".

 
> 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.

Das sollte man wirklich trennen: Man muss an die Datenbank heran
(Teile der Klassenbibliothek, a99-Sprache, avanti-Sprache) und
man muss XML-Datensaetze (auch offline) verarbeiten (Import- und
Exportsprache). Lohnenswert wird es sein, beide Aspekte sauberer
zu trennen.

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

OLE-Fernsteuerung statt Flexen? Persoenlich finde ich, dass man
hierfuer eher Protokolle statt API's braucht. Im Zoo der
neuen X-Woerter gibt es glaube ich auch XQL und auch Z39.50
wird irgendwann durch etwas universelleres abgeloest werden.
Aber das steckt alles noch ziemlich in den Kinderschuhen

 
> 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.

Auch "Objekte" haben "Methoden" und selbst in der Objektwelt
sollte man nicht das eine stellvertretend fuer das andere
nehmen. Man versucht natuerlich (im Falle von XSL) fuer die
Methoden eine Notation zu finden, die selbst wieder XML ist
und keine Extraloesungen bei Eingabe und Transport erfordert.
Aufgabe von avanti und a99 ist es auch jetzt schon, anhand
von Anfragen und Tastendruecken spontan aus Datensaetzen
etc. ein "Dokument" zusammenzustellen, dies mit der
Exportsprache umzutransformieren und irgendwohin (Fenster,
CGI-Skript) weiterzuleiten. Entfallen wird hoechstens, dass
man vor und nach jedem Transportschritt noch eine Zusatz-
transformation (Transportverpackung) applizieren muss.

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

Man wird sehen. Jedenfalls sollten Indexeintraege *nach aussen*
auch als XML praesentiert werden.

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

Grundlage von XML ist Unicode (UTF-8, wenn ich mich recht
entsinne).


viele Gruesse
Thomas Berger