[mab-list] MABXML
Thomas Berger
ThB at gymel.com
Tue Nov 11 15:40:22 CET 2003
Lieber Herr Kett, liebe Liste,
> Bis Freitag, den 21.11.2003, wird eine Test-Version von MABXML online
> gehen (URL, etc. werden noch bekannt gegeben). Diese Version wird im
> Anschluss für einen Monat (bis zum 19.12.03) als Testversion bestehen
> bleiben und nach Ablauf dieser Test-Phase in das erste Release
> übergehen.
Testversion bedeutet, dass Sie einen Namespace festlegen
und die xsd-Dateien (Schemadefinitionen) online zugaenglich
machen?
> Es bleiben also zwei Änderungsphasen für die ich dringend ihre Kritik
> und Anregungen (insbesondere zu MABXML Ebene 1) benötige, damit daraus
> eine stabile erste Version entsteht:
>
> 1. Änderungen vor der Veröffentlichung der Testversion
> 2. Änderungen an der Testversion vor dem ersten Release
Folgende Anmerkungen habe ich, vor allem zu Abschnitt 5:
Inzwischen ist mir aufgefallen, dass man wegen der Problematik
mit den Zeichen unterhalb ASCII 31 mit einer XML-Applikation
kein MAB (woher auch immer) exportieren kann. Insofern gewinnt
(fuer mich) auch die Stufe 0 an Bedeutung: Mit XSL-Transformationen
o.ae. kann man mit XML-Applikationen Stufe 0 und 1 gegenseitig
auseinander generieren, fuer die Konversion von MAB zu MABXML
Stufe 0 und umbekehrt kann man ziemlich dumme Programme einsetzen,
denn gerade fuer MABXML Stufe 0 braucht es keinen echten
XML-Parser.
Ziel auch von MABXML Stufe 0 sollte es sein, den Unterschied
zwischen MAB-Band und MAB-Diskette auszugleichen. Das
erfolgt in Ihrem Entwurf auch groesstenteils, wenn man
bedenkt, dass die "richtigen" Satz- und Feldendezeichen
auf XML-Elemente umzusetzen sind. Zeichensatzunterschiede
werden im XML-Header explizit gemacht, es bleibt also noch
das unten beruecksichtigte Problem des Headers als
Pseudodatenfeld ### mit Indikator Spatium.
Die Generierungsvorschrift 5.2. sollte m.E. sein:
1. Isoliere einen MAB-Datensatz und entferne das Satzendezeichen
(Tabelle 2 enthaelt das Satzendezeichen noch als spaeter
umzusetzendes, das Beispiel jedoch nicht), falls der
Satz (MAB-Diskette) mit "### " beginnt, entferne auch dies.
Das ist dann der "Inhalt" des Datensatzes.
2. Schuetze die ueblichen Zeichen mit Steuerfunktion in XML,
naemlich "&" sowie "<" und ">" (einfache und doppelte
Anfuehrungszeichen muessen nur in Attributen geschuetzt
werden, die haben wir hier nicht). [Dieser Schutz koennte
theoretisch nicht nur durch Escapen als & sowie <
und > erfolgen, sondern auch durch Umwandeln in CDATA-
Abschnitte, das muss aber mit groesster Vorsicht erfolgen,
da ja noch XML-Elemente eingefuehrt werden.
3. Ersetze alle Zeichen mit MAB-Steuerbedeutung durch
XML-Tags, naemlich die Tabelle 2, wobei "Satzendezeichen"
entfaellt und die Spalte Zeichenpositionen nur den MAB2-
Zeichensatz wiedergibt, fuer MAB-Diskette analog.
Fuer Feldendeezeichen und Teilfeldtrennzeichen ist
somit alles klar, auch fuer das Stichwortzeichen.
Nichtsortierzeichen sind im MAB2-Zeichensatz zwei
verschiedene, es ist also einfach, diese mechanisch
in oeffnende und schliessende Tags des ns-Elements
umzuwandeln. In MAB-Diskette muss man hierfuer mitzaehlen.
Beim Unterfeld sehe ich das Problem, dass hier eine
Elementbezeichnung ("uf") gewaehlt wird, die es auch
in MABXML Stufe 1 und 2 gibt, dort nur mit anderer
Bedeutung, das koennte verwirren.
Ein alternativer Ansatz koennte daher sein, XML-Elemente
fez, ufz, tfz, nsz, (und stwz?) zu definieren, die
nur die *Zeichen* abbilden: Damit waere die moegliche
Verwirrung zwischen uf und ufz abgemildert, und
Worte in Nichtsortierzeichen waeren in (<nsz/>...<nsz/>)
eingeschlossen, was das Auswerten von Paarigkeit auf
die Konversion zwischen Stufe 0 und 1 verlagert bzw.
auf den Reimport nach MAB-Band, nicht jedoch die
Umwandlung von MAB-Diskette nach MABXML Stufe 0
erschwert. [Man koennte zusaetzlich auch <ns>...</ns>
erlauben...]. 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.
4. Besonderes Augenmerk sollte man Leerzeichen (im XML-
Sinne, also auch TAB, Zeilenumbruch und einige wenige
mehr) widmen: MAB kennt nur das Leerzeichen, d.h.
Zeilenumbruch und TAB sind illegal, anderseits gibt
es Felder, in denen Mehrfachleerzeichen bedeutungs-
tragend sind.
a) Man kann zunaechst einmal konstatieren, dass jedes
XML-Space-Zeichen (also auch Umbrueche etc.) in MAB
einem regulaeren Leerzeichen entspricht.
b) Weil keine Feldnummer mit Spatium beginnt und es
keine Unterfelder mit Feldcode Spatium gibt, kann
man festlegen, dass - um die Lesbarkeit zu erhoehen -
hinter <datensatz>, <fe/> und <uf/> (bzw. <fez/> und
<ufz/> nach meinem Vorschlag) Spatien (also auch
Zeilenumbrueche) in beliebiger Zahl erlaubt sind.
Damit waere dann Ihr Beispiel 7 gerettet, das ja auch
Formatierungen enthaelt:
<?xml version="1.0" encoding="UTF-8"?>
<datensatz>
0200nM2.01200024 l001 090020707<fe/>
02a20031014<fe/>
003 20031014103559<fe/>
...
050 a||||||||<fe/>
...
200 <uf/>01<uf/>b1966<uf/>f3Z 2707<uf/>gVaih<fe/>
210a<uf/>j1966<fe/>
</datensatz>
Schoen waere es natuerlich, auch die Unterfelder
lesbarer gestalten zu koennen, also etwa
200 <uf/>01
<uf/>b1966
<uf/>f3Z 2707
<uf/>gVaih
<fe/>
Dies wuerde bedeuten, dass man auch *vor* <uf/> und
<fe/> (bzw. <ufz/> und <fez/>) Spatien beliebig
hinzufuegen und entfernen kann, weil in "echtem" MAB
klar ist, dass hier nie welche sein koennen.
(Im Beispiel beim <uf/> direkt hinter "200 " muss man
natuerlich aufpassen, weil hier " " der Indikator ist
und nicht weggenommen werden darf, Hinzufuegen sollte
jedoch gefahrlos sein). Nach meiner Erfahrung mit
USMARC-verarbeitender Software steckt diese Semantik
zumindest hinter MARC21: Liefert man hier wie erwartet
Inhalte mit Teilfeldern und folgender Interpunktion, so
muss man von der Interpunktion (etwa " : ") allerdings
die abschliessenden Spatien entfernen, weil sonst die
ueblichen Verarbeitungsparadigmen entgleisen, d.h. man
liefert "245 $aTitel /$cVerfasserangabe", das " " hinter
"/" wird anscheinend viel spaeter von der Software ergaenzt,
in dem Moment, wo "$c" erkannt wird.
D.h. in USMARC ist es so, dass (Teil)felder nicht mit
Spatien beginnen oder enden koennen, insofern kann man
an diesen Stellen gefahrlos in XML Spatien einfuegen, weil
klar ist, dass sie artifiziell sind. Fuer MAB ist mir
nur klar, dass dies fuer den Anfang von Feldern nicht gilt
(vgl. das pathologische, aber wichtige Feld 902, das
typischerweise mit mehreren Spatien beginnt), fuer das
Ende von Feldern aber wohl. Bei Unterfeldern duerfte alles
problemlos sein, wenn man unterstellt, dass ein Feld mit
Unterfeldern keinen Inhalt ausserhalb der Unterfelder
haben darf, (also "070 test $a weiter gehts" nicht legal
ist). Beim Teilfeldzeichen bzw. Feldteilungszeichen
hingegen ist klar, dass man die Leerzeichen sowohl davor
als auch dahinter besser nicht modifizieren sollte...
Was ich leider nicht ueberblicke ist, welche Aspekte
dieser von mir diskutieren Spatiensemantik man in
einer Schemadatei formalisieren kann und ob man dies
formalisieren muss oder es ausreicht, sie verbal
formuliert in einem Dokument "Vorschriften fuer MAB <->
MABXML-Konverter" niederzulegen.
Wichtig ist mir jedenfalls, dass Ihr Beispiel 7 tatsaechlich
legales MABXML ist, d.h. es muss Stellen geben, an denen
man Zeilenumbrueche und Einrueckungen einfuegen kann,
ohne die Bedeutung des "darunterliegenden" MAB-Datensatzes
zu beeinflussen.
5. Umschliesse das Resultat mit den Tags "<datensatz>"...
"</datensatz>".
6.
Fuer MABXML Ebene 1, das ich auch als das Hauptarbeitspferd
ansehe und das demnach am sorgfaeltigsten geplant werden muss,
stellt sich vieles etwas einfacher dar. Die Generierungs-
vorschrift koennte lauten:
1. Identifiziere Felder bzw. Unterfelder im MAB-Datensatz
und isoliere Feldnummer, Indikator und Unterfeldcode.
Der Header ist wegzunehmen und gewisse Headerinformationen
sind zu merken. Es bleibt der "Inhalt".
2. Schuetze die ueblichen Zeichen mit Steuerfunktion in XML,
... Nichtsortierzeichen muessen jedoch unbedingt paarig
als <ns>...<ns/> umgesetzt werden (Falls die Vorlage
unpaarige Zeichen enthaelt => Error).
3. Umschliesse den so aufbereiteten Inhalt eines
a) Unterfelds mit <uf>...</uf> (Und ueberfuehre den
Unterfeldcode als Attribut "code" des so entstehenden
XML-Elements).
Dabei ist Leerraum sowohl am Anfang als auch am Ende
artifiziell, darf also hinzugefuegt oder weggenommen werden
b) Feldes, das Unterfelder enthaelt, mit <feld>...</feld>
(und ueberfuehre Feldnummer und Indikator in die
entsprechenden Attribute "nr" und "ind" des so entstehenden
XML-Elements).
Jeglicher Leerraum ist dabei Artifiziell (sofern er
nicht in den uf-Unterelementen sitzt), d.h. sowohl
vor, hinter als auch zwischen den uf-Unterelementen
darf er beliebig eingefuegt oder weggenommen werden
c) Feldes ohne Unterfelder mit <feld>...<feld> usf. wie
bei b).
Leerraum am Ende des Feldes ist dabei artifiziell.
4. Umschliesse alle so gewonnenen Felder mit <datensatz>...
</datensatz> und vergebe dem so entstandenen XML-Element
die benoetigten und optionalen Attribute aus dem Header.
<datensatz> hat nur <feld>-Unterelemente, d.h. jeglicher
Text-Inhalt ist (artifizieller) Leerraum, analog 3.b)
Mit diesen Regln kann Ihr Beispiel 15 fast gerettet
werden:
Beispiel 15 (unvollständiger Datensatz)
<datensatz typ="h" status="n" mabVersion="M2.0">
<feld nr="089" ind=" ">Schuljahr
10.<tf/>Erweiterungskurs.<tf/>Hauptbd.
</feld>
<feld nr="100" ind="b">Ernst, Klaus</feld>
<feld nr="200" ind=" ">Institut für
Geschichtswissenschaft
</feld>
<feld nr="652" ind="a">
<uf code="a">
Diskette
</uf>
</feld>
</datensatz>
(oder auch - das waere eine "typische" Formatierung von
XSL-Prozessoren)
<feld nr="652" ind="a">
<uf code="a">Diskette</uf>
</feld>
oder meinetwegen
<feld nr="652" ind="a"><uf code="a">Diskette</uf></feld>
Sowieso legal ist natuerlich das Einfuegen von Zeilenumbruechen
in die Tags, das folgende Beispiel hat nur artifzielle
Leerzeichen in den text-Nodes von "datensatz" und am Ende
von "feld"-Elementen:
<datensatz typ="h"
status="n"
mabVersion="M2.0">
<feld nr="089" ind=" "
>Schuljahr 10.<tf
/>Erweiterungskurs.<tf
/>Hauptbd.
</feld>
<feld nr="100" ind="b"
>Ernst, Klaus
</feld>
<feld nr="200" ind=" "
>Institut für Geschichtswissenschaft
</feld>
...
</datensatz>
Diese Umsetzung ist natuerlich besonders "treu" und koennte
von Konversionssoftware von MAB nach XML genutzt werden, die
die Bedeutung von Spatien in MAB2 lieber ungeklaert lassen
moechte. Bei der Weiterverarbeitung (etwa Umwandlung nach
Ebene 0) mit XML-Software waere es allerdings nuetzlich,
etwas freier mit Spatien umgehen zu duerfen.
Einfacher koennte man die Spatienverarbeitung zumindest
fuer MABXML Ebene 1 gestalten, wenn man alle Datenfelder
ermittelt, in denen Fuehrende und Mehrfachleerzeichen
vorkommen koennen, und diesen dann bei der Generierung von
MABXML das fuer diesen Zwecke vor langer Zeit eingefuehrte
XML-Attribut xml:space="preserve" spendiert.
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.
More information about the datenformate
mailing list