Re: [Allegro] kleine ergänzungen zum neuen ALF-paket für a99

Klaus Lehmann lehmann_klaus at t-online.de
Mo Dez 12 13:25:46 CET 2005


On Mon, 12 Dec 2005 12:28:20 +0100, Bernhard Eversberg wrote:

guten tag herr eversberg,


kl>> a-ex.flx
kl>> kann es sein, daß dieses flex folgendes tut?
kl>> die exemplarsätze, die hiermit global angelegt werden sollen,
landen
kl>> beim testen in der datenbanknummer _1.ald . das dürfte so nicht
kl>> stimmen. die exemplare müssten m.E. in _230.ald landen..... ?!!!
kl>Gut, wird eingebaut. Obwohl es mehr Kosmetik ist, schaden tut es
kl>keinesfalls, wenn die Sätze in eine andere Datei gehen, und sei
kl>es die 1.

naja, kosmetik hin und her. 
'denke, es gab eine empfehlung, in welche datenbankdateien die
verschiedene dos-alf-datensätze reingehören. diese struktur sollten wir
auch für a99-alf übernehmen.

es gibt SEHR viele bibliotheken, die auf alf-a99 warten, damit sie
endlich aus dos wegkommen; und die schon dos-alf zu laufen haben. wenn
das dos-alf nicht so monolithisch aufgebaut wäre, wäre es ja alles kein
problem... (da dos-alf ist längst an grenzen herangekommen...)





kl>> a-trenn.flx
kl>> hier wurde bei einem durchgang hierarchisches getrennt. 
kl>> aber es wurden ca 240 bände erzeugt, die eine eigene #09 haben
(mit "+"
kl>> drin!)
kl>> 
kl>> wird #09 dann angelegt, wenn dieser datensatz eine eigenständige
#00
kl>> bekommen soll, und in der #09 die (quer)beziehung zu dem irgendwo
kl>> vorkommenden #00 notiert ist????
kl>So ist es.
kl>
kl>
kl>> verstehe ich das richtig? wer
kl>> benötiogt diese konstruktion????
kl>> 
kl>> 
kl>Das brauchen z.B Pica-Mitglieder, die in #00 die Pica-Nr. des 
kl>Untersatzes haben. Wir hätten natürlich entscheiden können,
kl>daß die in dem Falle in #09 käme, aber wäre das eine bessere Logik?

ich denke, diese zusätzliche vergabe in #09 ist für die
anwender-bibliotheken hinderlich (? was für ein deutsch, sorry!).
vielleicht auch sehr verwirrend. bislang (und das seit 10 jahren?) gehe
ich von identnummern in #00 aus, und nicht von zusatzkonstruktionen in
#09.

pica kann haben, was pica will.

für meinen teil: #09 als identnummer ist nicht produktiv. vermutlich
erzeugt es fehler, wie ich es in der nächtlichen email beschrieb: 

"a-trenn.flx
hier wurde bei einem durchgang hierarchisches getrennt. 
aber es wurden ca 240 bände erzeugt, die eine eigene #09 haben (mit "+"
drin!) und sie waren sehr unsinnig alle mit dem ersten auftretenden
übergeordneten werk in der #00 verknüpft. also alle zeigten sie auf
denselben datensatz mit der einen #00"


das hat für mich die konsequenz, alle verweise und befehle auf #09
herauszunehmen.




viele grüße
k.lehmann








Mehr Informationen über die Mailingliste Allegro