Element oder Attribut?

Diese Seite behandelt die Frage, wann eine Information in XML  durch ein Element  und wann durch ein Attribut  dargestellt werden soll. Es geht hier nicht um die Verwendung vorgegebener Dokumenttypen (DTDs oder Schemas), sondern um die Frage, wann bei der Festlegung neuer Dokumenttypen Elemente und wann Attribute zur Darstellung von Informationen verwendet werden sollten. XML -Grundkenntnisse werden vorausgesetzt.

Zunächst wird eine „natürliche Semantik“ formuliert, die Richtlinien zur Semantik von Elementen und Attributen durch möglichst wenig willkürliche oder zusätzliche Annahmen erlangen will. Wenn den Leser beim Lesen der natürlichen Semantik das Gefühl befällt, das Dargestellte sei selbstverständlich, dann wäre diese Absicht erfüllt.

Diese „natürliche Semantik“ erlaubt es oft, die Frage, ob ein Element oder ein Attribut verwendet werden sollte, zu beantworten. Anschließend wird beschrieben, warum es in XML  leider nicht immer möglich ist, die natürliche Semantik direkt anzuwenden. Unter Umständen muß in XML  von ihr abgewichen werden, weil technische Einschränkungen von XML  es verlangen.

Die Natürliche Semantik von XML

Die natürliche Semantik von XML  versucht, Aussagen über die Bedeutung von XML -Strukturen zu machen, die so nicht mehr in der maßgeblichen XML -Spezifikation enthalten sind, aber durch die Benennung von Begriffen in der XML -Spezifikation nahegelegt werden. Dadurch soll es erleichtert werden, XML  in möglichst „natürlicher“ Weise anwenden zu können. Sicher kann die im folgenden angegebene natürliche Semantik nicht zwingend als „richtige“ Semantik bewiesen werden, sie ist vielmehr ein Vorschlag zur Interpretation von XML, der aber so durch verschiedene Indizien in der XML -Spezifikation und bekannten XML -Anwendungen nahegelegt wird.

Die hier beschriebene Semantik von XML  soll zudem auch einfach  sein; damit ist gemeint, daß es zu jeder im folgenden behandelten syntaktischen Situation von XML  genau eine Interpretation  geben soll. Es soll nicht nötig sein, von Fall zu Fall noch erraten zu müssen, was gemeint sein könnte. Es wäre gewiß hilfreich, wenn XML -Anwendungen auch stets solch eine einfache Semantik hätten. Weiter unten wird aber auch noch beschrieben, daß bestehenden Beschränkungen von XML  das leider oft verhindern.

Obwohl die natürliche Semantik also nicht immer direkt angewendet werden kann, sollte sie auch in der Praxis der XML -Anwendung hilfreich sein, um ein erstrebenswertes Ziel zu bieten, das aber nicht immer so erreicht werden kann.

Was bedeutet ein Element ?

Die Syntax eines Elements ist durch die XML -Spezifikation gegeben. Hier soll die zusätzlich semantische Annahme eingeführt werden, daß ein Element ein bestimmtes Etwas innerhalb eines XML -Dokuments repräsentiert  oder angibt.

Als Begründung für diese Annahme sei angeführt, daß XML  in der Regel gerade so verwendet wird. So repräsentiert das Leerelement "<br/>" in XHTML  beispielsweise einen Zeilenumbruch. Man kann auch sagen, es gebe einen Zeilenumbruch an.

Ein Element repräsentiert etwas, es ist eine Angabe.

Was bedeutet ein Elementtyp ?

Zur Bedeutung  von Elementtypen  macht die XML -Spezifikation ebenfalls keine Aussagen. Allerdings liefert sowohl die übliche Verwendung in XML -Anwendungen als auch die Bedeutung des Worts „Typ“ hier eine naheliegende Erklärung zur Semantik:

Der Typ eines Elementes gibt eine charakterisierende Menge an, der das durch das Element Repräsentierte angehört.

