[Allegro] Getrennte Listefür Entwickler sinnvoll?

[Thomas Berger]

Lieber Herr Mentzel-Reuters,


> Was mir abhanden gekommen ist: Die Debatten in der Liste drehen sich um
> Features, die mit dem was für mich allegro ausmacht - Import- und Export-Sprache
> inkl. Index - nichts oder wenig zu tun haben.

[...]

> Was ich aber immer wieder habe, sind Datenimporte aus weiß der Teufel was für
> Quellen, die dann in das Format einer unserer Datenbanken müssen: und das sind
> weiß Gott nicht nur Dinge nach dem A-Schema, sondern alles mögliche bis hin zu

Solche Anforderungen sind seltener geworden, ich weiss auch nicht warum:
Immerhin gibt es viel mehr Daten und man koennte meinen, dass mehr
importierenswerte dabei sind.

Natuerlich gibt es Linked Data bzw. die Einsicht, dass die eigenen Datenformate
(auch die internen) nicht fuer beliebige Inhalte taugen und eine gescheite
Verlinkung oft angemessener ist. Aber auch da wuerde man oft zumindest die
Identifier importieren muessen...



> Mein Eindruck in der Liste ist, daß es um die Struktur der Daten innerhalb der
> Datenbank gar nicht mehr geht, sondern um weit hinausgreifende Aufsätze, aber
> oft weiß ich nicht einmal, wozu das dienen soll. Muß ich ja auch nicht: nur wenn
> ich in einen Hype wie seinerzeit mit dem neuen srch32 (das ich übrigens ohne
> Probleme sofort eingesetzt habe) hineingerate, brauche ich mit einer Frage nach
> den Parametrisierungen gar nicht zu kommen. Das interessiert einfach nicht -
> bzw. ich muß die Lösung einkaufen. das klingt zwar gut, ist es aber nicht, weil
> man fremde Parametrisierungen erst mal nicht nachvollziehen kann.

Auf einer gewissen Ebenen /koennen/ Sie es allerdings im Unterschied zu anderen
Systemen immer noch, weil die eingekaufte Loesung (hoffentlich) als
Parameterdatei, also als Quelltext vorliegt.

Ich hatte vorhin die Regelwerke als nicht-allegro-Beispiel gebracht, wo ich
eine Tendenz des Abgebens von Kompetenz zu beobachten glaube. Bei Daten-
formaten und -strukturen ist das m.E. genauso deutlich zu sehen:

Um 1990 gab es einiges an verschiedenen Anwendungen und Datenformaten,
die wurden am lebenden System veraendert und divergierten schnell: Alle
paar Monate kam der "Institutsbetreuer" vorbei und spielte neue Versionen
auf bzw. trug Aenderungen in den Parameterdateien nach, unter Berufung
auf allegro als "frei konfigurierbares Datenbanksystem" wurden oft auch
ganz bewusst abweichende Datenschemata definiert, im gleichen Haus fuer
jedes Projekt eins (etwa Wolfenbuettel). Das erwies sich aber bereits
Mitte oder spaetestens Ende der 1990er Jahre als nicht mehr pflegbar und
viele Anwendungen wurden mit grossem Aufwand auf das (oder ein) Standardformat
zurueckgebogen.

Seitdem hat man mit allegro-Datenbanken eigentlich genau dasselbe
Dilemma wie auch mit MAB2 oder MARC21: In "Randbereichen" taugen die
Formate nicht und an vernuenftiger Dokumentation bei gleichzeitiger
Fortentwicklung ist selbst MAB gescheitert, obwohl eine viel groessere
und potentere Community dahinter stand. Beispiele:
* Bei in HANS vorgesehenen Kategorien fuer Wasserzeichen haben die
  Fachleute nur muede abgewinkt, als die einmal zum Einsatz kommen
  sollten.
* MAB2 hat kein eigenes Datenfeld fuer die Fundstelle eines Aufsatzes,
  hoechst wichtiges wie 655$A und 655$3 werden von fast allen
  Datenproduzenten hingegen ignoriert
