3.2. Von Elementen, Tags und Attributen

Alle in SGML geschriebenen DTDs haben bestimmte gemeinsame Eigenschaften. Das ist nicht verwunderlich, da sich die hinter SGML stehende Idee unweigerlich bemerkbar macht. Zwei der markantesten Merkmale dieser Idee sind die Begriffe Inhalt und Element.

Von einem Dokument, unabhängig, ob es sich um eine einzelne Webseite oder ein langes Buch handelt, wird angenommen, dass es einen wie auch immer gearteten Inhalt hat. Dieser lässt sich selbst wiederum in Teilelemente aufspalten, die ebenso zerlegbar sind. Durch die Aufnahme von Auszeichnungselementen in einen Text, werden diese einzelnen Elemente eindeutig benannt und voneinander abgegrenzt.

Nimmt man zum Beispiel ein typisches Buch, so kann man es auf der obersten Ebene als ein Ganzes, als ein Element betrachten. Dieses Buch-Element enthält nun Kapitel, die wiederum selbst als Elemente bezeichnet werden können. Jedes einzelne Kapitel enthält weitere Elemente. So gibt es beispielsweise Absätze, Zitate und Fußnoten. Jeder Absatz kann wiederum selbst Elemente enthalten, die helfen, den Absatzinhalt als direkte Rede oder als Namen eines der Protagonisten einer Geschichte zu identifizieren.

Wenn man möchte, kann man sich das als Unterteilung[3] des Inhalts vorstellen. Auf der obersten Ebene gibt es ein Element: das Buch selbst. Schaut man ein wenig tiefer, findet man weitere Teilelemente: die einzelnen Kapitel. Diese sind wiederum unterteilt in Absätze, Fußnoten, Namen und so weiter und so weiter.

Anzumerken ist an dieser Stelle, dass das eben gesagte ohne weiteres auf jeden Inhaltstyp angewandt werden kann, auch ohne dass von SGML die Rede ist. Man könnte beispielsweise einfach verschiedene Stifte nehmen und einen Ausdruck dieser Fibel vor sich hinlegen und dann mit verschiedenen Farben die einzelnen Abschnitte des Buchinhalts markieren.

Leider gibt es keinen elektronischen Stift, um das zu tun. Deshalb muss ein anderer Weg gewählt werden, um zu bestimmen, zu welchem Element die einzelnen Inhalte gehören. In SGML-basierten Auszeichnungssprachen wie HTML und DocBook werden dafür so genannte Tags eingesetzt.

Mit einem solchen Tag wird eindeutig festgelegt, wo ein bestimmtes Element beginnt und wo es endet. Allerdings gehört der Tag selber nicht zum Element. Er legt lediglich die Grenzen des Elements fest. Da jede DTD mit dem Ziel entwickelt wurde, einen speziellen Inhaltstyp auszuzeichnen, wird jede DTD verschiedene Elemente kennen, die daher natürlich auch unterschiedlich benannt sein werden.

Der Starttag für ein imaginäres Element mit dem Namen elementname ist <elementname>. Sein Gegenstück, der schließende Endtag, ist </elementname>.

Beispiel 3.1. Verwendung eines Elements (Start- und Endtag)

HTML kennt das Element p, um festzulegen, dass ein bestimmter abgegrenzter Bereich einen Absatz darstellt. Dieses Element hat sowohl einen Start- als auch einen Endtag.

<p>Das ist ein Absatz. Er beginnt mit Starttag
  für das Element 'p' und endet mit dem Endtag für
  das Element 'p'.</p>

<p>Das ist ein etwas kürzerer Absatz.</p>

Elemente müssen nicht notwendigerweise einen Endtag haben. Ebenso ist es nicht notwendig, dass Elemente einen Inhalt haben. Beispielsweise kann in HTML-Dokumenten mittels eines speziellen Elements festgelegt werden, dass eine horizontale Linie an einer bestimmten Stelle erscheinen soll. Da dieses Element offensichtlich keinen Inhalt hat, wird auch kein Endtag benötigt.

Beispiel 3.2. Verwendung eines Elements (nur Starttag)

In HTML kann man mit dem Element hr festlegen, dass an einer bestimmten Stelle eine horizontale Linie angezeigt werden soll. Da dieses Element keinen Inhalt umschließt, hat es nur einen Starttag.

<p>Das ist ein Abschnitt.</p>

<hr>

<p>Das ist ein weiterer Absatz. Eine horizontale Linie
  trennt ihn vom vorherigen Absatz.</p>

