AW: AW: [mab-list] MABXML

["Kett, Jürgen"]

Lieber Herr Berger, liebe Liste,

> Mein Standpunkt noch einmal knapp: 1. Ebene 0 
> sollte moeglichst trivial sein, aus Ruecksicht auf
>    Konverter von MAB-Diskette nach MABXML daher Nichtsortier-*Zeichen*
>    kennzeichnen, auch wenn einem MAB-Band ein Nichtsortier-Element
>    schenken wuerde.
> 
> 2. Gemeinsame Elementnamen in Ebene 0 und Ebene 1 sollten gleiche 
>    Bedeutung haben, d.h. dass "<uf/>xInhalt" in Ebene 0 nach dieser
>    Ansicht in Konflikt steht mit "<uf code="x">Inhalt</uf>" von 
>    Ebene 1 und das Element daher in Ebene 0 besser <ufz/> heissen
>    sollte.
Ich verstehe ihr Argument. Andererseits bietet eine Gleichbennung den
Vorteil, dass die Schemata der beiden Ebenen eher aufeinander aufbauen: Die
Elemente sind im wesentlichen die selben, nur ihre "Schema-Typen"
unterscheiden sich. Ich hätte aber auch kein Problem damit, das
Unterfeld-Element in Ebene 0 in <ufz/> umzubennnen. 

Was das Element <ns> anbelangt: Ihr Vorschlag war es, mit Rücksicht auf
MAB-Diskette sowohl das Nicht-Sortier-Anfang-Zeichen, als auch das
Nicht-Sortier-Ende-Zeichen auf den einen Code "<ns/>" abzubilden (anstatt
auf <ns> und </ns>). Dann müsste man nicht ein und dasselbe Zeichen in
MAB-Diskette (#xAA) auf zwei verschiedene Codes abbilden. Aber dann
verschiebt man dasselbe Problem auf die Rückkonversion: Bei einer Konversion
von MABXML Ebene 0 auf MAB müsste man dann den Code <ns/> auf zwei
verschiedene Zeichen (#x88 und #x89) abbilden. Eine möglichst einfache (Hin-
und Rück-)Konversion zwischen MAB und MABXML ist mir aber wichtiger als eine
zwischen MAB-Diskette und MABXML (beides gleichzeitig geht leider nicht).

> > > Ob man die Stichwortkennungen ueberhaupt
> > >    behandeln sollte, weiss ich nicht, schliesslich muss
> > >    man ja erst in MAB 030 Position 8 nachsehen, ob "{...}"
> > >    die Spezialbedeutung hat, oder auf die schliessende
> > >    Klammer verzichtet wird oder es keine Spezialbedeutung
> > >    gibt: Strenggenommen ist also "Stichwort" eine
> > >    Funktionalitaet einer Protokollstufe oberhalb von MAB.
> > >    (und "{" und "}" machen aus XML-Sicht nun wirklich keine
> > >    Probleme). Umgekehrt koennte man ueberlegen, ob man
> > >    nicht das - ebenfalls wirklich harmlose - Fuellzeichen
> > >    "|" als <fsz/> expliziter macht, vermutlich wuerde das
> > >    aber die Lesbarkeit so stoeren, dass man es lieber nicht
> > >    tut.
> > Wissen Sie (oder ein anderer Kollege), ob Feld 030 das einzige 
> > MAB-Feld ist, in dem die Stichwort-Beginn- und 
> Stichwort-Ende-Zeichen 
> > vorkommen?
> 
> Dort kommen sie nicht vor, sondern dort wird fuer den 
> gesamten Datensatz geregelt, ob und wie "{" sowie ob "}" eine 
> Spezial- bedeutung als Stichwortzeichen haben. Ein Konverter 
> muesste MAB 030 analysieren um herauszufinden, ob er "{" in 
> "Stichwortzeichen" umwandeln *darf* oder es als "{" belassen muss.
Nach Rücksprache mit Kollegen, bin ich mir nicht so sicher, ob man diesen
Punkt so restriktiv auffassen kann. Was gilt beispielsweise, wenn der Code
nicht belegt ist (also mit "|"). 
Aber zum Thema <stw>: Es ist richtig, wenn sie sagen, dass Stichwortzeichen
in Ebene 0 nicht unbedingt umkodiert werden müssen. Entweder, man sollte es
als Angebot beibehalten oder es gänzlich verwerfen. Einen "Zwang" zur
Kodierung der Stichwortzeichen sollte es nicht geben. 

Zur optischen Formatierung:
Ich bin mit ihren Vorschlägen, was die Benutzung des Leerzeichens für Ebene
0 anbelangt, einverstanden. 
Was Ebene 1 anbelangte habe ich zumindest einen Einwand:

> 2. Ein Feld mit Unterfeldern hat keinen Inhalt 
> ausserhalb eines
>    Unterfeldes

Das ist in dem neuen Feld 671 leider nicht der Fall
(http://www.ddb.de/professionell/pdf/mab_671.pdf). Dieses Feld kann
Unterfelder enthalten und hat gleichzeitig einen festen Vorspann außerhalb
von Unterfeldern.

Viele Grüße
Jürgen Kett

----------------------------------------------------------------------
Zum Austragen aus dieser Liste senden Sie bitte eine Mail an
majordomo at ddb.de mit unsubscribe mab-list im Textfeld.