Unzulänglichkeiten des W3C-Validators?

[Tobias Müller]

Hallo,

Zwei Fragezeichen drängen sich mir immer wieder im Bezug auf den Validator vom W3C auf.

1. Irgendwo in der XHTML-Spezifikation steht meines Wissens geschrieben, dass man bei XHTML-Dokumenten die XML-Deklaration mit den darin enthaltenen Kodierungsinformationen weglassen darf, sofern man als Kodierung UTF-8 oder UTF-16 verwendet. Meine Schlussfolgerung daraus ist, dass wenn man per Meta Charset die Kodierung auf bspw. Latin-1 festlegt, die XML-Deklaration _nicht_ weglassen darf, sondern dort dann ebenfalls encoding="iso-8859-1" angeben muss.

Wenn ich mit dieser meiner Schlussfolgerung richtig liege, dann frage ich mich, warum der Validator nicht meckert, wenn man bei obigem Beispiel die XML-Deklaration weglässt.

2. XHTML 1.1 enthält nicht das Latin-1-Entities-Modul. IMHO dürfte man in Dokumenten, die den XHTML 1.1 Doctype verwenden, also keine benannten Zeichen wie ä etc verwenden. Tut man es trotzdem, meckert der Validator aber wieder nicht, sondern befindet das Dokument - wenn auch sonst alles stimmt -  für valide. Ja was denn nun?

So, jetzt bin ich mal gespannt, ob ich hier einfach nur Bockmist verzapft habe oder nicht... ;)

MfG Mülli

PS: Das selbe gilt übrigens auch für den SelfValidator oder wie das Ding heisst.

[MudGuard]

Hi,

1. Irgendwo in der XHTML-Spezifikation steht meines Wissens geschrieben, dass man bei XHTML-Dokumenten die XML-Deklaration mit den darin enthaltenen Kodierungsinformationen weglassen darf, sofern man als Kodierung UTF-8 oder UTF-16 verwendet. Meine Schlussfolgerung daraus ist, dass wenn man per Meta Charset die Kodierung auf bspw. Latin-1 festlegt, die XML-Deklaration _nicht_ weglassen darf, sondern dort dann ebenfalls encoding="iso-8859-1" angeben muss.

Im HTTP-Umfeld reicht auch ein entsprechender HTTP-Header.

2. XHTML 1.1 enthält nicht das Latin-1-Entities-Modul.

Doch, enthält es.
Denn in
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd
wird
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-framework-1.mod
eingebunden, welches
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-charent-1.mod
einbindet, welches wiederum
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-lat1.ent
einbindet.

cu,
Andreas

[Tobias Müller]

Hallo,

Im HTTP-Umfeld reicht auch ein entsprechender HTTP-Header.

Gut zu wissen.

Doch, enthält es.
Denn in
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd
wird
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-framework-1.mod
eingebunden, welches
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-charent-1.mod
einbindet, welches wiederum
http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-lat1.ent
einbindet.

Da hätte ich wohl ein bisschen vernetzter denken müssen... ;) Jetzt kann ich dem Vali ja wieder vertrauen. :)

Danke!

MfG Mülli

[molily]

Hallo,

Zwei Fragezeichen drängen sich mir immer wieder im Bezug auf den Validator vom W3C auf.

1. Irgendwo in der XHTML-Spezifikation steht meines Wissens geschrieben, dass man bei XHTML-Dokumenten die XML-Deklaration mit den darin enthaltenen Kodierungsinformationen weglassen darf, sofern man als Kodierung UTF-8 oder UTF-16 verwendet.

Ja. Empfehlenswert ist die Angabe selbst dann, wenn UTF-8 verwendet wird.

Meine Schlussfolgerung daraus ist, dass wenn man per Meta Charset die Kodierung auf bspw. Latin-1 festlegt, die XML-Deklaration _nicht_ weglassen darf, sondern dort dann ebenfalls encoding="iso-8859-1" angeben muss.

Ja. Und nein. Zuerst einmal: Kodierungsangaben in meta-Elementen haben für »echte« (als XHTML verarbeitete) XHTML-Dokumente keinen formalen Wert. Es ist also, die Praxis des Validator einmal außen vor, formal irrelevant, welche Kodierung dort angegeben ist. Ein XHTML-Dokument ohne encoding in der XML-Deklaration (und ohne ohne Angabe der Kodierung in einem übergeordneten Protokoll wie HTTP, siehe Andreas) muss UTF-8- oder UTF-16-kodiert sein, wie du weißt. Wenn es anders kodiert ist, entspricht es nicht den Standards und es bei der Verarbeitung werden (höchstwahrscheinlich) Probleme auftreten, weil eine falsche Kodierung angenommen wird.

Will man also in einem echten XHTML-Dokument die Kodierung desselben angeben, so muss dies auf die beschriebene Weise in der XML-Deklaration passieren. XHTML ist von dieser Warte aus gesehen eine beliebige XML-Sprache, auf die sich die Regeln übertragen, die für alle XML-Sprachen gelten. Es ist nirgendwo definiert, dass XML-Prozessoren für XHTML eine Ausnahme machen und in einem bestimmten Element mit einem bestimmten Attribut an einer bestimmten Stelle im Attributwert nach der Kodierung suchen.

Wenn ich mit dieser meiner Schlussfolgerung richtig liege, dann frage ich mich, warum der Validator nicht meckert, wenn man bei obigem Beispiel die XML-Deklaration weglässt.

Du hast vermutlich XHTML 1.0 als text/html ausgeliefert. Die XML-Regeln gelten dann formal nicht mehr, das Markup sollte wie gewöhnliches HTML verarbeitet werden. Die Regeln, wie die Kodierung eines HTML-Dokuments bestimmt wird, unterscheiden sich von denen, wie die Kodierung eines XHTML-Dokuments bestimmt wird: http://www.w3.org/TR/html401/charset.html#h-5.2.2. In HTML/SGML spielen XML-Deklarationen keine Rolle, dafür aber die meta-Kodierung.

