[Allegro] Umcodierung Benutzereingabe nur teilweise abschalten

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> #u1 y0 p" ;" E";"
>> #u1 b";" y0 f" " r5
>>
> Es geht einfacher:
> 
> #u1 P"*" b";" y0 f" " r5 p" ;" F" *"

das r5 auf einen Text angewandt, der "*" am Ende ergaenzt
hat, liefert allerdings ein anderes Ergebnis. "r6" koennte
die Sache reparieren.


>> und letzteres sollte eigentlich auch "/" und "," so differenziert behandeln wie
>> die Aufbereitung von #85 bei #-I (der Absatz zwischen #98u und #98H), hier ist
>> also noch einiges an Arbeit hineinzustecken, wenn auch Trunkierung an anderen
>> Delimitern erlaubt sein soll (etwa wenn alle Aufsaetze eines gegebenen
>> Berichtsjahrs einer Zeitschrift zu selektieren waeren)
>>
> Das wäre noch im einzelnen zu durchdenken, aber die angegebene
> Erweiterung der Zeile löst erstmal das Problem von Frau Koczian.
> Allerdings sind andere Zeichen wie "/" hier ja nicht explizit in die
> Vorbehandlung einbezogen, daher sehe ich wegen y0 eigentlich nicht,
> warum und in welchen Fällen es Probleme geben könnte.

Gerade das y0 ist ja ein weiteres Problem.

Die Umcodierung der Benutzereingabe hat eine doppelt schwere Aufgabe:

Zum einen muss sie (Benutzer-)eingaben punktgenau zum existierenden
Indexeintrag fuehren, die weitgehend identisch mit den Daten aus
dem Datensatz sind, der zum Indexat gefuehrt hat.

Zum anderen muss sie dafuer sorgen, dass die Abbildung idempotent ist,
Einfuettern der aufbereiteten Indexzeile (mit Rechtsbuendigkeit und
entfallener Interpunktion, besonders auch eigentlich entfallenden aber
per Zwischenteil oder sonstwie doch bei der Indexierung geretteter
Interpunktion) muss absolut exakt dieselbe Zeile liefern (sonst entgleist
seitenweises Blaettern in allen Web- und a30-Kontexten, m.W. auch bei
a99).

Dazu kommt dann noch die von Frau Koczian tangierte Trunkierungsproblematik,
es muss auch in Situationen ein (kontextabhaengig zu definieren) "korrekter"
Eintrag getroffen werden, wo die Eingabe keinen realen Daten oder
Indexeintraegen entspricht.

Bei #-I wird hinter ";" u.a. mit der p-Tabelle umcodiert (fuer die Bestandteile
hinter "/" , "-", ,",",  "+" oder "=", die alle mit "/" angehaengt werden),
daher lassen sich Faelle konstruieren, wo das y0 bei #-5 scheitert.

Vermutlich lohnt sich die Reparatur nicht, die im Kommentar bei #-I erwaehnten
Falle nn/mmm bzw. nn,mmm bzw. nn mmm  und die beruecksichtigte Interpunktion
" = " wirkt auf mich nicht unbedingt so, als sollten hier RAK-Daten aufbereitet
werden...

viele Gruesse
Thomas Berger




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk1iJjEACgkQYhMlmJ6W47My5gP/ZZPuJ0BJ0YYdAOgcy1v/RIIa
6OLujbrKmI6fe/bOH/Y8OVActgtWTYnhJF18vDSaSbv1ThO1V8zC7vFXKGgM6uDP
dUSLBWfrLpMoedz8qmn9fMw5wr5/HloaqFKG/7RaqH0OOkvGainYXgfc9UwTA4he
ZDS2iSR8peAXigtgeec=
=Mg00
-----END PGP SIGNATURE-----