Auch hier liefert XHTML  wieder Beispiele, so gehört der durch "<br>" repräsentierte Zeilenumbruch der Menge "br" der Zeilenumbrüche an, ein XHTML-Absatz "<p></p>" ist ein Element der Menge der Absätze. Man sagt auch kurz „Das Element "<br>" ist ein  Zeilenumbruch.“, „Das Element "<p>a</p>" ist ein  Absatz.“, u.s.w.. So kann man einen Elementtyp auch als ein einstelliges  Prädikat auffassen, mit dem die Aussage formuliert wird, daß das Element der durch den Typ angegebenen Menge angehört.

Wenn das durch ein Element "<br/>" repräsentierte Etwas mit "E " bezeichnet wird, so bedeutet der Typ dieses Elements die Aussage "br(E )", in Worten: Das einstellige Prädikat "br" trifft auf das durch das Element Repräsentierte "E" zu. Beispielsweise wäre dieses Prädikat in XHTML  die Eigenschaft, ein Zeilenumbruch zu sein.

Natürlich kann etwas in mehreren Mengen enthalten sein oder mehrere Prädikate besitzen. Oft wird es in einem bestimmten Zusammenhang aber primär durch eine bestimmte Menge oder ein bestimmtes Prädikat charakterisiert, das dann als Typ fungiert.

Durch den Typ kann ein Element das von ihm Repräsentierte also auch noch beschreiben, indem es eine Aussage darüber macht. Wegen dieser Situation, wird das von einem Element repräsentierte Etwas hier auch als der Deskriptand  des Elements bezeichnet. Also als das, was das Element beschreibt oder angibt.

Was bedeutet ein Attribut ?

Während der Elementtyp also ein einstelliges Prädikat ist, so ist der Name eines Attributes der Name einer binären Relation, die den Deskriptanden mit etwas anderem verbindet. Daß solch eine Aussage gemacht werden soll, wird auch schon durch die Verwendung des Wortes „Attribut“ angedeutet. Wenn keine Mißverständnisse möglich sind, so wird eine binäre Relation hier auch einfach nur als „Relation“ bezeichnet.

So kennt XHTML  beispielsweise ein Element "<img src="../icons/logo.gif" alt="logo"/>" mit dem Typ "img", dem Attribut "src="../icons/logo.gif"", und dem Attribut "alt="logo"". Hier werden über den Deskriptanden drei Aussagen gemacht: Der Deskriptand ist ein "img" (ein Bild), der Pfad "../icons/logo.gif" gibt die Quelle des Deskriptanden an, und der Text "logo" gibt einen Alternativtext des Deskriptanden an. Wird der Deskriptand mit dem Zeichen "D" bezeichnet, so ergibt sich in Prädikatsschreibweise:

img( D ).

src( D, "../icons/logo.gif" ).

alt( D, "logo" ).

Ein Attribut beschreibt eine (durch den Attributnamen bezeichnete) Relation zwischen dem Deskriptanden und etwas anderem (das durch den Attributwert bezeichnet wird).

Wenn die Zugehörigkeit zu einer Menge mit einem Einfachpfeil und eine Aussage mit einer binären Relation mit einem Doppelpfeil, über dem der Name der Relation steht, dargestellt wird, so ergibt sich das folgende Bild.

<img src="../icons/logo.gif" alt="logo"/>

D ---------> img

     src
D =========> "../icons/logo.gif"

     alt
D =========> "logo"

Elementtypen sind keine binären Relationen

Daß ein Elementtyp—anders als ein Attribut—nicht dafür gedacht ist, eine Beziehung zu einem direkt umgebendem Element zu beschreiben, wird auch dadurch nahegelegt, daß es in jedem XML -Dokument ein Wurzelelement ohne ein umgebendes Element gibt (während es kein „Wurzelattribut“ gibt). Der Elementtyp des Wurzelelements kann also schon einmal keine solche Relation zu einem umgebenden Element darstellen. Da die Aussage des Wurzelelements nicht durch ein umgebendes Element relativiert werden kann (etwa nach dem Muster "<element truth="false"><color>sound</color></element>", wo das äußere Element das innere als falsch bezeichnet), ist die Aussage des Wurzelelements stets absolut, nämlich ein einstelliges Prädikat des Deskriptanden des Wurzelattributs. Verlangt man nun Einfachheit  der Semantik, dann sollte diese Interpretation auch in allen anderen Fällen möglich sein und nicht von Fall zu Fall verschieden, der Elementtyp sollte dann also immer ein einstelliges Prädikat des Deskriptanden sein.

