[Allegro] VS-Sequenzen und .api

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

folgende Inkonsistenz ist vermutlich schon seit immer in der cat.api:

startet man die Demo-Datenbank und sucht per Fernglas im Register
der Titelanfaenge nach

Mr. William Shakespeares comedies, histories, & tragedies

dann gibt es keinen Treffer. Holt man hingegen irgendeine Aufnahme
in die Anzeige und gibt F7, dann funktioniert die obige Recherche
anschliessend stets bis zum Ende der Sitzung (und liefert einen Treffer).

In avanti-Zusammenhaengen (Web-Kataloge, a35, ...) wird der Suchbegriff
allerdings niemals seine Aufnahme treffen, das ist dann schon auffaellig...

Grund ist, dass i.apt eigentlich das "&" auf "+" umsetzt, jedoch
mit Ruecksicht auf die VS-Methodik von V23 (vb164) das "&" eine
Steuerzeichenfunktion bekommt, kenntlich durch die Zuweisung des
Wertes 9 in p- und q-Tabelle.

Das passiert jedoch "dynamisch" in cat.api, durch die Zeilen

  V24.4 (3 Zeilen)
#bp & 9    wegen V23 Unicode
#bq & 9
#dV        V23: VS-Ersetzungen im gesamten Satz

im Kontext von #-0 (Kurztitelaufbereitung)

Falls nie ein Kurzeintrag bestimmt wird, etwa weil z.B. acon
nur einen Suchbegriff bei #-1 ... #-9, #-:, #-; aufzubereiten
hat, haben diese Umbelegungen von "&" nie stattgefunden und es
wird nach "+" gesucht.

Bei der Indexierung hingegen ist es uneinheitlich und daher diese
Mail, da ich nicht genau weiss, was eigentlich passieren soll:

In a99 gelten die obigen Einstellungen fuer "&" unbeschraenkt fort,
d.h. alle Datensaetze sind ihnen unterworfen. #dV hingegen
wirkt immer ab der Stelle, wo es ausgefuehrt wird, d.h. Primaer-
schluessel werden mit "&#...;" in den Index gesetzt, sofern die
Daten so erfasst sind, fuer alles spaetere hingegen sind diese
Konstruktionen entsprechend den hinterlegten VS-Schluessel
umgewandelt und die ak-Abschnitte bekommen die nicht zu Gesicht.

Verzichtet man auf #dV, so gelten die ";" in den u.U. als Trenner
und ausserdem unterliegen "#nnn" den wohl gleichzeitig in der
.api aktivierten, unseligen Texel-Ersetzungen und werden teilweise
ebenfalls ausgeblendet.

Um Recherchen zu retten, kann und sollte man m.E. unbedingt auf die

#bp & 9    wegen V23 Unicode
#bq & 9

hinter #-0 verzichten und stattdessen

p & 9
q & 9

unmittelbar hinter der Einbindung der Umcodierungstabelle

ti

notieren.

Irgendwie unloesbar hingegen scheint mir zu bestimmen, ob bei den Marken
#-1 ... #-9, #-:, #-; nun ein Schluessel
gesucht werden soll, der mit oder eben ohne Anwendung der VS-
Methodik zustandegekommen ist:

Ich koennte bei #-: etwa ein
#dV
geben, dann wird der Suchbegriff "tucho=|2Tucholsky-а, Kurt"
auf "tucho=|2Tucholsky-a, Kurt" umgewandelt und trifft daher den
Primaer/Ersetzungsschluessel "tucho=|2Tucholsky-а, Kurt" gerade
/nicht/ (auch wenn ich bei #-: ein y0 gebe).

Dafuer trifft aber der Suchbegriff "ütucholsky-а, kurt  _tucho"
korrekterweise den existierenden Schluessel "|:ütucholsky-a, kurt  _tucho",
/obwohl/ ich y0 gebe.

Ohne #dV hingegen bin ich in einem aehnlichen Dilemma, manchmal muss
ich dem y0 ein y3 vorschalten, um die Sequenzersetzungen fuer den
konkreten Arbeitstext zu erzwingen, manchmal darf ich es nicht (im
Gros der Faelle, wo Standard-Umcodierungen per p oder q-Tabelle ausgefuehrt
werden, ist es gluecklicherweise egal: Die Umsetzungen sind erwuenscht und
finden statt).

Zu #dV gibt es m.E. keinen globalen Parameter (oder wuerde dx=1 auch
in einer Indexparameterdatei wirken?), das macht m.E. auch keinen Sinn,
denn in Ersetzungsschluesseln muessen ja die Inhalte weitestgehend so
wie eingegeben transportiert werden (unterstellt dabei, dass zuerst
V14-Ersetzungen stattfinden, denn in typischen Anzeige und Export-
parameterdateien wird man evtl. auch mit #ia jonglieren, jedenfalls
Wert darauf legen, dass die VS-Ersetzungen nachgelagert ausgefuehrt
werden, also auf konkrete Arbeitstexte anlaesslich deren Ausgabe)

Wirklichen Handlungsbedarf sehe ich nur fuer die oben benannte
Aenderung der "q & 9" etc. von "dynamisch" auf "statisch" (d.h.
#dV bei #-0 drin lassen), denn m.W. gibt es keine Anwendungen, die
auf die /vollen/ Primaer/Ersetzungsschluessel zugreifen und dem
Unterscheidungsproblem unterlaegen: Falls es das doch gibt, muss
fuer die jeweilige Anwendung im Einzelfall entschieden werden,
ob bei den Umcodierungssprungmarken y0's von #dV's oder y3's
flankiert werden muessen oder nicht.

viele Gruesse
Thomas Berger