[Allegro] Mehr zum Neutralformat

Bernhard Eversberg ev at biblio.tu-bs.de
Mi Nov 30 12:34:38 CET 2005


Thomas Berger schrieb:

>>Es geht nur noch um
>>
>>1. Die Codes für Teilfeldcode und Nichtsortierzeichen.
>>   Wir wollen keine Steuerzeichen vorschreiben, die im ANSI-Code
>>   oberhalb 127 liegen!
>>   Jetzt favorisieren wir
>>   ^ (Code 94) Teilfeldcode
> 
> Fuer MARC wird der Unterfeldcode meist als "|" oder "$" visualisiert.
> 
Der $ geht nicht, der kommt zu oft in Titeln vor. Das | ist weniger
leicht eingebbar als ^, deshalb wollen wir letzteres nehmen.
Visualisieren kann man natürlich jederzeit auch anders, das ist nicht so
wichtig.

> 
>>   ` (Code 96) Nichtsortierzeichen
> 
> Meist als "_" visualisiert
Oft aber auch ^. Wir wollen, wie oben begründet, ^ aber als Teilfeldcode
und (siehe unten) _ als V14-Ersetzungscode. Der ` hat hier den Vorteil,
daß er nicht so aufdringlich hervorsticht, wenn man in einer
Visualisierung das Ausblenden vergißt oder nicht machen kann.

> 
>>   Fest stehen bereits:
>>   | (Code 124) Mehrfachfeld-Trennzeichen
> 
> Das Teilfeld-Zeichen von MAB?
MAB wird doch abgeschafft!

 > Wenn man mit Unterfeldern und
> internen Feldwiederholungen arbeitet, geht die Semantik meistens
> Badn:
> 
> Ist
> #kkf $u abc | xyz
> 
> ein Doppel-Inhalt fuer Unterfeld u oder ist es eine
> (verunglueckte?) Wiederholung von #kkf?
Ein | trennt zwei Feldinhalte der gleichen Art. Ein Unterfeld
gilt damit NUR für den Inhalt, der mit ihm zwischen zwei | steht.
Doppelinhalte von Unterfeldern sind nicht vorgesehen!! (Es sei denn,
ein Anwender macht sich dafür noch eine eigene Syntax.)
Damit kann es dann kein Mißverständnis geben.

> 
> Viele der Mehrdeutigkeiten wird man los, indem man (wie bei MARC)
> nur die Alternative laesst zwischen Feldern, die ueberhaupt keine
> Unterfrelder ermoeglichen und Feldern, wo kein Inhalt ausserhalb
> von Unterfeldern erlaubt ist.
Das ist zu rigide. Wir wollen Teilfelder sparsam verwenden, viele
Felder werden gar keine haben oder aber nicht in jedem Fall. Dann ist
das stereotype $a am Feldbeginn, wie bei MARC, einfach nur lästig.

> 
> D.h. die in MAB und allegro beliebten Inhalts-Mixes wie
> #90 Sig N atur $u ich
> oder
> #99n20051129/00:00:00$user
> sind undbedingt zu vermeiden!
Das sehen wir, wie soeben begründet, anders.

>>   _ (Code 95) V14-Ersetzungscode (wie A.CFG)
> 
> 
> In Pica z.B. als "!" visualisiert (problematisch), ich meine,
> ich haette auch schon einmal "^" gesehen.
Wie auch immer, wir bleiben bei _ .

> Ich schlage uebrigens den Einsatz der (mit v23 implementierten)
> alternativen v14-Methode (i5=xx) vor.
Was genau meinen Sie damit? Für welche Art von Daten?

>>   @ (Code 64) Entstoppungszeichen
> 
> Stopwortlisten sind eigentlich nicht mehr zeitgemaess, also wird
> auch kein Entstoppungszeichen benoetigt.
Wir können das aber nicht dekretieren, sondern müssen dem Anwender
die Möglichkeit lassen.

> 
> VS-Sequenzen fuer numerische HTML-Entitaeten und die Standard-
> Entitaeten (& vor allem) sollte ebenfalls von vorneherein
> eingebaut werden, d.h. "&" ist Steuerzeichen und ein woertliches "&"
> sollte in den Daten als "&" auftreten.
> 
Das können wir leicht von der Standard-A-Implementierung übernehmnen.

MfG B.E.




Mehr Informationen über die Mailingliste Allegro