Was bedeutet Elementinhalt ?

Der „Inhalt“ eines Elements ähnelt einem namenlosen Attribut. Man kann ihn auch als Wert eines „Attributs“  "*contents" ansehen, dessen Name sich von den möglichen Namen eines XML-Attributes unterscheidet.

Die Bedeutung des Elementinhalts  hängt im allgemeinen von dem Elementtyp ab und muß für einen Dokumenttyp wie die Bedeutung der einzelnen Attribute spezifiziert werden.

Häufig stellt der Elementinhalt den Deskriptanden  dar, den auch das Element als ganzes repräsentiert.

Im Rest dieses Abschnittes wird die Situation beschrieben, in der der Elementinhalt den Deskriptanden darstellt.

Das Element "<acronym>WAC</acronym>" repräsentiert das Akronym "WAC", indem der Typ das Prädikat in der Aussage "acronym("WAC")" wird. Dies bedeutet „"WAC" ist ein Akronym“. Falls es ohne diesen Typ noch andere Interpretationen von „WAC“ geben sollte, so wird dadurch auch gleichzeitig klargestellt, daß das Element dasjenige „WAC“ darstellen soll, welches ein Akronym ist.

<acronym>WAC</acronym>

"WAC" =========> acronym

Das Element "<abbr meaning="incorporation" lang="en">Inc.</abbr>" enthält drei Aussagen, nämlich:

abbr( "Inc." ).

meaning( "Inc.", "Incorporation" ).

lang( "Inc.", "en" ).

In Worten:

„Inc.“ ist hier eine Abkürzung.

„Inc.“ bedeutet hier dasselbe wie „Incorporation“.

„Inc.“ ist hier ein Text der englischen Sprache.

<abbr meaning="incorporation" lang="en">Inc.</abbr>

"Inc." ---------> abbr

        meaning
"Inc." =========> "incorporation"

         lang
"Inc." =========> "en"

Was bedeutet Elementverschachtelung ?

Die Frage nach der Bedeutung von Elementverschachtelung  ist eigentlich ein Spezialfall der zuvor behandelten Situation des Elementinhalts, denn ein Element, das in einem anderen enthalten ist, ist ja nichts anderes als ein Inhalt  des enthaltenden Elementes. Daraus ergibt sich also die folgende Interpretation:

Die Bedeutung von Elementverschachtelung  hängt im allgemeinen von der Bedeutung des Inhaltes des äußeren Elements ab, die für einen Dokumenttyp jeweils spezifiziert werden muß.

Wenn der Elementinhalt den Deskriptanden  darstellt, dann ist das innere Element der Deskriptand des äußeren Elements.

Im Rest dieses Abschnittes wird die Situation beschrieben, in der das innere Element der Deskriptand des äußeren Elements ist.

Die so gegebene Möglichkeit Aussagen über ein Element selber zu machen wird auch als Meta-Information  bezeichnet, damit ist nur gemeint: eine Information über  etwas—im engeren Sinne meist: eine Information über eine andere Information.

Da dies in XHTML  leider oft nicht so einfach und einheitlich angewendet wird, wird hier eine hypothetische XML -Anwendung angenommen, in der das Element "<element author="Peter"><sentence lang="en">This is a test.</sentence></element>" vorkommen kann.

