AW: AW: [mab-list] [Fwd: Ebenen. Was: Re: MABXML]

Thu Sep 18 11:52:34 CEST 2003

Lieber Herr Kett, liebe Liste,

> Noch ein paar Kommentare zu Ebene 0, auch wenn dies mit Abstand die
> uninteressanteste Variante ist. Dennoch sehe ich noch keine Veranlassung
> bereits jetzt Ebene 0 vollständig zu kippen. Ich denke dieser Bereich
> (Minimallösung) ist weiterhin wichtig für die Diskussion.

Das sehe ich auch so: Wir muessen ausloten, wie "minimal" 
ein MABXML theoretisch sein kann und danach, welche 
Minimalitaet sinnvoll und erwuenscht ist. Klar ist, dass
die von uns derzeit diskutierten moeglichen Varianten fuer
die Festlegung von Ebene 1 sich nicht besonders unterscheiden
und die Ebene 1 am aehnlichsten zu MARCXML ist, wenn man
die Designprinzipien betrachtet.

Eine konkreter gestellte Frage waere daher vielleicht,
inwieweit man die Ebene 1 weiter "herunterkochen" kann,
durchaus auch auf ein Level, das fuer eine XML-Weiterverarbeitung
nicht mehr wirklich sinnvoll ist.

> ----------------------------------------------------------------------
> 
> Zu der Frage, ob MABXML Ebene 0 Unicode als Zeichensatz fordern sollte:
> 
> Mein Vorschlag war es, neue Encodings einzuführen (x-MAB2, x-MAB2-Diskette).
> Ihr berechtigter Einwand hierzu ist: "[...]wir werden auf absehbare Zeit
> keine XML-Applikationen haben, die diese Daten unterstuetzen wuerden, egal
> ob wir sie als "ISO-5426-1983" oder als "x-MAB2" encoden. ["keine" mit
> Ausnahme derjenigen, die wir selber schreiben wuerden: So eingeschraenkte
> Applikationen, dass sie nur aus MABXML wieder MAB herstellen koennten [...]
> Ein MABXML, mit der man nur eine einzige Sache machen kann (naemlich nach
> MAB zurueck verwandeln), und auch das nur mit Spezialsoftware, halte
> ich fuer ziemlich uninteressant".
> 
> Das ist richtig. Aber: Möglichst leichte Rückkonvertierbarkeit nach MAB2 ist
> genau der einzige Zweck den MABXML-Ebene 0 erfüllen soll. D.h. es muss
> überhaupt keine Applikationen geben, die die MABXML-Dokumente zu einem
> anderen Zweck weiterverarbeiten kann.

* Irgendeinen Bezug zu MABXML-Ebene 1 sollten wir aber auch bei
  Ebene 0 im Auge behalten: Ich hielte es fuer fatal, wenn wir
  XML-Daten aus Ebene 0 erst nach MAB konvertieren muessten, um daraus
  dann XML-Daten der Ebene 1 konstruieren zu koennen. 

> Ein solches Format könnte z.B. im Rahmen von OAI und SRW/U eingesetzt
> werden. Diese Protokolle verlangen Datensätze in XML-Struktur. Ein Transport

Mit SRW/U kenne ich mich nicht aus. OAI 2.0 spezifiziert jedoch:

>>>
The XML data for all responses to OAI-PMH requests must validate against
the
XML Schema shown at the end of this section . As can be seen from that
schema,
responses to OAI-PMH requests have the following common markup:

The first tag output is an XML declaration where the version is always
1.0
and the encoding is always UTF-8, eg: <?xml version="1.0"
encoding="UTF-8" ?> 

...
<<<

> von herkömmlichen MAB2-Datensätzen ist also nicht möglich (bzw. nicht
> legitim), auch wenn der Abholende sich vielleicht nur für MAB2-Datensätze
> interessiert. D.h. der Abholdende hat mit den gelieferten MABXML-Datensätzen
> nichts anderes vor, als sie zurück nach MAB2 zu konvertieren. Da käme es ihm
> natürlich entgegen, wenn er keine Zeichsattkonvertierung ausgehend von
> Unicode durchführen müsste (die meisten Anwender nutzen für MAB2 ja noch
> immer kein Unicode, sondern die klassischen MAB-Zeichensätze, obwohl es
> inzwischen erlaubt wäre). (Das Argument "Spezialsoftware" lasse ich nicht
> gelten. Eine Konvertierung zwischen MAB und MABXML Ebene 0 (und umgekehrt)
> ist jeweils mit einem 1- bis 10-zeiligen Script möglich.)

Es ging mir um "XML-Applikationen" (in der Terminologie der
XML-Spezifikation).

Wenn A und B mittels OAI oder anderem MAB-Daten austauschen
moechten, koennen sie dafuer auch illegale Abkuerzungen
verabreden (z.B. "x-MAB2" meinen, mit dem UTF-8-Algorithmus
in Mehrbyte-Kombinationen uebersetzen und unter Deklaration
von "UTF-8" transportieren. Keine Frage, dass das funktioniert,
das ist aber so illegal (es ist nicht UTF-8, es ist nicht
XML, es sieht nur so aus, um Software zu ueberlisten), dass
man das keinesfalls "standardisieren" darf.

> Was Ihr Einwand aber deutlich macht: Will man MAB2-Daten in XML-Strukturen
> transportieren UND mit fremdentwickelten Tools weiterverarbeiten, müssen die
> Zeichen auf Unicode abgebildet werden. MABXML Ebene 0 (unter Verwendung
> eigener Encodings) wäre auf seine Rolle als stupides Transportvehikel
> beschränkt. Die Frage ist nur: Wenn eine Weiterverarbeitung der
> MABXML-Dokumente  (über eine einfache Rückkonvertierung nach MAB2 hinaus)
> das Ziel ist, wäre es dann nicht besser gleich MABXML Ebene 1 (oder höher)
> zu verwenden?

Unbedingt. Die andere Frage ist, ob eine "saubere" Ebene 0
nicht so viele unappetitliche Uebertragungsregeln benoetigt,
dass man auch fuer Anwendungen, die "nur" MAB2 zurueckgewinnen
wollen, lieber Ebene 1 nutzt.

Aus Ebene 1 mittels XSLT MAB2 (in UTF-8) zu erzeugen, waere nicht 
weiter schwer, wenn es nicht wieder die Probleme mit den Zeichen
kleiner als ASCII 20 gaebe, die man auch im Stylesheet nicht
notieren kann. Man koennte auch den Ansatz verfolgen, aus
Ebene 1 mittels XSLT Ebene 0 zu erzeugen, um das Resultat mit
einem maximal dummen Konvertierungsfilter (der auch Zeichenumwandlungen
erledigt) in echtes MAB2 oder MAB-Diskette umzuwandeln.

> [Ob überhaupt Bedarf nach Ebene 0  besteht, steht auf einem anderen Blatt.
> Mir ist es nur wichtig, eine Minmallösung (hinsichtlich des
> Konvertierungsaufwands)zum Transport von MAB2-Daten formuliert zu haben.]
> ----------------------------------------------------------------------------
> 
> Zu dem Problem mit den in XML nicht erlaubten Unicode-Zeichen (Feldende,
> Satzende, Unterfeld):
> Neben Ihren Einwänden, gibt da noch ein ganz anderes Problem mit meinem
> Vorschlag: Er löst das Problem mit den nicht-erlaubten Unicode-Zeichen
> NICHT. Ich hatte vergessen, dass MAB2 ja auch die Verwendung von "Unicode"
> als Encoding erlaubt (siehe Feld 030, Pos. 3). Die "Mogelpackung", auf eine
> Konvertierung nach Unicode zu verzichten, um so den XML-Restriktionen zu
> entgehen, funktioniert so also nicht. Es ist also für dises Problem egal, ob
> man generell Unicode fordert oder nicht.
> 
> Als Lösung finde ich Ihren Vorschlag naheliegend: "Einfach nur alle
> Steuerzeichen durch leere XML-Elemente [zu] ersetzen, und keine Kapselungen
> ein[zu]fuehren". Man hätte so weiterhin ein leicht von/nach MAB2
> konvertierbares Format (die Steuerzeichen müssten einfach rückübersetzt
> werden). Diesen Vorschlag würde ich gerne auf alle Fälle übernehmen.

Das waere doch was: Ebene 0 kennt noch "Datei" und "Datensatz",
ein "Datensatz" ist aber nur noch ein Strom von Zeichen und
Platzhaltern fuer die in XML nicht abbildbaren Zeichen (z.B.
die zwingenden Escapes &gt, &lt, &amp, &quot, ueber die wir auch
nicht gesprochen haben, oder aber &uf (oder <uf/>) als Codierungen
fuer XML-illegale Steuerzeichen, sowie natuerlich die ueblichen
numerischen Character references &#xhhhh und &#nnnn.

Dies kann durch sehr einfach gestrickte Tools nach MAB-Band oder
MAB-Diskette uebersetzt werden (ob das XML MAB-Band oder MAB-
Diskette enthaelt, kann man ja durch Test des ersten Bytes
herausfinden: Es steht nicht "### " vor dem Header oder eben doch).
Umgekehrt kann man mit einem einfachen Tool aus beiden MAB-Varianten
diese XML-Ebene erzeugen. Ich hatte ja den Einwand formuliert,
dass auch Ebene 0 den Unterschied zwischen MAB-Diskette und
MAB-Band nivellieren sollte, andererseits koennte ich mir
vorstellen, dass der "Wiedererkennungswert" hoeher ist, 
wenn man es nicht tut [ich moechte aber auch anmerken, dass
ich mir nicht vorstellen kann, Ebene 0 je einsetzen zu wollen].
Wegen der vielen Feldende- und Satzende-Zeichen in MAB2-Band,
(und weil MAB2-Band in der Praxis nie spezifikationskonform
ist, weil hinter dem Satzende von allen ein illegales
Zeilenende eingefuegt wird), koennte man auch ueberlegen,
in Bezug auf Ebene 0 ein Disketten-Format zu uebertragen,
d.h. Feldende ist Zeilenumbruch. Das Satzende braucht man 
nicht, das Unterfeldzeichen muss aus XML-Gruenden umgesetzt
werden, fuer die drei Nichtsortierzeichen und das Teilfeld-
zeichen wuerde ich vorschlagen, sie auch in Ebene 0 durch
Entitaten zu codieren: Es ist leider nirgends spezifiziert, wie
sich Position 3 von MAB-Feld 030 auf diese Zeichen auswirkt 
(etwa bei den ISO-8859-codierten "Disketten"-Daten von der 
DNB-CD) und ich moechte dem Feld nicht unbedingt trauen:
Daher sollten m.E. auch auf Ebene 0 alle strukturierenen 
MAB-Zeichen deutlich und unabhaengig vom konkreten encoding
gekennzeichnet sein.

Diese einfachen Tools erlauben dann auch Zeichenkonversionen zwischen
CP850 und UTF-8 sowie ISO5426 und UTF-8 (denn vorzugsweise sollte 
natuerlich aus MAB2-Daten in ISO5426 nicht MABXML mit x-MAB2-encoding 
hergestellt werden, aber wer Wert drauf legt...) und auch
von ISO-8859-1 bzw. CP1252 nach UTF-8.

Transformation zwischen so einer Ebene 0 und Ebene 1 ist mit
Stylesheets moeglich (mit der Einschraenkung natuerlich, dass
kein mir bekannter Stylesheet-Processor x-MAB oder x-ISO-6426
beherrscht).

Fuer den "Normalfall" sollte es natuerlich auch Tools geben,
die direkt zwischen MAB und Ebene 1 konvertieren.

Fuer die noch zu entwickelnde Ebene 2 hingegen koennte ich
mir vorstellen, diese nur mittels Stylesheets von und zu
Ebene 1 zu konvertieren, das werde ich demnaechst separat
darlegen.

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.