Geeigneter Listentyp für Pargraphen?

[molily]

Du gehst einfach davon aus, dass der Autor des Beispiels so denkt wie du. Diesen Glauben will ich dir ja im Prinzip auch gar nicht nehmen. (...) Das glaube ich dir aufs Wort, aber eigentlich projezierst du deine Ansicht über die Semantik auf ein Anwendungsbeispiel, ohne die von dir unterstellte Absicht des Autors hier zu zitieren oder anderweitig zu belegen.

Das ist doch gleich, ob die Semantik, die ich in einer Tabelle dieser Art sehe, auch so beabsichtigt war oder nur zufällig entstand. Es ist, was meine Aussage über die das Wesen der dortigen Tabelle angeht, egal, welche Absicht der Autor des Beispiels hatte. Daher hatte ich meine Aussage »andere sehen das anders« über die anderen existierenden Meinungen bereits dahingehend spezifiziert, dass ich Tabellen in der Art des Beispiels - wie beschrieben - für semantisch halte und sie auch mit dieser Semantik, die ich darin sehe, verwenden würde, um die Metainformationen eines Dokuments zugänglich zu machen. Mir ging es nie darum, den Autor der Beispielseite als Kronzeugen anzuführen, ich habe lediglich die abstrakten Verhältnisse der Daten und ordnende Bezüge beschrieben, die sich meiner Meinung nach in der Tabelle vorfinden. Ob sich der Autor dessen bewusst ist, ist mir im Prinzip egal, der Code sagt mehr aus, als ihm möglicherweise bewusst war.

Ich teile ihn nur nicht. Und da er an anderer Stelle Tabellen semantisch fragwürdig einsetzt, was du mir ja auch bescheinigt hast, halte ich es weiterhin für fragwürdig, ob er seine Syntax bewusst einer mit deiner kompatiblen Semantik unterworfen hat. -- Ich weiß es ebensowenig wie du, halte die anderen, semantisch fragwürdigen aber für ein Indiz.

Ich weiß wirklich nicht, welche Relevanz das hier hat. Dass der Autor an anderen Stellen semantischen Mist gebaut hat beziehungsweise wohl eine richtige Idee hatte (der Listencharakter von Dokumentabschnitten), aber die falsche Umsetzung wählte, ändert nichts an den Merkmalen und Eigenheiten der beschriebenen Tabelle und solchen Tabellen im Allgemeinen.

Ich verstehe "vornehmlich" als "vor allem", "in erster Linie" oder eben "maßgeblich, womit alle anderen Anwendungen von Tabellen also Ausnahmen darstellen, die diese Regel bestätigen.

Mir hilft die Unterscheidung zwischen Regel und Ausnahme hinsichtlich der Vergleichbarkeit bei der Frage, welche Tabellen semantisch sind, wenig weiter.

Persönlich habe ich noch keine Ausnahme gesehen, die einen so speziellen Charakter hätte, dass sie nicht allgemein ableitungsfähig wäre, was den Ausnahme-Charakter wieder negieren und die Regel letzlich aufheben würde -- was du im folgenden ja mit dem Begriff "unzählige" selbst belegst:

Mir fallen unzählige Beispiele für gleichförmige, kategorisierte Daten ein, die kein bisschen aufeinander Bezug nehmen und daher »Relationen zwischen den Daten« nur aufgrund ihrer Struktur bestehen (Datensatz X hat die gleichen Spalten und damit Bestandteile wie Datensatz Y). Eine alphabetisch geordnete Adressenliste in Form einer Tabelle etwa kann die Spalten Name, Straße, PLZ, Stadt, Telefon enthalten. [...]

Für mich ist dies ein klassisches Beispiel für verschachtelte Listen, die ja nach genau dem von dir beschriebenen Prinzip funktionieren.

Sicherlich lässt es sich mit verschachtelten Liste abbilden. Wenn man sich etwa die Datenstruktur anhand von Knoten verdeutlicht, so sind die Datensätze auch Listenelemente, die jeweils bestimmte Eigenschaft-Wert-Paare enthalten. Hier hat sich das Auffassen als Tabelle aber offenbar als hilfreicher erwiesen, interessant ist auch, dass die sogenannten »Tabellen« in relationalen Datenbanken auch aus solchen Datenstrukturen bestehen können, die du als Listen auszeichnen würdest, und dies wahrscheinlich auch zu einem stattlichen Anteil tun. Eine andere Annäherungsweise wäre das Nachdenken über äquivalente XML-Strukturen:

<adressen>
<adresseintrag>
<name>...</name>
<strasse>...</strasse>
...
</adresseintrag>
...
</adressen>

Ein Schelm, wer hier Gemeinsamkeiten sieht... ;)

<table>
<thead><tr><th scope="col" id="name">Name</th>...</tr></thead>
<tbody>
<tr>
<td headers="name">...</td>
<td headers="strasse">...</td>
...
</tr>
...
</tbody>
</table>

(Bzw. <adresseintrag id="[Name]"> und entsprechend <th headers="name" scope="row">[Name]</th>, wenn man die Merkmalspaare jeweils noch explizit als Kinder eines benannten Datensatzknotens versteht.)