Das innere Element kann als der englische Satz “This is a test. ” verstanden werden (zu dem hier gesagt wird, daß es ein englischer Text ist). Das äußere Element sagt nun, daß Peter  der Autor dieses inneren Elements ist. Der Elementtyp "element" liefert hier keine weitere Information, da es ja bereits bekannt ist, daß das innere Element ein Element ist, er steht hier nur deshalb, weil ein Element einen Typ haben muß, während hier die entscheidende Information des äußeren Elements aber in dem Attribut enthalten ist.

Im Element "<sentence lang="en" author="Peter">This is a test.</sentence>" würde das Attribut "author="Peter"" Peter als Autor des Textes " This is a test." festlegen, aber nicht als Autor des gesamten Elements.

Da ein Element, nach dem am Anfang des vorherigen Abschnittes Gesagten, für seinen Inhalt steht, steht das äußere Element also für das innere Element. Das ist so zu verstehen, daß es möglich sein soll, bei einer Darstellung des äußeren Elements, nur das innere Element darzustellen, also die „Meta-Information“ auch wegzulassen oder zu ignorieren (abgesehen von einer möglichen Klarstellung des Typs). Wenn ein Satz vom Typ "sentence" erwartet wird, dann soll also sowohl das Element "<element author="Peter"><sentence lang="en">This is a test.</sentence></text>" als auch das Element "<sentence lang="en">This is a test.</sentence>" akzeptiert werden. Beide repräsentieren nämlich einen Satz des Typs "sentence", das erste Element enthält nur noch zusätzliche Informationen über diesen Satz.

Das kann man damit vergleichen, daß etwa das erste Zeichen des durch das Element "<span>Hallo</span>" dargestellten Textes in XHTML  das Zeichen "H" ist. Das Element steht also für den enthaltenen Text.

An dieser Stelle entfernt sich die hier beschriebene natürliche Semantik allerdings schon deutlich von der XML -Praxis, wo diese einfache und einheitliche Regelung zur Notation von „Meta-Informationen“ so leider nur selten verwendet wird, wie weiter unten noch beschrieben werden soll.

Zusammenfassung

Die bisher entwickelte natürliche und einfache Semantik von XML  kann nun wie folgt zusammengefaßt werden.

Ein Element repräsentiert einen Deskriptanden.

Der Typ eines Elementes gibt eine Menge an, welcher der Deskriptand angehört.

Ein Attribut beschreibt eine (durch den Attributnamen bezeichnete) Relation zwischen dem Deskriptanden und etwas anderem (das durch den Attributwert bezeichnet wird).

Wenn ein Element einen Inhalt hat, so ist dieser wie der Wert eines speziellen „Inhaltsattributs“ zu verstehen und ist oft der Deskriptand, den auch das Element als ganzes repräsentiert.

Wann Elemente und wann Attribute verwenden?

Die natürliche Semantik von XML  liefert also eine Regel dafür, wann etwas durch einen Elementtypnamen  und wann durch einen Attributnamen  benannt werden soll:

Ein einstelliges Prädikat eines Deskriptanden wird durch einen Elementtyp dargestellt. Eine zweistellige Relation wird durch ein Attribut dargestellt, als dessen Name der Relationsname auftritt. Die Argumente der Relation sind der Deskriptand und der Attributwert.

Leider kann diese Regel in XML  aber nicht immer durchgängig verwendet werden. Unten wird beschrieben, warum bei Verwendung von XML  manchmal von ihr abgewichen werden muß. So kommen nun die XML -Dokumente zu ihrer komplizierten Semantik, die dann Anwender wegen ihrer Unregelmäßigkeit oft etwas ratlos zurückläßt, wenn es um die Frage geht, wann Elemente und wann Attribute verwendet werden sollen.

Einschränkungen der Ausdrucksmöglichkeiten in XML

Oben wurde beschrieben, daß ein Element als Beschreibung eines Deskriptanden  verstanden werden kann. Dabei gibt der Typ eines Elements ein einstelliges Prädikat und die Attribute geben zweistellige Relationen des Elements an. Der Inhalt kann als ein weiteres Attribut angesehen werden, das oft mit dem Deskriptanden des Elements übereinstimmt.

Die Anwendung dieses einfachen Prinzips ist in XML  aber leider nicht immer möglich, weil es in XML 

