AW: [mab-list] MABXML

["Kett, Jürgen"]

Lieber Herr Berger,  liebe Liste,


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

Es spricht nichts dagegen, zu diesem Zweck auch für MABXML Ebene 0 ein
Schema zu veröffentlichen.  
 
> 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),

Da hat sich in Fehler im Dokument eingeschlichen. Das Satzendezeichen sollte
eigentlich entfallen, da es durch das datensatz-Tag überflüssig wird.

> falls der
>    Satz (MAB-Diskette) mit "### " beginnt, entferne auch dies.
>    Das ist dann der "Inhalt" des Datensatzes.
> 

Danke für den Hinweis. Ich werde den Vorschlag in die Übertragunsregeln
aufnehmen.

> 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 &amp; sowie &lt;
>    und &gt; 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...]. 
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.)       

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

Auch XML-Schema bietet übrigens bisher noch keine Möglichkeit die
Interpration von "white space" eindeutig zu spezifizieren. Regeln, wie die
oben beschriebene, müssen ausserhalb von DTDs und Schemas festgelegt werden.


>  
> 5. Umschliesse das Resultat mit den Tags "<datensatz>"...
>    "</datensatz>".   


> 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".
Ok
 
> 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).
Ok
 
> 3. Umschliesse den so aufbereiteten Inhalt eines
>   a) Unterfelds mit <uf>...</uf> (Und ueberfuehre den
>      Unterfeldcode als Attribut "code" des so entstehenden
>      XML-Elements).
Ok

>      Dabei ist Leerraum sowohl am Anfang als auch am Ende
>      artifiziell, darf also hinzugefuegt oder weggenommen werden
Wie bereits oben erwähnt würde ich bevorzugen, wenn innerhalb von Elementen,
die Inhaltsdaten enthalten können:
- auf "space"-Zeichen (#x20) zur optischen Formatierung verzichtet würde,
- und hierfür generell TAB, Line Feed (Enter) und Carriage Return verwendet
würden.  
Was halten Sie davon?

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

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

>   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) 
Ok
 
> 
> Mit diesen Regln kann Ihr Beispiel 15 fast gerettet
> werden:
Danke ;)
 
> 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.
Das ist nicht notwendig. In XML-Schema gibt es für Elemente mit character
data die Möglichkeit die Eigenschaft xml:space="preserve" unter der Hand zu
vergeben. Ich nutze diese Möglichkeit bei allen Elementen, bei denen
führende Leerzeichen als Inhalt vorkommen können (falls zurzeit nicht, dann
ist das ein Fehler im Schema und wird noch von mir behoben). Jemand der auf
dieses Schema zur Validation verweist, muss das Attribut also nicht mehr von
Hand setzen.

Wie immer vielen Dank für Ihre Kommentare und beste Grüße aus Frankfurt

Jürgen Kett 

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