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

[Thomas Berger]

Lieber Herr Kett, liebe Liste,

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