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

["Kett, Jürgen"]

Lieber Herr Berger, 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.

Den Fehler, den Sie in meine Ausführungen gefunden haben (Feldendezeichen,
Satzendezeichen, Unterfeldkennzeichen sind keine legalen Characters in XML
1.0) möchte ich so schnell wie möglich beseitigen. Zusätzlich möchte ich
aber auch die Frage, ob für MABXML grundsätzlich eine Konvertierung nach
Unicode erforderlich ist, diskutieren. 

----------------------------------------------------------------------

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.

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

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?

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

Viele Grüße
Jürgen Kett



> > > - In XML 1.0 sind die Zeichen 28, 29, 30 und 31 nicht legal,
> > >   d.h. man muesste hierfuer Ersatzzeichen definieren, was
> > >   ich fuer verwirrend und kontraproduktiv halte.
> > >   Im kommenden XML 1.1 wird allerdings der volle Unicode
> > >   abgedeckt werden.
> > Vielen Dank für diese Information. Das war mir entgangen
> und ich muss
> > sagen: Ich bin überrascht darüber, dass selbst das Kodieren von
> > Zeichen über Character References 
> > (http://www.w3.org/TR/REC-xml#dt-charref) für die ersten 30 Zeichen 
> > ausgeschlossen ist.
> 
> Das liegt daran, dass Unicode in XML staerker eingebaut ist,
> als man zunaechst annimmt: Abschnitt 2.2 der 
> XML-Spezifikation definiert, was "Zeichen" sind. "Definition: 
> A character is an atomic unit of text as specified by ISO/IEC 
> 10646 [das ist das ISO-Pendant zu Uniode, Th.B.]. Legal 
> characters are tab, carriage return, line feed, and the legal 
> characters of Unicode and ISO/IEC 10646. [...] Char ::= #x9 | 
> #xA | #xD | [#x20 - #xD7FF] | [#xE000-#xFFFD]
>    | [x10000-#x10FFFF]
> /* any Unicode character, excluding the surrogate blocks, 
> FFFE, and FFFF */
> 
> The mechanism for encoding character code points into bit
> patterns may vary from entity to entity. All XML processors 
> must accept the UTF-8 and UTF-16 encoding of 10646; [...]"
> 
> Die XML-Spezifikation 1.0 stammt allerdings aus 1998, d.h.
> sie bezieht sich auf Unicode 2.0, ich finde allerdings keine 
> Indizien dafuer, dass diese C0-Controls damals noch nicht zu 
> Unicode gehoerten, die XML-Spezifikation scheint hier 
> ungluecklich formuliert.
> 
> Der Entwurf fuer XML 1.1 praezisiert dieses, er verbietet
> aber ausserdem und zusaetzlich auch die meisten der C1 
> controls (#x80 - #x9F). Allerdings erlaubt er fuer C0- und C1 
> controls die Ersetzung durch numeric character references, 
> also das, was Sie probiert hatten. (vgl. auch < 
> http://www.w3.org/International/questions/qa-controls.html >)
> 
> Jedenfalls ist Unicode / ISO 10646 ein XML zugrundeliegender
> Standard, eine Zeichen-referenz) &#x89 meint immer das 
> Unicode-Zeichen U+0089, egal welches Encoding Sie fuer das 
> konkrete XML-Dokument eingestellt haben. Aus Abschnitt 4.1 
> der XML-Spezifikation:
> >>>
> Definition: A character reference refers to a specific
> character in the 
> ISO/IEC 10646 character set, for example one not directly 
> accessible from available input devices.]
> 
> Character Reference
> [66]    CharRef    ::=    '&#' [0-9]+ ';'  
>    | '&#x' [0-9a-fA-F]+ ';' [WFC: Legal Character]
> 
> Well-formedness constraint: Legal Character
> 
> Characters referred to using character references must match the
> production for Char.
> 
> If the character reference begins with "&#x", the digits and
> letters up to the terminating ; provide a hexadecimal 
> representation of the character's code point in ISO/IEC 
> 10646. If it begins just with "&#", the digits up to the 
> terminating ; provide a decimal representation of the 
> character's code point. <<<
> 
> Ein direkt im Dokument befindliches Zeichen x89 hingegen wird
> entsprechend der Encoding-Declaration in der XML-Deklaration 
> interpretiert.
> 
>  
> > Ich sehe dennoch eine einfache Lösung für das Problem. Dazu aber
> > weiter unten. Durch Ihren Beitrag ist mir etwas ganz anderes 
> > aufgefallen: Ich habe in meinen Ausführungen bisher 
> keinerlei Aussage
> > über die verwendeten Character Sets gemacht. Zwar ist es allgemein
> > bekannt, dass XML auf Unicode basiert, aber für jemanden, der noch 
> > nicht XML gearbeitet hat zumindest eine Erwähnung wert.
> 
> So wie ich die XML-Spezifikation auffasse, gibt es fuer eine
> "XML-Anwendung" keine andere Wahl, als intern mit Unicode zu
> arbeiten:
> - Zeichen in XML-Dokumenten sind Unicode (s.o.), d.h. Dokumente
>   duerfen nur Unicode-Zeichen enthalten (was allerdings noch nichts 
>   ueber die konkrete Codierung aussagt). 
> - XML-Anwendungen muessen in der Lage sein, UTF-8 und UTF-16 codierte
>   Dokumente zu verarbeiten
> - XML-Anwendungen duerfen nur Dokumente in Kodierungen verarbeiten,
>   die sie kennen.
> 
> Das heisst fuer mich, legale XML-Dokumente koennen nur in
> Kodierungen vorkommen, die ein Mapping nach Unicode erlauben.
> 
> 
>  
> > Für Ebene 1 (und höher) ist der Einsatz von Unicode sicherlich ein
> > Muss. Was ist aber mit Ebene 0? Hier wäre eine Konversion 
> nach Unicode
> > ein unnötiges Unterfangen. Das Attribut "encoding"
> > (http://www.w3.org/TR/REC-xml#charencoding) wird bereits jetzt zum
> > Transport von Daten in anderen Zeichsätzen als Unicode verwendet 
> > (obwohl es, wie der Name deutlich macht, ursprünglich nur 
> um die Form
> > der Kodierung (z.B. UTF-8,
> > UTF-16) ging).  Es wäre also beispielsweise denkbar für
> MABXML Ebene 0 das
> 
> Aus 4.3 der XML-Spezifikation:
> >>>
> In an encoding declaration, the values "UTF-8", "UTF-16",
> "ISO-10646-UCS-2", and "ISO-10646-UCS-4" should be used for 
> the various encodings and transformations of Unicode / 
> ISO/IEC 10646, the values "ISO-8859-1", "ISO-8859-2", ... 
> "ISO-8859-n" (where n is the part number) should be used for 
> the parts of ISO 8859, and the values "ISO-2022-JP", 
> "Shift_JIS", and "EUC-JP" should be used for the various 
> encoded forms of JIS X-0208-1997. It is recommended that 
> character encodings registered (as charsets) with the 
> Internet Assigned Numbers Authority [IANA-CHARSETS], other 
> than those just listed, be referred to using their registered 
> names; other encodings should use names starting with an "x-" 
> prefix. XML processors should match character encoding names 
> in a case-insensitive way and should either interpret an 
> IANA-registered name as the encoding registered at IANA for 
> that name or treat it as unknown (processors are, of course, 
> not required to support all IANA-registered encodings).
> 
> In the absence of information provided by an external
> transport protocol (e.g. HTTP or MIME), it is an error for an 
> entity including an encoding declaration to be presented to 
> the XML processor in an encoding other than that named in the 
> declaration, or for an entity which begins with neither a 
> Byte Order Mark nor an encoding declaration to use an 
> encoding other than UTF-8. Note that since ASCII is a subset 
> of UTF-8, ordinary ASCII entities do not strictly need an 
> encoding declaration.
> 
> It is a fatal error for a TextDecl to occur other than at the
> beginning of an external entity.
> 
> It is a fatal error when an XML processor encounters an
> entity with an encoding that it is unable to process. It is a 
> fatal error if an XML entity is determined (via default, 
> encoding declaration, or higher-level
> protocol)
> to be in a certain encoding but contains octet sequences that 
> are not legal in that encoding. It is also a fatal error if 
> an XML entity contains no encoding declaration and its 
> content is not legal UTF-8 or UTF-16. <<<
> 
> 
> > Attribut encoding auf "ISO-5426-1983" zu setzen, oder, um
> korrekter zu
> > sein, auf Werte wie "x-MAB2" und "x-MAB2-Diskette".) Dann wäre auch
> > das oben genannte Problem gelöst, denn die von Ihnen genannte 
> > Einschränkung bezieht sich nur auf Unicode.
> 
> Das sehe ich nicht so:
> 
> Erstens kann man es nachpruefen, indem man ein XML-Dokument in
> der Codierung CP850 erzeugt, das das Unterfeldzeichen x31 als 
> solches oder als numeric entity reference &x#1f; oder &#31;
> enthaelt: Das gibt einen Error, [entweder weil die 
> XML-Software das Mapping von CP850 nicht beherrscht, oder, 
> z.B. wenn die iconv-Library eingebunden ist] weil das Mapping 
> von CP850 nach Unicode das Zeichen x1f auf U+001F abbildet, 
> also ein fuer 
> XML illegales Zeichen (auch in einer CDATA-Section).
> 
> Der Ausweg waere, hier nicht mehr CP850 als Encoding zu
> nutzen, sondern x-MAB-Diskette, wobei man darauf achtet, dass 
> das Mapping von x-MAB-Diskette nach Unicode die c0-Zeichen 
> auf in XML legale Zeichen abbildet. Das waere dann das von 
> mir bereits aufgebrachtem, schwerlich erwuenschte Um-Mappen der 
> Steuerzeichen plus die zusaetzliche Restriktion, dass es
> keine XML-Software gibt oder je geben wird, die diese XML- 
> Dokumente verarbeiten kann (das Mapping von x-MAB-Diskette 
> muesste dort ja eingebaut werden). Sie koennten nun 
> hoechstens dem XML-Dokument noch eine DTD mitgeben, die Entitaeten 
> deklariert:
> <?xml version="1.0" encoding="CP850"?>
> <!DOCTYPE elem [
> <!ENTITY y31 "<uf/>">
> ]>
> <elem>&y31;</elem>
> 
> Dies wuerde einfach nur die Notation &y31; als Ersatz fuer
> <uf/> einfuehren [Vielleicht waere das aber ein Ansatz, um 
> den Sinn der "Ebene 0" zu retten: Einfach nur alle 
> Steuerzeichen durch leere XML-Elemente ersetzen, und keine 
> Kapselungen einfuehren]
> 
> Bei ISO-5426 (vulgo MAB-Zeichensatz) haben wir noch mehr Probleme,
> weder gibt es ein offizielles Mapping zu Unicode, noch ist es 
> ein IANA-registrierter Zeichensatz. D.h. 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, und zwar nur fuer UTF-8, UTF-16, x-MAB2 und 
> x-MAB-Diskette, was auch ohne Mapping funktioniert, weil die 
> Anwendung weiss, dass das Mapping uninteressant ist. 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 (dann lieber uuencoden, das koennen 
> Sie mit jeder XML-Software dann verarbeiten)
> 
> Zweitens also wird eine Software, die MAB2(-Band) auf
> irgendeine der MABXML-Ebenen umsetzt, auch 
> Zeichenkonversionen durchfuehren muessen, sonst ist das 
> Resultat ziemlich unbrauchbar. Dabei muessen auch fast alle 
> Steuerzeichen beruecksichtigt werden (und ich hatte 
> dargelegt, dass es eigentlich alle sein sollten, um "Steuer"- 
> von "Text"-Zeichen zu trennen), der Aufwand fuer "Ebene 0" 
> waere also nicht geringer als fuer "Ebene 1".
> 
> Drittens bin ich immer noch der Meinung, dass jegliche XML-
> Darstellung von "MAB-Daten" erst dann sinnvoll ist, wenn sie 
> die (Meta-)Struktur der Daten soweit transformiert, dass man 
> den Unterschied zwischen MAB-Band und MAB-Diskette nicht mehr 
> kennen muss.
> 
> 
> Das "uuencoden" oben war nur halb im Scherz gemeint: Aus dem
> oben bereits angegebenen qa-controls.html:
> >>>
> If the data is not really textual, but binary, then it may be
> more practical to encode it, for example using base64 or as 
> hexadecimal values, to ensure only supported characters are 
> used in the markup language text. (And of course, decoding 
> the text when reading the
> files.) Note that XML Schema provides data types for these 
> encodings. <<< Das bedeutet aber, dass man die 
> mime64-escapten Einzelbytes, etwa x1f, 
> jeweils in ein eigenes XML-Element einbetten muss, das dann 
> den anderen (von text verschiedenen) Datentyp traegt, also 
> dann etwa fuer das Teilfeldzeichen:
> 
> ...text <mab:binchar xsi:type="hexBinary"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-datatypes">1F</mab
> :binchar>
> weiter im Text
> 
> (bin mir nicht ganz sicher, ob die Namespaces korrekt sind).
> 
> 
> 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.
> 

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