Betrachten wir das folgende in ISO-8859-1 kodierte Dokument:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title></title>
</head>
<body><p>ö</p></body>
</html>

Man speichere es mit der Endung .html, wodurch es durch den Webserver als text/html deklariert werden sollte. Es sollte somit als HTML-Dokument verarbeitet werden. Wir wissen natürlich, dass es ein sogenanntes HTML-kompatibles XHTML-Dokument gemäß Anhang C der XHTML 1.0-Spezifikation sein soll.

Wenn dieses Dokument nun mithilfe des W3C-Validator geprüft wird, wird es als valide angesehen. Der Validator entnimmt gemäß den obigen HTML-Regeln die Kodierung aus dem meta-Element: ISO-8859-1. Alles scheint soweit in Ordnung.

Wenn dasselbe Dokument nun als .xhtml abgespeichert wird, sollte es der Webserver mit dem Inhaltstyp application/xhtml+xml ausliefern. Dies ist der für XHTML-Dokumente an sich vorgesehene und passene MIME-Typ. Beim Validieren wird nun versucht, die Kodierung gemäß den XML-Regeln festzustellen. Gemäß diesen befindet sich jedoch keine Kodierung im Dokument selbst - das meta-Element hat wie gesagt keine Bedeutung.

Deshalb wird (muss) ein XML-Prozessor annehmen, dass die Kodierung des Dokuments UTF-8 ist (oder meines Wissens UTF-16, falls ein Byte-Order-Mark vorhanden ist). Wenn also keine Kodierung per HTTP-Header angegeben wurde, wird der Validator logischerweise einen Fehler zurückgeben: »Sorry, I am unable to validate this document because on line 7 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.« - In diesem Fall muss eine XML-Deklaration mit encoding="iso-8859-1" angegeben werden, damit der Validator die Kodierung erkennt.

Der Sinn der sogenannten HTML-Kompatibilität von XHTML 1.0 ist nun, dass ein und dasselbe XHTML-Dokument einerseits als text/html an HTML-Browser gesendet werden kann und andererseits als application/xhtml+xml (oder etwa application/xml) an XHTML/XML-Browser. Ein sog. HTML-kompatibles XHTML-Dokument ist somit in diesem Fall ein XHTML/XML- und gleichzeitig ein HTML-Dokument.

Es gibt also zwei Verarbeitungsarten, die sich insbesondere hinsichtlich der Kodierungsproblematik unterscheiden. Die HTML-Prozessoren wenden die besagten HTML-Regeln an, die XML-Prozessoren die XML-Regeln. Deshalb raten die Kompatibilitätsrichtlinien, dass die Kodierung sowohl in einer XML-Deklaration, als auch in einem meta-Element angegeben wird (wenn sie überhaupt im Dokument selbst angegeben wird). Dadurch soll das Dokument auf beide Arten verarbeitbar sein.

In die Praxis ist diese Problematik noch nicht vorgedrungen, weil zwar mittlerweile viele XHTML schreiben, es aber nahezu immer als text/html deklariert wird und in keinem Kontext durch XML-Prozessoren verarbeitet wird. Sicher könnte man sich daran halten, immer darauf entsprechende XML-Deklarationen einzufügen, nur hat dies die bekannten Nebenwirkungen (Stichwort Doctype Switch).

Ob das Verhalten des Validators in diesem Punkt nun ein Fehler ist, darüber lässt sich streiten. Auf jeden Fall ist es widersprüchlich. Der Validator verarbeitet das besagte Dokument, wenn es vom Webserver als text/html ausgeliefert wird, als XML - bis auf die Kodierungsfrage. Das ist freilich absurd, denn in der Praxis werden die Browser mit ihrem HTML-Parser arbeiten, der über eine solche Fehler und solche Fehlertoleranz verfügt, dass er auch mit XHTML mehr oder weniger klar kommt. Was soll der Validator nun machen, das Dokument nur nach HTML-Regeln verarbeiten? Das geht nicht, weil die XHTML-Syntax formal nicht kompatibel zur HTML-Syntax ist. Er könnte auch keinen fehlertoleranten Parser imitieren, denn es geht ja gerade darum, die Konformität zu formalen Standards zu prüfen. Wenn er den praktischen Komplex des »HTML-kompatiblen XHTMLs« vergessen würde und nur gemäß XML-Regeln die Kodierung bestimmen würde, würden die Autoren nicht darauf aufmerksam gemacht, dass dem Dokument als HTML-Dokument, als das es ausgeliefert wird, eine Kodierungsangabe fehlt.

Was der Validator hier macht, lässt sich also nicht stringent aus den Standards ableiten, alleine schon, weil HTML-kompatibles XHTML selbst ein in sich widersprüchliches Konzept ist. Das Validatorverhalten ist ein mit Blick auf die Praxis ausgehandelter Kompromiss, der sicher streitbar ist. Christoph Schneegans' XHTML 1.0 Schema-Validator beispielsweise ignoriert meta-Elemente auch im Falle von text/html, weil es sich nichtsdestoweniger faktisch um XML-Dokumente handelt (insbesondere dann, wenn sie gegen ein XML Schema validiert werden sollen).

Eine weitere Unstimmigkeit ist etwa, dass der Validator bei einem XHTML-Dokument als text/html mit Kodierungsangabe in einer XML-Deklaration nicht darauf hinweist, dass konsequenterweise auch ein meta-Element vorhanden sein sollte. Das als Ganzes kritikwürdige Konzept ist also nicht einmal in sich stimmig.

Mathias