• pro Element höchstens einen Typ geben darf,
• Attributwerte in XML  nicht strukturiert sein dürfen, und
• es pro Attributnamen höchstens einen Attributwert geben darf.

Im folgenden sollen einige dieser Einschränkungen samt ihren Konsequenzen beschrieben werden.

Einfachheit des Typs

Da ein Element nur einen Typ haben kann, müssen mehrfache Typen durch eine Verschachtelung von Elementen  nachgebildet werden. Soll ein Text in XHTML 1.0  beispielsweise fett  und kursiv  sein, so sind Elemente mit entsprechenden Typen zu verschachteln.

Fettschrift und Kursivschrift in XHTML 1.0

<b><i>example</i></b>

Dies hat mindestens zwei störende Nebenwirkungen:

Die Verschachtelung von Elementen kann nicht mehr eindeutig nur der Darstellung von Meta-Aussagen gewidmet werden, so daß ihre Bedeutung in jedem Einzelfall interpretiert werden muß.

Der Autor muß eine bestimmte Reihenfolge der Verschachtelung wählen, obwohl darüber gar keine Aussage gemacht werden soll. So soll in dem obigen Beispiel ein Text nur als fett und kursiv gekennzeichnet werden. Die Verschachtelung des Kursivelements in dem Fettelement verschleiert aber, daß hier die Fett- und Kursivdarstellung gleichberechtigte Auszeichnungen sind, die nicht ein einer hierarchischen Ordnung zueinander stehen.

Einfachheit von Attributwerten

Pro Attributname darf es in XML nur einen Attributwert geben. Dabei erkennt das W3C  selber die Notwendigkeit mehrerer Attribute schon in der wichtigsten XML-Anwendung XHTML. Dort soll es möglich sein, daß ein Elemente sowohl einer Klasse A als auch einer Klasse B  angehört. Da man aber nun in XML nicht schreiben darf »<p class="A" class="B"></p>« wird in XHTML statt dessen die Schreibweise »<p class="A B"></p>« verwendet.

Der Attributwert »A B« stellt nun einen Text einer weiteren formalen Sprache dar, die in XHTML zusätzlich zu XML verwendet werden muß, und in der Klassennamen durch Leerraum getrennt angegeben werden. Es wirft aber doch ein Licht auf die Ausdrucksmöglichkeiten von XML, wenn das W3C  schon in der Standardanwendung von XML, nämlich XHMTL nicht alle Strukturen mit den Mitteln von XML selber ausdrücken kann, sondern schon hier auf zusätzliche ad-hoc -Sprache ausweichen muß. Dieses Problem ist um so weniger verständlich, als HTML ja beim Entwurf von XML schon bekannt war und das W3C  auch auf jahrelange Erfahrungen mit SGML zurückgreifen konnte.

Ein Nachteil der Verwendung solch einer Mini-Sprache ist es beispielsweise, daß ihre Regeln nicht mehr mit einer DTD angegeben werden können, so daß auch die Korrektheit ihrer Verwendung nicht mehr durch Validierung überprüft werden kann.

Ad-hoc -Sprachen

In der Realität tauchen mehrfache Werte häufig auf. So kann ein Buch beispielsweise mehrere Autoren haben. Da XML mehrfache Attributwerte nicht erlaubt, sind Autoren gezwungen, innerhalb von XML eigenen ad-hoc -Sprachen zusammenzubasteln. In dem einen Fall werden dazu mehrfache Werte innerhalb eines Attributwertes durch Leerzeichen getrennt, wie eben dargestellt. In einem anderen Fall werden Elementtype als Namen zweistelliger Prädikate mißbraucht, wie in diesem Absatz beschrieben werden soll.

Sind Marie  und Alexander  die Autoren eines Buches, so wäre die naheliegende Schreibweise »<buch autor="Marie" autor="Alexander"/>«, da XML dies aber so nicht erlaubt wird oft auf die Verwendung von Unterelemente, wie in »<buch><autor>Marie</autor><autor>Alexander</autor></buch>«, ausgewichen.