Zum einen hast du noch nicht beantwortet, wie du diese Paare mit verschachtelten Listen auszeichnen willst (außer mit <ul><li><dl><dt>Eigenschaft1</dt><dd>Wert1</dd>..</dl></li>...</ul>?) und zum anderen ist im Gegensatz zur Tabelle nicht herausgearbeitet, dass die Datensätze nicht willkürliche Merkmale haben, sondern jeder Datensatz Werte hinsichtlich bestimmter, datensatzübergreifender Merkmale hat. Bei einer Tabelle ist dies durch die Einordnung in eine gewisse Spalte und die implizite und explizite Verknüpfung über th und scope/id/headers festgelegt, bei eine Liste nicht. Die Eigenschaft eines Datensatzes ruft immer eine Spalte hervor, die Gleichförmigkeit aller anderen Datensätze verlangt.

Im Übrigen hattest du gefordert, die Elementliste im besagten DCMI Core Element Set-Dokument als Tabelle auszuzeichnen, dabei ist es doch selbst eine klassische verschachtelte Liste? Es liegt m.M.n. keine Vergleichbarkeit vor (die käme erst mit den element refinements - mir fällt eh gerade keine Möglichkeit der dritten Dimension ein). Noch einmal die besagte überarbeitete Struktur:

<table><thead><tr><th scope="col">Element Name</th><th scope="col>Label</th><th scope="col>Definition</th><th scope="col>Comment</th></tr></thead><tbody><tr><th scope="row">Title</th><td>...

würde etwa zu

<ul>
<li>
 <dl>
 <dt>Element Name</dt>
  <dd>Title</dd>
 <dt>Label</dt>
  <dd>Title</dd>
 <dt>Definition</dt>
  <dd>A name given to the resource.</dd>
 <dt>Comment</dt>
  <dd>Typically, Title will be a name by which the resource is formally known.</dd>
 </dl>
</li>
...
</ul>

In wie weit mir die Methodik der Juristen an sich zusagt oder nicht, ist eigentlich egal, mir ging es darum, ein Gesetz webgerecht aufzuarbeiten und wiederzugeben - für Menschen, deren Verständnis ebenfalls hinter dem der Fachleute des Gebietes zurückliegt -, und diesbezüglich halte ich oben genannte Sichtweise für wenig zielführend und spreche solchen Bezeichnern keinen eigentlichen, unmittelbaren Wert zu, so angemessen sie in anderen Zusammenhängen sein mag, etwa wenn Fachmenschen sich untereinander auf entsprechendem Wissenslevel in entsprechendem Code austauschen.

Inwieweit die Form der Strukturierung dabei hilfreich sein kann, bleibt mir dennoch ein Rätsel. Ob du einen Begriff definierst, ihn als Überschrift verwendest oder in eine Tabelle stellst, sollte auf die Verständlichkeit der Aussage keinen Einfluss haben, da ja offenbar die Inhalte das Unverständliche sind, nicht deren Struktur.

Die Auszeichnung beeinflusst hier durchaus die Art der Aufnahme der Inhalte. Eine Überschriftenstruktur etwa kann als solche durchsprungen werden und taucht in entsprechenden Gliederungsnavigationen auf. Eine Tabelle erlaubt es, eine Zelle zumindest über zwei Achsen in seiner Zugehörigkeit zu bestimmen (zugegeben, das geht bei verschachtelten dl-Elementen auch, also <dl><dt>Datensatztitel1</dt><dd><dl><dt>Merkmal1</dt><dd>Wert1</dd>...</dl></dd>..</dl>, wäre vielleicht auch angemessener beim obigen Codebeispiel, müsste man näher untersuchen) und sie erlaubt ein direktes Springen von einem bestimmten Wert eines Datensatzes zu einem Wert eines anderen Datensatzes desselben Merkmals. Die Strukturierung kann also die Lesebedingungen und die Bedienungssituation entscheidend ändern und diese »Präsentation« der Daten hängt m.E. sehr stark mit der Verständlichkeit der Aussage zusammen, selbst wenn man annimmt, dass die verschiedenen Markupstrukturen denselben Sachverhalt wiedergeben, nur andere Schwerpunkte setzen und Herangehensweisen verwenden.

Was ich auch zu sagen versuchte, war, dass die Sichtweise »der Paragraphinhalt ist die Definition der Paragraphbezeichnung« notwendigerweise Auswirkungen darauf hat, wie der Inhalt und überschreibende Bezeichnung aussehen. Dann muss ich von der Bezeichnung auch verlangen, dass sie als angemessener, nicht zu präziser und nicht zu allgemeiner Container für die Inhalte dienen kann und auch wirklich »für diese (stellvertretend) steht«. Ob das etwa bei »§3 Ordnung auf dem Friedhof« usw. der Fall ist, bezweifle ich, obwohl ich es am Friedhofsordnungsbeispiel mit den im Allgemeinen relativ aussagekräftigen Paragraphentitel (und den zusätzlichen Übersichtskategorien jenseits des Paragraphensystems) noch besser nachvollziehen kann als bei einem BGB-Pararaphen oder ähnlichen.
Bei Überschriften muss man sich genauso Gedanken darüber machen, in wie weit sie den betitelten Inhalt kennzeichnen und »repräsentieren«, da stehen aber m.M.n. andere Kriterien im Vordergrund als bei der Definitionsliste im strengen Sinne, die Überschrift umfasst den Inhalt nicht. Aber die Unterscheidung verschwimmt mir, wenn ich von der Definition absehe und jeweils nur die Zuordnung vergleiche (gemäß dem Zitat aus der ersten HTML-Spec).