Elemente können andere Elemente enthalten. Im anfangs erwähnten Buch enthielt das Buch-Element alle Kapitel-Elemente, die wiederum alle Absatz-Elemente enthielten und so fort.

Beispiel 3.3. Verschachtelte Elemente: em
<p>Das ist ein einfacher <em>Abschnitt</em>, in dem
  einige <em>Worte</em> <em>hervorgehoben</em> wurden.

Welche Elemente andere Elemente enthalten können und welche das sind, wird innerhalb der DTD eines Dokuments festgelegt.

Wichtig:

Viele Leute sind oft verwirrt, wenn es um die richtige Benutzung der Begriffe Tag und Element geht. Im Ergebnis werden sie oft so genutzt, als wären sie austauschbar. Allerdings sind sie das nicht.

Ein Element ist ein konzeptioneller Teil eines Dokuments und hat einen festgelegten Anfang und ein festgelegtes Ende. Ein Tag hingegen markiert die Stelle, an der ein Element beginnt und endet.

Wenn in diesem Dokument vom Tag p gesprochen wird, ist damit der Text gemeint, der aus den drei Zeichen <, p und > besteht. Wird hingegen von dem Element p gesprochen, ist damit das gesamte Element gemeint.

Diese Unterscheidung ist sicherlich subtil. Trotzdem sollte man sie sich vergegenwärtigen.

Elemente können selber Attribute haben, die aus einem Namen und einem Wert bestehen. Die Attribute haben die Aufgabe, dem Element zusätzliche Informationen hinzuzufügen. Denkbar sind hier Festlegungen über die Darstellung, Bezeichner, über die das Element eindeutig identifiziert werden kann, oder beliebige andere Informationen.

Elementattribute werden in den Starttag eingefügt und haben die Form Attributename="Wert".

Bei einigen HTML-Versionen kennt das Element p das Attribut align, mit dessen Hilfe die Textausrichtung eines Absatzes bestimmt werden kann.

align akzeptiert einen von vier vorgegebenen Werten: left, center, right und justify. Ist align nicht angegeben, wird vom Standardwert left ausgegangen.

Beispiel 3.4. Elemente mit Attributen nutzen
<p align="left">Die Verwendung des align-Attributs
  für diesen Absatz ist überflüssig, da left
  der Standardwert ist.</p>

<p align="center">Dieser Absatz wird hoffentlich mittig dargestellt.</p>

