AW: [mab-list] MABXML

Mon Nov 17 13:14:11 CET 2003

Lieber Herr Kett, liebe Liste,

> > 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...].
> Darüber hatte ich auch nachgedacht, hielt es am Ende aber für mindestens
> ebenso verwirrend alle Sonderzeichen in Ebene 1 anders als in Ebene 0 zu
> benennen, obwohl doch beispielsweise das Teilfeldtrennzeichen und die
> Nichtsortierzeichen die selbe Bedeutung haben. Ich sehe auch ein "Problem"
> mit dem Kodieren der Nichtsortierzeichen durch ein leeres Element "<nsz/>":
> In MAB gibt es ja ein Nicht-Sortier-Beginn-Zeichen und ein
> Nicht-Sortier-Ende-Zeichen. Beide Zeichen auf eine einzige Kodierung
> abzubilden, hätte zur Folge, dass bei einer Rückkonversion nach MAB2 keine
> einfache Ersetzungsvorschrift mehr möglich ist. (Natürlich ist das einfach
> zu lösen, aber mein Ziel war eigentlich eine Konversion durch simples
> Ersetzen von Zeichen bzw. Zeichenmustern.)

Umgekehrt gibt es in MAB-Diskette keine zwei verschiedenen Zeichen.
[Und "am Arbeitsplatz" ist MAB-Diskette durchaus ernstzunehmen].
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.

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

> > 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.
> 
> In der XML-Terminologie wird hier unterschieden zwischen "space" und "white
> space".
> "space" entspricht dem normalen Leerzeichen (#x20), "white space" wird
> dagegen als Oberbegriff für "space", Zeilenumbruch (d.h. "line feed" (#xA)
> oder "carriage return" (#xD)) oder TAB (#x9) verwendet.
> 
> Es wird in XML also zwischen Leerzeichen, Zeilenumbruch und TAB
> unterschieden, sie wurden mit "white space" lediglich terminologisch zu
> einer Gruppe zusammengefasst.

Mit Grund: Attributnormalisierung, visuelle Formatierung in Tags ... 
2.10 der XML-Spezifikation gibt an, dass white space im "element
content"
treu (modulo Zeilenendenormalisierung 2.11) vom Parser an die Anwendung
durchzureichen ist. Erwaehnt wird, dass die Anwendung einen "default
white space processing mode" hat. 

> Für MABXML (egal welcher Stufe) sollte als Regel für Validatoren generell
> gelten: "space"-Zeichen sind (in Elementen, die "character data" enthalten
> dürfen) immer Teil des Inhalts. Alle anderen "white-space"-Zeichen haben
> keine inhaltliche Bedeutung und müssen ignoriert werden (und können somit
> immer zur optischen Strukturierung der Daten eingesetzt werden).
>
> Vom Einsatz von "space"-Zeichen zum  Formatieren von Inhalten würde ich in
> Elementen mit mixed-content, um die Logik des Parsers möglichst einfach zu
> halten, generell abraten (hierzu sollte ausschliesslich TAB verwendet
> werden).

vgl. auch Ihren spaeteren Vorschlag, sich zur visuellen Formatierung
auf TAB und CR zu beschraenken: 
- Werkzeuge wie XSLT-Prozessoren formatieren typischerweise mit Spatien
- Was "leer" aussieht, muss auch "leer" sein, d.h. wenn "Spatium Tab"
  und "Tab Spatium" und "Tab Tab" subtil unterschiedliche Bedeutungen
  bekommen, ist groesstes Unheil vorprogrammiert.
- Der Lesbarkeit wegen sollte man in Daten Zeilenumbrueche einfuegen
  duerfen, diese sollten dann die Bedeutung "Spatium" haben.

Ziel sollte sein, Einrueckungen wie in Ihren Beispielen zu erlauben,
egal wie sie hergestellt werden. "Mixed content" liegt in MAB-Daten
vor, weil ja Text und NSZ-Nodes sowie Teilfeldzeichen gemischt
vorkommen koennen.

Dazu genuegt eigentlich die Beobachtung (sowohl fuer Ebene 0 als auch
1),
dass Leerraum am *Ende* von Feldern und Unterfeldern kein Bestandteil
der Inhaltsdaten ist (sein kann). Insofern darf man jedes Feld und
jedes (bis auf das erste) Unterfeld mit beliebiger Einrueckung auf
einer neuen Zeile darstellen.

Fuer Ebene 0 gilt zusaetzlich (hier sind ja Feldnummern und 
Unterfeldcodes Bestandteil der Elementinhalte), dass es auch
am Anfang von Feldern und Unterfeldern (genauer: Nach Feld-ende-
und Unterfeld-Beginn-Zeichen) keinen Leerraum geben kann, d.h.
evtl. vorhandener kann beim Umwandeln von XML nach MAB still-
schweigend entfernt werden.

Fuer Ebene 1 koennte man sich mit folgenden zwei Behauptungen ueber
MAB auseinandersetzen:
1. Unterfelder beginnen nie mit Spatium
2. Ein Feld mit Unterfeldern hat keinen Inhalt ausserhalb eines
   Unterfeldes
(1. und 2. gelten m.E. in MARC21)
[Nicht dazu gehoert: Die AACR2 verlangen bisweilen die Erfassung
 von ".  " und ".   " (also Punkt und zweimal bzw. dreimal Spatium).
 Ich habe nicht ermittelt, ob dies von MARC-Software "treu" behandelt
 wird, oder ob hier des oefteren Spatien "normalisiert" werden.
 ]

Allgemeiner Erwartung entspricht jedoch, dass zwischen zwei unmittelbar
aufeinanderfolgenden oeffnenden Tags (etwa <feld><uf>... aber dann auch 
<feld><ns[z]>... ) stets Leerraum zur Formatierung eingefuegt werden
kann. 
Dies bedeutet im Umkehrschluss, dass Leerraum in "<feld>   <uf>" bzw. 
eben auch "<feld>    <nsz>" beliebig entfernt werden darf. Dies muesste 
man fuer die MAB-Felder, die mit Spatien als Codes beginnen koennen, 
ueberpruefen (ob der "eigentliche Inhalt" evtl. mit
Nichtsortiersequenzen 
beginnt) und sich ansonsten fuer MABXML Ebene 2 das Ziel setzen, eine 
aeusserst weitgehende Leerraumnormalisierung zuzulassen.

Im Zusammenhang mit DocBook wurde der Begriff "pernicious mixed content"
gepraegt (fuer SGML): Dort gibt es Situationen, in denen Elemente mixed 
content haben, der alternativ "inline" als auch "block level" sein kann
(was wie bei "<nsz>" bzw. "<uf>" starke Auswirkungen auf die
Interpretation
von Leerraum hat). [In SGML muss der Parser entscheiden, ob Leerraum
bedeutungstragend ist, insofern gibt es einen entscheidenden Unterschied 
zwischen "<feld><uf>" und "<feld> <uf>". XML verlagert die Entscheidung
auf die Anwendung, problematisch bleibt es: in "Feld" Leerraum
wegnehmen,
ist das naechste Token nicht <uf>, Leerraum wiederherstellen...]

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.