* MARC21 ist schnell in der Entwicklung, aber die Codes zu Materialarten
  zeigen m.E., dass man gewisse Dinge nicht verstanden hat und Entwicklungen
  nicht hat absehen koennen, als man mit der bibliothekarisch gebotenen
  Gruendlichkeit die Welt in erstens, zweitens drittens aufgeteilt hat.
  So etwas zu revidieren ist dann mit Ruecksicht auf existerende Daten
  eher unmoeglich.

Als (spezialisierter) Anwender ist man nun teilweise ueber- und an
anderen Stellen unter- bzw. fehldifferenzierten Datenformaten ausgeliefert,
denn jede Abweichung stellt die muehsam erreichte Kompatibilitaet infrage.

Keines der Austauschformate und m.W. auch keines der Internformate
hat sich in Richtung einer Modularisierung bewegt, d.h. ein mit dieser
Community austauschbarer Kern umgeben von auf andere Communities
zugeschnittene Ergaenzungen. Dementsprechend gab es (zumindest bei allegro)
auch nie bezueglich Konfigurations- und Parameterdateien Ideen zur
Modularisierung: Der Anwender ist immer umfassenderen (und raum- und
sprungmarkenverzehrenden) "Standardparametern" ausgeliefert, die fuer
sich genommen ja auch immer besser werden, aber den paar eigenen
Datenelementen und Abrufzeichen fuer den Geschaeftsgang immer weniger
(organisatorischen) Raum lassen.



> In jedem Perl- oder Javascriptforum gibt es Threats des Typus: ich möchte das
> und das programmieren, habe folgende Zeilen probiert, aber es geht nicht. Bei
> der Allegro-Liste bewegt sich das in wolkigsten Höhen.

Sie meinen, auf konkrete Fragen gibt es viel zu abstrakte Antworten?

Ist nicht eher zu beobachten, dass konkrete Fragen des "wie programmiere ich
das" irgendwie nie gestellt werden?



> Ein Beispiel: durch unsauberes Parametrisieren entstehen bei mir immer wieder
> mal alg-Dateien, in denen die Zeichenfolge 00 13 10 erzeugt wurde (also ein
> angefangener Datensatz ohne Inhalt). Passiert das nur mir?

01 13 10?

Es war hier schon einmal Thema, dass die "Abbruch"-Anweisung #+- nicht
wirklich rueckstandsfrei arbeitet und bereits ausgegebenes nicht retrospektiv
unterdrueckt wird. Dazu gehoert wohl in jedem Fall der Inhalt des Parameter
ab (und as)

Beim normalen "Ende"-Befehl #+# wird anschliessend noch der Wert von ae
angehaengt, auch wenn man als Parametrierer "Abbruch" im Sinn hat.

Das betrifft jeden Einzelexport, d.h. jeweils einmal pro ak-Statement, das
fuer einen gegebenen Datensatz aktiv wird.

> Denn es war niemals Thema, daß diese Datensätze beim alten update16 zur Blockade
> der TBL führten (acon -jupdate verdaut sie hingegen), das alte srch16 kommt gut
> damit zurecht, das neue srch32 aber nicht. Klar, solche Sätze gehören
> eliminiert. Keiner fragt, wie man die am besten mit Allegro-Bordmitteln
> eliminiert - die einen wissen es (nehme ich an), die andern wagen sich nicht
> dran? Das ist nur ein Beispiel, damit komme ich schon zurecht, aber solche
> Fragen innerhalb der Parameter lese ich ziemlich selten. Und ich frage selber ja
> auch nicht mehr, ehrlich: man dringt mit solchen Banalitäten (?) nicht durch!

Die "Bordmittel" sind leider extrem schlecht darin, irregulaeres zu erkennen
oder zu reparieren, weil sie ueblicherweise mit "allegro-Methdoden" an die
Aufgabe herangehen. Will sagen, im Zweifelsfall crasht auch das Werkzeug,
das die Daten "validieren" soll. Ich halte das fuer nicht banal.

viele Gruesse
Thomas Berger