[Allegro] Reminder: Acon-Bugs

Di Aug 25 12:50:37 CEST 2015

lieber herr berger (und Herr Eversberg)

> Noch einmal zur Genese der Lehmann-Probleme: Die diversen Varianten
welch' ehre ;-)
s.a. bitte unten weiter!

> des *update.job* als Ersatz von update.exe haben urspruenglich ein
> simples find durchgefuehrt.
> Die "Braunschweiger" Variante hat irgendwann gemerkt, dass Suchbegriffe
> wohl besser in "..." einzuschliessen waeren.
> Die "Bonner" Variante hingegen hat bemerkt, dass doppelte Umcodierungen
> ein Problem sein koennten und "_" vorangesetzt, den Suchbegriff aber
> normalerweise nicht in "..." eingeschlossen (ausser beim Vorliegen von
> runden Klammern). Irgendwann habe ich bemerkt, dass Haeufiger
> Anfuehrungszeichen gesetzt werden mussten, habe dabei aber die Syntax
> falsch geraten:
> find IDN _"a b c"
> sucht (ohne Umcodierung) nach der Zeichenkette '"a b c"' im Register
> IDN (und stolpert ueber " and ", "(" etc.), nur
> find IDN "_a b c"
> haelt den Suchbegriff zusammen *und* schaltet die Umcodierung aus.
> Das zeigten allerdings auch erst die Lehmann-Beispiele, wo dann
> trotz scheinbarem In-"..."-setzen die Schluessel so gekappt wurden,
> als seien die Anfuerhungszeichen nicht vorhanden und ausserdem
> vorhandene Versionen solcher Saetze nie getroffen wurden.
ich  kann  gerne  noch mal meine liste veröffentlichen. bin sicher, es
gibt  auch  noch  andere  kollegen aus der praxis HIER, die verzwickte
primäre schlüssel haben.

so:
ich bekomme mit, daß bei diesen "suchen" oder "vergleichen" (letzteres
ist ja auch eine art "suche"), folgende zeichen eine rolle spielen:
-*;_    [moch mehr?]

[das  wort  "and" wohl auch]
[irgendwie habe ich das aber in der praxis doch nicht erlebt?]

DAS da oben ist nicht gut!
wie  ich  ja öfters schrieb, tauchen diese zeichen auch in kombination
eines  einzelnen  zeichens eben in sachtiteln (oder was man immer auch
für einen sachtitel hält!) auf.

wie sieht es mit dem "\" aus? man kann es auch mit selber "escapen", als
"\\". ich bin nicht für dioe einführung von "\" .....

WILL auf folgendes hinaus:
man  sollte  ein(?) oder eine kombination mehrerer zeichen nehmen, die
etwas  "einführt". also sowas wie das "\". wobei dieses für mich eher
eine  art  "natürliches" zeichen ist. "natürlich"="gebräuchlich". also
lieber nicht.

es sollte ein zeichen sein, wie allegro sie ja schon benutzt:
decimal000 (ist bereits belegt)
decimal001 (")
decimal035 (ist bereits belegt!)

was ist mit:
decimal002 bis decimal009
oder decimal019
decimal016-019 sind auch ganz nett.
bin   sicher,  daß  dise  zeichen  wohl  kaum  in  (pseudo)"sachtiteln
vorkommen.....

ist das nachdenkenswert?
grüße vom k.l.

> viele Gruesse
> Thomas Berger

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?

Am Dienstag, 25. August 2015 um 12:31 schrieben Sie:
> Am 25.08.2015 um 11:51 schrieb Bernhard Eversberg:
>> Am 25.08.2015 um 11:43 schrieb Thomas Berger:
>>> Wurzel allen Uebels ist m.E., dass man in den 1990er Jahren besonders
>>> smart sein wollte und den Benutzer nicht durch Syntaxvorschriften wie
>>> "Suchbegriffe in Anfuehrungszeichen setzen" ueberfordern wollte. ...
>> .............
>> 
>> Da walzen Sie allerhand Gemeinplätze aus und tiefschürfende
>> Fundamentalkritik, aber damit kommen wir in der Sache nicht weiter.
>> Oder wollen Sie sagen, die Mühe wäre vergebens, es ist eh alles
>> verkorkst, und jedwede Änderung wäre nur Verschlimmbesserung?

> Soweit ich es rekonstruieren kann, ging es darum, ob der Parser
> eine illegale Syntax ueberhaupt erkennen kann oder ob einfach
> alles "Null Treffer" ist. Sie brachten dabei das Beispiel, dass
> am " and " der Beginn eines neuen Terms erkannt wird aber keine
> Pruefungen passieren, ob hier nun eine Registerangabe und/oder
> ein Suchbegriff fuer diesen Term folgen.
> Wenn man hier akzeptieren muss, dass wohl in jedem Fall irgendwas
> gesucht wird, illegale Suchbegriffe also gar nicht existieren
> koennen, so ist dagegen zu setzen, dass das so stark von
> Implementierungsdetails abhaengt, dass niemand mehr weiss /was/
> da eigentlich gesucht wurde. Na gut.
> Es ist aber wirklich nicht hilfreich, nun die temporaere
> Verbiegung des Benennung des AND-Operators in Humtata anzubieten,
> denn wenn ich zu traege bin, den Suchbegriff in "..." einzuschliessen,
> dann werde ich wohl auch zu traege sein, ihn auf "gefaehrliche"
> Inhalte zu untersuchen und entsprechende Operatornamen auszudenken.

> Noch einmal zur Genese der Lehmann-Probleme: Die diversen Varianten
> des *update.job* als Ersatz von update.exe haben urspruenglich ein
> simples find durchgefuehrt.

> Die "Braunschweiger" Variante hat irgendwann gemerkt, dass Suchbegriffe
> wohl besser in "..." einzuschliessen waeren.

> Die "Bonner" Variante hingegen hat bemerkt, dass doppelte Umcodierungen
> ein Problem sein koennten und "_" vorangesetzt, den Suchbegriff aber
> normalerweise nicht in "..." eingeschlossen (ausser beim Vorliegen von
> runden Klammern). Irgendwann habe ich bemerkt, dass Haeufiger
> Anfuehrungszeichen gesetzt werden mussten, habe dabei aber die Syntax
> falsch geraten:
> find IDN _"a b c"
> sucht (ohne Umcodierung) nach der Zeichenkette '"a b c"' im Register
> IDN (und stolpert ueber " and ", "(" etc.), nur
> find IDN "_a b c"
> haelt den Suchbegriff zusammen *und* schaltet die Umcodierung aus.
> Das zeigten allerdings auch erst die Lehmann-Beispiele, wo dann
> trotz scheinbarem In-"..."-setzen die Schluessel so gekappt wurden,
> als seien die Anfuerhungszeichen nicht vorhanden und ausserdem
> vorhandene Versionen solcher Saetze nie getroffen wurden.

> viele Gruesse
> Thomas Berger

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro