Inklusionen und Exklusionen, auch SGML extensions genannt, sind ebenso einfache wie effektive Mittel, ein Inhaltsmodell zu erweitern oder einzuengen.

Durch eine Inklusion wird das inkludierte Element an allen Stellen und in allen Kind-, Enkel- etc. Elementen des Elements erlaubt, in das es inkludiert wurde. Eine Exklusion bewirkt das Gegenteil: selbst wenn ein Element durch Deklaration oder Inklusion erlaubt worden ist, wird es durch Exklusion wieder verboten. Am besten lässt sich das durch ein Beispiel erklären.

Nehmen wir an, Sie wollen in dem Element name an allen Stellen das Element diverses erlauben. Hier hilft Ihnen der AND-Konnektor nicht weiter. Zwar kann auch in AND-Reihungen ein Element an beliebiger Stelle beliebig oft vorkommen, aber das nur jeweils an einer Stelle, nicht an mehreren zugleich.

Eine elegante Lösung für dieses Problem ist die Inklusion von diverses:

<!ELEMENT name (hauptname & nebenname+ & abstammung? & akad.grad*) +(diverses)>

diverses kann nun überall in name und in allen Kind-Elementen von name sowie deren Kindern, Enkeln etc. vorkommen. Das aber ist zugleich ein Problem: da Sie zwar diverses in name, also zwischen hauptname, nebenname usw. haben wollen, nicht aber in hauptname, nebenname etc., benötigen Sie Exklusionen von diverses in den Deklarationen für hauptname, nebenname etc.:

<!ELEMENT hauptname (#PCDATA) -(diverses)>

Inklusionen und Exklusionen ergänzen sich also hervorragend.

Mehrere Elemente können ex- oder inkludiert werden, indem in die Klammern nach dem »+« bzw. »-« die gewünschten Elemente mit »|« getrennt geschrieben werden:

+(ein.element|noch.eins)

Anwendungsbeispiele sind die Verwendung von Elementen anstelle von Processing Instructions oder die Optimierung von XML Mixed Content:

Wenn aus XML-Daten gesetzt wird, müssen oft Angaben in den Daten untergebracht werden, die nicht aus der Struktur generiert werden können. Das trifft vor allem auf Informationen zu, die den Seiten- und Zeilenfall optimieren. Dazu werden in den XML-Datenstrom programmspezifische Verarbeitungsanweisungen (processing instructions, PI; siehe oben) eingebracht. XML-fähige Satzsysteme wie 3B2, PowerPublisher, TypoScript oder TUSTEP beherrschen diese Technologie.

Bei komplexen, zeitkritischen Workflows kann es notwendig werden, die XML-Satzdaten mit umbruchrelevanten PIs an den Bearbeiter zurückzugeben, z. B. damit dieser Register-Informationen einbringt. Soll der Umbruch erhalten bleiben, müssen die PIs vor Veränderungen geschützt werden. Abhängig vom genutzten XML-Editor kann es einen Schreibschutz und eine Layoutmöglichkeit für PIs geben – oder auch nicht.

Da die professionellen Editoren meist einen konfigurierbaren Schreibschutz für Elemente haben, bietet es sich an, PIs provisorisch in Elemente umzuwandeln. Ein leeres Element, dass die PI als Attribut enthält, ist hier die beste Lösung: es kann z. B. als unaufällige aber sichtbare Grafik in den Textfluss eingebunden werden.

Die DTD muss dazu nur an einer Stelle geändert werden: durch Inklusion des zusätzlichen Elements auf oberster Ebene kann es wie PIs überall im Dokument verwendet werden. (Dieser Weg wurde z. B. bei pagina für ein Projekt verwendet, bei dem XMetaL 3 als Editor vorgegeben war: XMetaL erlaubt SGML-Konstruktionen, hat aber keinen Schreibschutz für PIs).

Ein weiteres Beispiel:

Für den Inhalt von Absätzen ist XML-Mixed Content recht gut geeignet. Da hier so gut wie immer auch Schachtelungen von Elementen vorkommen können (z. B. stichwort innerhalb von link und umgekehrt) müssen Sie so arbeiten:

<!ELEMENT absatz (#PCDATA | stichwort | link)*>
<!ELEMENT stichwort (#PCDATA | link)*>
<!ELEMENT link (#PCDATA | stichwort)*>

Damit sind aber unerwünschte da unsinnige Schachtelungen von Elementen in sich selbst möglich:

<absatz><link><stichwort><link><stichwort>Text</stichwort>
</link></stichwort></link></absatz>

In der Regel wird man aus pragmatischen Gründen zur Konstruktion mit Parameter-Entities greifen:

<!ENTITY % inzeilige "(#PCDATA | stichwort | link)*">
<!ELEMENT absatz %inzeilige;>
<!ELEMENT stichwort %inzeilige;>
<!ELEMENT link %inzeilige;>

Dann kann ein Element auch direkt in sich geschachtelt vorkommen:

<absatz><link><link>Test</link>text</link></absatz>

In der Praxis erzeugen viele WYSIWIG-Editoren zur XML-Textbearbeitung diese Schachtelungen, etwa wenn der Nutzer die entsprechenden Buttons im Editor mehrfach anklickt. Schachtelungen identischer Elemente in alltäglichen Konstruktionen wie Absätzen lassen sich also in XML prinzipiell nicht vermeiden. Mit SGML-Exklusionen können Sie diese Schachtelungen jedoch ganz einfach verhindern:

<!ENTITY % inzeilige "(#PCDATA | stichwort | link)*">
<!ELEMENT absatz %inzeilige; >
<!ELEMENT stichwort %inzeilige; -(stichwort)>
<!ELEMENT link %inzeilige; -(link)>

Ein aus sich selbst exkludiertes Element kann nicht mehr in sich selbst vorkommen, egal auf welcher Ebene etwas anderes festgelegt wurde.

Ein besonderer Vorteil von Inklusionen und Exklusionen ist, dass sie einfach an bestehende XML-Element-Deklarationen angehängt und auch ebenso schnell wieder entfernt werden können. Die Modifikation von XML-DTDs durch Inklusionen und Exklusionen ist mithin so einfach wie effektiv.

Und so deklarieren Sie Inklusionen und Exklusionen um, wenn Sie wieder in einer reinen XML-DTD arbeiten müssen:

Inklusionen: sind in XML nur schwer nachzubilden, insbesondere wenn sie für einen großen Bereich realisiert werden sollen. Eine einzige Inklusion in SGML kann Dutzenden punktuellen Änderungen in der entsprechenden XML-DTD entsprechen. Zu Auswahllisten kann das zu inkludierende Element hinzugefügt werden; ansonsten ist die optionale Ergänzung jedes Elements um das zu inkludierende Element im betreffenden Bereich nötig: aus element_xy wird an allen Stellen in der DTD: (element_xy, inkludiertes_element*).

Umfassendere Inklusionen sind daher nur als temporäre Lösungen sinnvoll, d. h. die inkludierten Elemente werden nach der betroffenen Arbeitsphase wieder entfernt. Dann ist auch keine XML-DTD notwendig, die diese Inklusionen nachbildet.

Benötigen Sie zwingend umfassende Inklusionen – evtl. sogar mit Exklusionen kombiniert –, sollte statt XML »offiziell« SGML verwendet werden.

Exklusionen: sind in XML nicht nachzuahmen und müssen bei Rückgang zu reinem XML aus der DTD entfernt werden. Kompatibilitäts-Probleme treten dabei nicht auf, lediglich die Strukturkontrolle wird unschärfer. Auch an den Dokumenten muss nichts geändert werden.

Fazit