Ein Mangel dieser Vorgehensweise ist die sinnwidrige Verwendung von Typen zur Angabe einer binären Relation. So hat das Element »<autor>Marie</autor>« ja den Typ »autor«, was also Maria als einen Autor  kennzeichnet. Das ist aber etwas anderes als das zweistellige Prädikat Ist-ein-Autor-von, das hier tatsächlich gemeint ist. Die Verwender solcher Notationen wollen hier mit dem Elementtyp die Beziehung des Elements zu seinem direkten Oberelement  angeben und nicht etwa den Typ des Elements. Dieses Prädikat sollte besser durch ein Attribut dargestellt werden, was aber in XML wie geschildert nicht direkt möglich ist. Die fehlenden Möglichkeiten zur Strukturierung von Attributwerten muß der XML-Anwender also selber durch den Mißbrauch eines Elementtypen als Relationstypen ausgleichen.

Strukturlosigkeit der Attributwerte

Da Attributwerte nicht mit den Mitteln von XML selber strukturiert werden können, kann die Verschachtelung von Elementen meist auch nicht nur einer speziellen Aufgabe pro XML-Anwendung zugeordnet werden (beispielsweise der Notation von Meta-Informationen), denn die Verschachtelung wird meistens benötigt, um die fehlenden Strukturierten Attribute nachzubilden.

Auswirkungen der Einschränkungen

Die unnötigen Einschränkungen von XML verhindern es, daß die Syntax in bedeutungstragender Weise eingesetzt wird. Daß sich so viele Dokumenttypgestalter fragen, wann Attribute und wann Elemente eingesetzt werden sollen, ist ein Mangel für eine Sprache, in der es eigentlich nicht viel anderes gibt außer Attributen und Elementen. Und nun ist es nicht einmal gelungen, diese beiden so zu gestalten, daß sie eine verständliche Widmung haben!

Ohne die geschilderten Einschränkungen hätte XML alleine bereits die Ausdrucksstärke von RDF/XML, das beim Aufbauen auf XML mühsam die gemachten Fehler reparieren muß.

Meinungen zum Thema dieser Seite

Eric Meyer

Eric's Archived Thoughts

http://www.meyerweb.com/eric/thoughts/200310.html#t200310015

Übersetzung des Textes von Eric Meyer  (mit freundlicher Erlaubnis des Autors)

Betrachten Sie das folgende XML -Fragment.

<stadt name="Köln" land="Nordrhein-Westfalen">23</stadt>

Gut …, irgendeine Idee, was diese Zahl darstellt? Nein, wahrscheinlich nicht. Was schlimmer ist: Wenn ich dieses Element einem Anzeigeprogramm geben, wird es den Elementinhalt darstellen: 23. Der Benutzer wird nicht einmal die Attributwerte haben, um ihm wenigstens die geringen Hinweise zu geben, die Sie erhalten, wenn Sie den Quellcode anschauen. Sie sehen nur die Zahl 23.

Das liegt daran, daß Attributwerte nicht angezeigt werden, während Elementinhalt angezeigt wird. Ja, wir können CSS-erzeugten Inhalt verwenden, um die Attributwerte sichtbar zu machen, aber ist es nicht verrückt, daß das folgende Fragment nötig wäre, um die Anzeige brauchbarer zu machen?

stadt:before {content: attr(name) " " attr(land) ": ";}

Und dann, wenn Sie die Datenstücke als Tabelle darstellen wollen—Sie können es nicht. Oh sicher, Sie könnten den erzeugten Inhalt in ein Darstellungsstück holen und den Elementinhalt in ein anderes, aber sie können den Stadtnamen und den Landnamen nicht in verschiedene Zellen holen. Selbst, wenn Sie "display: table-cell" auf den erzeugten Inhalt anwenden könnten, Sie könnten ihn nicht auf verschiedene Zellen aufteilen.

