[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Thomas Berger]

Lieber Herr Eversberg,

> Grundsätzlich muß man sagen: Die interne Methodik der Adressierung
> von Feldern ist rigoros auf Performanz optimiert. Das ist bei allen
> umfänglichen Exporten, und bes. beim Indexieren, wichtig. Da müssen
> mitunter weit mehr als 1000mal einzelne Felder angesprochen, also
> im internen Speicher aufgefunden werden. Das geschieht nicht durch
> ein textuelles parsing durch den Satztext, sondern beim Einlesen wird
> eine Hilfsliste angelegt (Array int gi[] in record.cpp). Beim Einlesen
> der Parameter werden dann die Feldnummern im Parameterspeicher auch
> nicht als solche abgelegt, sondern deren interne Nummern, die sich aus
> der CFG-Reihenfolge ergeben. Hinzu tritt der Mehrfachcode. So wird
> jedes Feld sehr schnell gefunden.
> Ganz ähnlich ist es mit den #u-Variablen.
> In dieser Methodik wäre es nun ein Problem, Mehrfachfelder zu verwalten,
> die kein unterscheidendes Merkmal haben, wie z.B. in MARC21, Unimarc und
> teilweise in Pica3. Die kann man nicht eindeutig adressieren. Auch die
> Idee mit den nicht festgelegten Feldnummernlängen oder mit den mehr
> als einstelligen Wiederholungskennungen wäre nicht einfach zu lösen.
> 
> Und wenn man nun daranginge, die interne Struktur und Adressierung der
> Datensätze und -felder grundlegend zu ändern, hätte das weitreichende
> Auswirkungen auf Parameter und FLEX. Sicher wird hieraus verständlich,

Ich lese aus Ihren Ausfuehrungen eigentlich nichts hinderndes:

/intern/ ist der Datensatz angemessen aufbereitet, so dass /Zugriff/
vermoege Information erfolgen kann, die nicht *im* Datensatz steht,
sondern beim Einlesen aus ihm erschlossen worden ist. Insofern gibt
es da keinen Zwang, Wiederholungszaehler in der .ald-Datei abzulegen
oder intern mit exakt als Byte gespeicherten Integers im Bereich
gewisser Zahlen unter Ausschluss einer komplizierten Liste gewisser
Werte zu operieren (es ist nur so schoen praktisch, dass die
Komponenten "Speicher" und "Eingabe" sich quasi intuitiv ueber die
Zaehlung der gewuenschten Wiederholung austauschen koennen, aber die
Diskussion der letzten Tage hat gezeigt, dass die in a99 erforderlichen
Umcodierungen angeblicher "Zeichen" Gift dafuer sind).

"angemessen" bzw. "auf Performanz optimiert" ist nichts absolutes:
Wenn wir in Zukunft mehr MARC-artige Daten haben, also Unterfelder
(auch wiederholbare und frei angeordnete) in den Feldern die Regel
sind und nicht die Ausnahme, waere es "angemessen", die Performanz
auf besseren Zugriff auf Unterfelder zu optimieren.

Wahr ist natuerlich, dass der Versuch, die "Folgebuchstaben" entsprechend
ihrer Bedeutung in "echte, indikatorartige" und "artifizielle,
zaehlerartige" zu differenzieren, sich irgendwie in den Adressierungs-
Methoden etwa der Flexsprache niederschlagen wuerde: Deswegen macht
man es ja.

Wenn man es durchdenkt, gibt es auch andere Folgen: Warum sind die
"echten, indikatorartigen" nicht wiederholbar, wie es bei echten
Indikatoren von (wiederholbaren) Feldern ist: Das liesse sich dann
realisieren, wenn man es will. Oder man fasst es als "variable
Kategorielaenge" auf: Eigentlich kein zusaetzliches Problem.

Die Sache mit den variablen Kategorielaengen ist m.E. ein ziemlich
triviales Problem, wenn man ein eindeutiges Zeichen hat, das Feldnummer
vom Feldinhalt trennt. In MARC-artigen Formaten (zumindest bei den
data fields, nicht bei control fields und leader) ist das gegeben:
Diese haben keinerlei Content jenseits von Unterfeldern...

viele Gruesse
Thomas Berger