AW: AW: [mab-list] MABXML

[Thomas Berger]

Lieber Herr Kett, liebe Liste,

> > 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).

Beides gleichzeitig ginge mit einem optionalen Attribut
<nsz typ="öffnend"/> und <nsz typ="schliessend"/>?

(oder "auf" und "zu", "(" und ")": Die Entscheidung fuer deutsche
Element- und Attributnamen in allen Ehren, die festen Inhalte
fuer Attribute sollten vielleicht keine "hoeheren" Deutsch-
kenntnisse erfordern). 

Ich wuerde die Prioritaeten so setzen, dass eine moeglichst
einfache Konversion fuer alle MAB-Dialekte *nach* MABXML
wichtiger ist als eine in die umgekehrte Richtung: Hier
hoffe ich naemlich, dass die von Ihnen in Zukunft bereitgestellten
Werkzeuge bekannter und einsetzbarer sein werden. Meine
Einschaetzung beruht darauf, dass ein Exportfilter *nach* MABXML
moeglichst einfach in Software xy hineinprogrammiert werden
koennen soll, wohingegen Import von MABXML durchaus die
Vorbehandlung durch einen externen Konverter voraussetzen 
darf. [Die Hoffnung ist natuerlich, dass sich in Zukunft
moeglichst viel auf MABXML Ebene 1 abspielt, wo wir diese
Probleme nicht haben, die Konverter aber komplexer sind]

Das Problem, dass gerade MABXML Ebene 0 nicht besonders viel
Spielraum fuer unterschiedliche Codierung gleicher Datensaetze
lassen sollte, sehe ich natuerlich auch. Bei falsch belegten
Datensaetzen und der Variante "Nichtsortiertext als *Element*"
erzeugt jedoch ein Konverter nach MABXML u.U. illegales XML, 
das sich ueberhaupt nicht verarbeiten laesst, bei Nutzung von
Nichtsortier-*Zeichen* hingegen haette auch ein sehr dummer
Konverter keine Chance, syntaktisch falsches XML zu erzeugen.

 
> > > 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.

Ich vermute, wir werden hier auch fuer MABXML Ebene 1 eine
gewisse Volatilitaet haben. Sprich, zwei verschiedene Programme,
die aus MAB MABXML erzeugen, werden sich im Output hier
moeglicherweise unterscheiden, ohne dass man sagen koennte,
das eine konvertiere "falsch" und das andere "richtig".


 
> > 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.

Das halte ich fuer ziemlich furchtbar:
1. Da hat man sich nun nach langem Zieren ueberwunden, Unterfelder
   wie in MARC zuzulassen und dann sind sie noch nicht einmal wie
   in MARC.

2. Ausgerechnet das super-neue Feld 671, von dem sich nach meinem
   Eindruck gerade herausstellt, dass es sowieso nicht die Probleme
   loest, fuer die es eingefuehrt wurde. Koennte nicht jemand fuer
   die naechste Sitzung des MAB-Ausschusses die Abschaffung von 671
   beantragen?

viele Gruesse
Thomas Berger

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