Einige Attribute akzeptieren nur bestimmte Werte, wie beispielsweise left oder justify. Andere akzeptieren jeden beliebigen Wert. Enthält Attributwert doppelte Anführungszeichen ("), wird der Wert in einfachen Anführungszeichen eingeschlossen.

Beispiel 3.5. Attribute mit einfachen Anführungszeichen
<p align='right'>Ich stehe rechts!</p>

Manchmal können die Anführungszeichen um den Attributwert weggelassen werden. Allerdings sind die Regeln, die festlegen wann dies zulässig ist, sehr spitzfindig. Am besten schließen Sie Attributwerte immer in Anführungszeichen ein.

Die Informationen über Attribute, Elemente und Tags sind in SGML-Katalogen abgelegt und werden von den verschiedenen Werkzeugen des Dokumentationsprojektes genutzt, um die geschriebenen Dokumente zu validieren. Die Programme die durch textproc/docproj installiert werden, bringen ihre eigenen Katalogvarianten mit, zudem pflegt das FDP seine eigenen Kataloge. Beide Katalogarten müssen von allen Programmen gefunden werden können.

3.2.1. Was dafür getan werden muss;…

Damit die Beispiele dieser Fibel ausgeführt werden können, ist es notwendig, dass einige Programme auf dem Rechner installiert sind und das eine Umgebungsvariable korrekt gesetzt wird.

  1. Der erste Schritt ist die Installation des Ports textproc/docproj über das FreeBSD-Portsystem. textproc/docproj ist ein Metaport, der alle vom FDP benötigten Programme und Daten aus dem Netz laden und installieren sollte.

  2. Anschließend muss in den Shellkonfigurationsdateien die Variable SGML_CATALOG_FILES [4] gesetzt werden.

    Beispiel 3.6. .profile, für sh(1) und bash(1) Benutzer
    SGML_ROOT=/usr/local/share/xml
    SGML_CATALOG_FILES=${SGML_ROOT}/jade/catalog
    SGML_CATALOG_FILES=${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=/usr/doc/share/xml/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=/usr/doc/en_US.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES
    export SGML_CATALOG_FILES

    Beispiel 3.7. .cshrc, für csh(1)- und tcsh(1)-Benutzer
    setenv SGML_ROOT /usr/local/share/xml
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/jade/catalog
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES /usr/doc/share/xml/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES /usr/doc/en_US.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES /usr/doc/de_DE.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES

    Damit die Änderungen wirksam werden, meldet man sich ab und anschließend wieder an – oder man führt die obigen Anweisungen direkt in der Shell aus und setzt so die benötigten Umgebungsvariablen.

  1. Nun sollte man eine Datei beispiel.xml anlegen, die den folgenden Text enthält:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    
    <html>
      <head>
        <title>Eine Beispieldatei in HTML</title>
      </head>
    
      <body>
        <p>Das ist ein Absatz mit etwas Text.</p>
    
        <p>Das ist ein Absatz mit anderem Text.</p>
    
        <p align="right">Dieser Absatz wird rechtsbündig
          ausgerichtet.</p>
      </body>
    </html>
  2. Nachdem die Datei abgespeichert wurde, kann sie mit Hilfe eines SGML-Parsers validiert werden.

    Bestandteil von textproc/docproj ist onsgmls - ein validierender Parser. onsgmls liest ein Dokument entsprechend einer SGML-DTD ein und gibt anschließend ein Element-Structure-Information-Set (ESIS) aus. Allerdings ist das an dieser Stelle nicht weiter wichtig.

    Wird onsgmls mit der Option -s aufgerufen, werden nur Fehlermeldungen ausgegeben. Dadurch kann leicht geprüft werden, ob ein Dokument gültig ist oder nicht.

    So prüft man mit onsgmls, ob die neuangelegte Beispieldatei gültig ist:

    % onsgmls -s beispiel.xml

    Sofern das Beispiel korrekt abgetippt wurde, wird sich onsgmls ohne jegliche Ausgabe beenden. Das bedeutet, dass das Dokument erfolgreich validiert werden konnte und somit gültig ist.

  3. Jetzt sollten die Tags title und /title aus dem Dokument gelöscht und das Dokument erneut validiert werden:

    % onsgmls -s beispiel.xml
    onsgmls:beispiel.xml:5:4:E: character data is not allowed here
    onsgmls:beispiel.xml:6:8:E: end tag for "HEAD" which is not finished

    Die Fehlermeldungen, die von onsgmls ausgegeben werden, sind in durch Doppelpunkte getrennte Spalten unterteilt.

    SpalteBedeutung
    1Der Name des Programms, das den Fehler meldet. Hier wird immer onsgmls stehen.
    2Der Name der fehlerhaften Datei.
    3Die Zeilennummer des Fehlers.
    4Die Spaltenummer des Fehlers.
    5Ein einbuchstabiger Code, der über die Art des Fehlers informiert. I steht für eine informelle Meldung, W für eine Warnung und E für Fehler[a] und X für einen Querverweis. Bei den oben stehenden Ausgaben handelt es sich also um Fehlermeldungen.
    6Die Meldung.

    [a] Nicht immer besteht eine Meldung aus fünf Spalten. Die Ausgabe von onsgmls -sv ist beispielsweise onsgmls:I: SP version "1.3" (natürlich abhängig von der Version). Wie man sehen kann, handelt es sich hier um eine informelle Meldung.

    Durch das Weglassen des Tags title sind zwei unterschiedliche Fehler entstanden.

    Der erste Fehler besagt, dass Inhalt (in diesem Falle Zeichen anstatt eines Starttags) an einer Stelle gefunden wurde, an der der Parser etwas anderes erwartet hat. Genauer gesagt wurde der Starttag eines Elements erwartet, das innerhalb von head auftreten kann.

    Der zweite Fehler wurde dadurch verursacht, dass das Element head ein Element title enthalten muss und onsgmls nicht berücksichtigt, dass dieser Fehler auf dem vorhergehenden beruht. Es wird lediglich festgestellt, dass der Endtag von head auftritt, obwohl nicht alle notwendigen Elemente vorhanden sind.

  4. Zum Schluss sollte der Tag title wieder in die Beispieldatei eingefügt werden.



[3] Im angelsächsischen Sprachraum wird hier von chunking gesprochen.

[4] Sofern man nicht an der deutschen Dokumentation arbeitet, müssen die Verzeichnisangaben entsprechend angepasst werden.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.