Wir könnten einwenden, daß dies Begrenzungen von CSS  wiedergibt und in gewissem Sinne stimmt das auch, aber damit würde das eigentliche Problem ganz verfehlt werden. Es wird immer irgendwelche Begrenzungen geben, die wir nicht überwinden können, etwas das die Darstellungssprache des jeweiligen Zeitpunktes nicht ermöglichen kann. Was ich meine ist die Tatsache, daß Darstellung untrennbar mit Struktur verbunden ist, und Dokumentautoren ignorieren diese Verbindung auf ihre eigene Gefahr. Lassen Sie uns zu diesem XML-Fragment zurückkehren und es so umstrukturieren, daß es vernünftiger wird:

<stadt region="westen">

  <name>Köln</name>

  <land>Nordrhein-Westfalen</land>

  <hoechsttemperatur skala="c">23</hoechsttemperatur>

</stadt>

Jetzt haben wir nicht nur mehr Informationen als eigentlichen Inhalt, der vorgabemäßig angezeigt wird, sondern tatsächlich auch mehr Elemente, deren Darstellung festgelegt werden kann. Nun können wird das XML -Fragment 1 in einer tabellenartigen Struktur zusammen mit einigen nützlichen Hinweisen für den Leser, darstellen, wie in dem folgenden CSS -Fragment.

stadt {display: table-row;}

stadt > * {display: table-cell; width: 33%;}

hoechsttemperatur[skala="c"]:after {content: " Grad Celsius";}

hoechsttemperatur[skala="f"]:after {content: " Grad Fahrenheit";}

Nun, dank unserer Struktur, können wir die Darstellung viel nützlicher für den Leser machen und sie selber besser verstehen. Wir können die Stadt und das Land unterschiedlich darstellen, was zuvor unmöglich war. Wir konnten auch die Werte von Attributen verwenden, um die Darstellung zu beeinflussen. Ich habe die Attribute verwendet, um zu zeigen, daß Attribute ganz und gar nicht nutzlose sind oder sogar ganz aus der Darstellung herausgehalten werden müssen. Sie können ganz praktisch sein. Trotzdem, das Attribut "region" ist ein gutes Beispiel für eine Angabe, die sorgfältig bedacht sein muß.

Wenn wir jemals die Region einer Stadt neben ihrem Namen positionieren wollen, dann ist es wahrscheinlich eine gute Idee, ein Element (wie das Element "<region>...</region>") an Stelle eines Attributs zu verwenden. Wenn wir die Information in dieser Datenstruktur nur zum Zweck der Umformung oder zur Beeinflußung der Darstellung untergeordneter Inhalte wollen ohne den Namen der Region wirklich anzuzeugen, dann ist ergibt ein Attribut viel mehr Sinn. Ein Beispiel dazu ist das folgende CSS -Fragment.

stadt[region="westen"] {background: green; color: white;}

stadt[region="osten"] {background: purple; color: white;}

Wenn wir solche Sachen machen, die Region fast wie eine Klasse behandeln, dann wollen wir sie sicher als Attribut. Wenn es ein Element wäre, mit dem Namen der Region als Inhalt, dann hätten wir keine Möglichkeit die Darstellung (oder etwas anderes) in Abhängigkeit vom seinem Inhalt festzulegen.

Worauf es hinausläuft ist, daß Struktur entscheidend für die Darstellung ist, mit oder ohne CSS —obwohl eine vernünftige Struktur die Anwendung von CSS  erheblich vereinfacht. Anders als es Einige behauptet oder vorausgesetzt haben mögen, kann man nicht einfach eine beliebige Struktur erzeugen ohne sich Gedanken über ihre Darstellung zu machen. Wenn Sie etwas auf dem Bildschirm wollen, sollte es Elementinhalt sein. Das ist vielleicht nicht ideal, aber man kommt nicht umhin es so zu machen. Struktur kann vielleicht von der Darstellung getrennt werden, aber die Darstellung braucht immer noch Struktur und hängt wesentlich von ihr ab. Ich selber bin auch nicht sicher, ob es jemals anders sein kann.