Re: [Allegro] d-wrtf.apr: kein klick auf 1. exemplar/bestellung möglich

[Thomas Berger]

Lieber Herr Allers, lieber Herr Lehmann,

>> 1. mir fällt auf, sie haben es so formuliert:
>> #(s   Schlagw.
>> ...
>> #cc f" ;" =sw
>> ...
> 
>> am anfang? bewusst am anfang?
> 
> Ich denke, daß Leerzeichen sowie Semikolon am Anfang der Anwendervariablen #usw nichts zu suchen 
> haben und drum mit voller Absicht hier weggenommen werden.
>
>> wäre F" ;" nicht besser?

Jede Parameterdatei darf eigentlich ueberhaupt keine Annahmen
ueber den Inhalt der Daten machen (Ausnahme siehe unten).
[Speziell die #31er-Kategorien enthalten eine ziemliche
Bandbreite. Die Behandlung des "_" z.B. hat nichts mit den
v14-Verknuepfungen zu tun, sondern damit, dass seit etwa
1995 Importparameter kursieren, die aus MAB Schlagworte
uebernehmen und die SWD-Nummer mit "_" hintangestellt haben.
d-1.apr tut merkwuerdige Dinge mit ;;-Verdopplungen, deren
tieferer Grund ebenfalls diese _-Konstruktionen sind]

Die folgende Schleife ist so ausgelegt, dass der Anfang
der Kategorie bereits "bereinigt" ist, die Sprungbedingung
am Ende erzeugt dann wieder eine analoge Situation: Definitiv
verkuerzte Kategorie, wiederum bereinigter Anfang. Initial
muss daher eine zusaetzliche Bereinigung des Anfangs erfolgen,
damit auch der erste Schleifendurchlauf garantiert nicht
querschiesst.


> Das Wegnehmen von Leerzeichen und Semikolon am Ende von #usw geschieht ein paar Zeilen drunter, 
> in
> #usw C e"[_;]" F" "                            % sonst einfach nur anzeigen
> und in
> #usw dsW e"[_;]" F" " AsW                      % nichtleerer Text?
> 
>> 2. dann, in der cat.api ist aber nur ";" als trenner formuliert. 
>> NICHT: " ;"
>> greift ihre zeile überhaupt?
> 
> Die *Index*parameterdatei cat.api hat bei der hier diskutierten Frage nichts mit der 
> *Anzeige*parameterdatei d-wrtf.apr zu tun! Oder übersehe ich irgendeinen Umstand?

Herrn Lehmanns Ueberlegung ist gerechtfertigt: #31ff haben u.a. eine
Binnengliederung, d.h. es gibt - vorzugsweise im "Datenformat" kodifiziert -
Festlegungen fuer die Syntax. Lt. Allegro-Format sind etwa ";" und "¶"
erlaubte Trenner ("¶" kam hinzu, weil ich irgendwann einmal zu bedenken
gab, dass "; " [oder gar " ; "?] in Ordnungshilfen von Einzelschlagworten
vorkommen kann und daher nicht auch noch eine Funktion im Datenformat
uebernehmen /kann/. ";" wurde dann aber nicht als Trenner abgeschafft,
insofern ist nun alles komplizierter aber kein Problem geloest.

Es empfiehlt sich daher stets, die tatsaechliche Implementierung zurate zu
ziehen und in cat.api wird tatsaechlich alternativ an ";" und "¶" zerlegt.
Die Anzeigeparameter muessten das dementsprechend auch tun und im Beispiel
hier bei der Schleifenkonstruktion beruecksichtigen (Fuer d-1.apr war das egal,
weil nur der Text gezeigt wurde und "¶" fures Display auf Absatzwechsel
umgesetzt wird, im Zusammenhang mit Hyperlinks muss sorgfaeltiger gearbeitet
werden, denn zwei korrekte Einzellinks in je einer Zeile sind doch etwas anderes
als ein zweizeiliger Link mit Verklebungsunfall als Suchbegriff.
(d-wrtf.apr hat an dieser Stelle fatalerweise das "¶" nie als Trennzeichen
vorgesehen und meine Korrktur gestern hatte das leider auch nicht
beruecksichtigt)

Die oben angekuendigte Ausnahme ist also, dass auf der einen Ebene jeglicher
Zeichensalat als Kategorieinhalt zu korrekter Verarbeitung fuehren muss
(und insbesondere die #uY- und #uZ-Variablen sich nicht desynchronisieren
duerfen), aber natuerlich auch die fuer die Kategorie definierten (oder
faktisch etablierten) Steuerzeichen als solche zu beruecksichtigen sind (etwa
";" und "¶" zur Untergliederung oder die oben erwaehnten durch "_" abgetrennten
Normdatennummern). Auch hier darf wieder nicht davon ausgegangen werden, dass
die wie vorgesehen verwendet werden: ";" am Kategorieende etwa oder "; "
mit Spatien als Trenner oder das erwaehnte ";" in der Ordnungshilfe, das gar
nicht als internes Trennzeichen gedacht war. Wenn die erfassten Inhalte mit
den zugrundeliegenden Regeln in Konflikt stehen (oder wie im Fall der
Ordnungshilfe mit Semikolon die zugrundeliegenden Regeln untereinander in
Konflikt stehen) wird es natuerlich schwer, von "korrekter" Verarbeitung
zu sprechen und die Routine muss sich auf eine ganz formalistische
Definition zurueckziehen: Nach Anwendung aller Regeln fuer Steuerzeichen
duerfen wiederum keine weiteren Unterstellungen an die Arbeitstexte
gemacht werden, insbesondere koennen sie leer geworden sein, unbalancierte
Nichtsortierzeichen enthalten, unbalancierte Winkelklammern etc. pp.

viele Gruesse
Thomas Berger