optionale Codeteile

... [ Seminar XML (DTD) ] ... [ Einleitung ] ... [ Fallbeispiel ] ...

optionale Codeteile: bedingte Abschnitte und Kommentare

Bedingte Abschnitte

 Stellen Sie sich vor, Sie schreiben einen etwas umfangreicheren Text, vielleicht ein Buch. Meist werden Sie es nicht schaffen, einen so langen Text beim ersten Versuch so zu schreiben, wie Sie es gerne möchten. Dem ersten Entwurf folgt der zweite und so weiter, bis endlich nach einigen Schritten die endgültige Form vor Ihnen liegt. In der Entwurfsphase ist es üblich, Kommentare und Bemerkungen zu schreiben, die im gedruckten Buch nicht enthalten sein dürfen. Dazu können Sie natürlich XML-Kommentare einsetzen. Der Nachteil ist dabei, daß der Kommentartext in einem Probeausdruck nicht sichtbar ist. Schöner wäre es doch, einen Elementtyp kommentar zur Verfügung zu haben, dessen Inhalt auch im Probeausdruck erscheint. Nichts leichter als das:

<!ELEMENT kommentar (#PCDATA)>


So weit so gut. Nun müssen Sie nur noch aufpassen, daß Sie Ihre Kommentare löschen, sobald die Arbeit beendet ist. Auch hier liegt eine Idee zur Verbesserung nahe: Das XML-System soll prüfen, ob alle Kommentare entfernt sind. Diese Überprüfung überläßt man am besten dem Parser, indem man die Definition des Elementtyps kommentar aus der DTD entfernt. Umgangssprachlich ist also folgendes gewünscht: Kommentare sind in der Entwurfsphase erlaubt, in der endgültigen Fassung jedoch verboten. XML bietet dafür ein Konstrukt an, genannt bedingter Abschnitt. Realisiert wird er durch einen markierten Abschnitt der externen (!) DTD, der entweder berücksichtigt (include) oder ignoriert wird (ignore). Für die Entwurfsphase sieht das so aus:

<![INCLUDE[
>   <!ELEMENT kommentar (#PCDATA)>
]]>


Nach getaner Arbeit weisen Sie den Parser an, die Kommentar-Deklaration zu ignorieren:

<![IGNORE[
  <!ELEMENT kommentar (#PCDATA)>
]]>


Sollte Ihre Instanz nun noch ein Element vom Typ kommentar enthalten, so wird der Parser dies als nicht deklarierten Typ, also als Fehler, anzeigen.

Wenn Sie solche bedingten Abschnitte an mehr als einer Stelle einsetzen, kann es recht lästig sein, zwischen INCLUDE und IGNORE zu wechseln. Leichter geht es mit geschickt benutzten Parameter-Entities, wie das folgende Beispiel demonstriert.

<!ENTITY % entwurf 'INCLUDE'>
<!ENTITY % fertig 'IGNORE'>
<![%entwurf;[
  <!ELEMENT kommentar (#PCDATA)>
]]>
<![%fertig;[
  <!ELEMENT kommentar EMPTY>
]]>


Die Funktion ist die gleiche wie zuvor. Hier genügt es jedoch, in der Definition der Entities die Worte INCLUDE und IGNORE zu vertauschen. Die Änderung wird damit automatisch für alle bedingten Abschnitte wirksam.

Kommantare

 Wenn Sie bereits Kommentare in HTML kennen, wird Ihnen die XML-Syntax sehr bekannt vorkommen, denn Kommentare sind in HTML und XML identisch.
Diese Syntax stimmt auf den ersten Blick mit der von SGML überein. Tatsächlich sind XML-Kommentare ein Sonderfall von SGML-Kommentaren. Das heißt, jeder XML-Kommentar ist ein SGML-Kommentar, aber nicht umgekehrt.

Kommentare dürfen überall dort im Dokument stehen, wo Text zulässig ist, also insbesondere nicht innerhalb der Tags anderer Elemente. Der Text innerhalb eines Kommentars gehört nicht zum Dokument. Es ist einem XML-Prozessor freigestellt, ob er Kommentartexte für ein Anwendungsprogramm zugänglich macht oder nicht. 

<!-- Henning, kannst Du folgenden Abschnitt
     noch einmal durchlesen. Hab' ich etwas
     vergessen? Ist er verständlich?
-->
Keinesfalls sollten Sie Kommentare mit einer bestimmten Semantik belegen. Schreiben Sie Kommentare so, daß Ihr Dokument auch nach dem Entfernen der Kommentare uneingeschränkt zu gebrauchen ist. Falls Sie Ihre Dokumente mit einem selbstgeschriebenen Programm weiterverarbeiten, ist es verführerisch, Anweisungen für die Verarbeitung in Kommentare zu schreiben. Abgesehen davon, daß es ein schlechter Stil ist, verlieren Instanzen dadurch an Portabilität. Nur noch Ihr Programm kann Ihr Dokument adäquat verarbeiten. Es gibt eine Möglichkeit, solche Anweisungen in eine Instanz einzufügen. Der Name dafür ist »Processing Instruction«.
In den frühen Tagen des Web wurde HTML aus dem Blickwinkel eines SGML-Puristen oftmals nicht besonders »gut« behandelt. Meist waren (und sind) dafür neue Browser-Features, wie etwa blinkender Text, verantwortlich. Aber auch auf der Server-Seite gibt es Beispiele, und eines davon ist der Kommentar. 

<!--#include file="fusszeile.html" -->
<!-- SSI-Anweisungen des Apache stehen in Kommentaren :-( -->
Das Problem ist hierbei, daß ein SGML/XML-Parser den Inhalt eines Kommentars gar nicht an ein Anwendungsprogramm weiterreichen muß. Er könnte also verlorengehen. Das darf dem Server natürlich nicht passieren. -- Wir wollen hier nicht diskutieren, wie man alle Optionen der Server Side Includes besser realisiert hätte -- das gezeigte Beispiel wäre mit einem externen Entity auch leicht umzusetzen --, zumal hier viele Faktoren (zum Beispiel auch die Geschwindigkeit) eine Rolle spielen. Aus syntaktischer Sicht hätte man aber die Alternative der Processing Instructions wählen sollen.

... [ Seminar XML (DTD) ] ... [ Einleitung ] ... [ Fallbeispiel ] ...