Geeigneter Listentyp für Pargraphen?

[at]

Hallo.

Häh? Da folgt im Beispiel nur ein Datensatz;

Häh? Und wofür stehen bei dir Ellipsen?

außerdem, wie kann das Wort »Adresse« die folgenden Datensätze zusammenfassen, wenn alle Datensätze bzw. Datensatzgruppen denselben Titel haben?

"Adresse" fasst eine Liste aus "Name", "Straße" etc. zusammen.

Das fände ich vollkommen überflüssig.

[...]

Dieser Vorgehensweise kann ich nachwievor keinerlei Nutzen abringen - Informationen im Text unterzubringen, sie dann aber in nahezu allen Zusammenhängen als unwesentlich zu betrachten und zu verstecken.

Das ist doch schon deswegen kein Problem, weil du das doch ohnehin nicht machst. -- Ich sehe einen Sinn darin, habe diesen bereits erläutert und werde es weiterhin so handhaben.

Darüber hinaus habe ich absichtlich herausgestellt, dass der eindeutige Datensatztitel (»Primärschlüssel«) hier meinem Verständnis nach der Name ist, es ist also kein Merkmal wie alle anderen Merkmale.

Was "kein Merkmal wie alle anderen Merkmale" sein soll, hebe ich durch logische Formatierung hervor.

Das ändert nichts daran, dass die Wichtigkeit und das Herausragen nicht aus dem Markup erkennbar ist, sondern erst durch die Formatierung. Damit gibt das Markup nicht die Bedeutung wieder. Das führt zu den geschilderten Nachteilen.

Jede logische Formatierung erfolgt durch Markup und ausschließlich logische Formatierung gibt die Bedeutung wieder. Wie die Hervorhebung ausgestaltet ist, ist davon unabhängig, und ob sie erkennbar ist, obliegt dem User Agent oder dem Gestalter.

Ich sehe vor allem den Nachteil, für jeden abweichenden oder zusätzlichen Eintrag eine weitere Spalte oder flexiblere Überschrift finden zu müssen, etwa bei zusätzlichen Postfachadressen etc.

Das ist dann tatsächlich eher eine Frage von flexiblen Kopfzellen, also der Kategorisierungsleistung der Datenstruktur. Mit Listen entzieht man sich natürlich jedem Zwang zur Vereinheitlichung und Kategorisierung, wie gesagt. Die Merkmale/Eigenschaften der Datensätze folgen dabei keinem gemeinsamen Schema, da sie sich nicht (bzw. nicht explizit, nicht maschinenlesbar, nicht redundant usw.) auf ein gemeinsames Schema beziehen, wie es bei Tabellen im thead definiert wird. Denke auch an maschinelle Verarbeitung und Speicherung, also wie gesagt über SQL bzw. XML - da ist Kategorisierung wieder Zwang.

Um so praktischer werden hier Verschachtelungen möglichst einfacher Strukturen, die sich mittels Bezeichner/Wert-Zuordnung herstellen lassen.

Wo sollen bei der in eine Tabelle umgewandelten DCMI-Core-Elementliste Differenzen aufgezeigt werden, was liegt denn hier vor?

In der derzeitigen Form sehe ich hier -- wie bereits -- erwähnt keine Tabelle gerechtfertiget, könnte mir aber vorstellen, bei einer Umformung die Vergleichbarkeit so weit herzustellen, dass eine Tabelle gerechtfertigt wäre. So fällt beispielsweise der Gebrauch des Bezuges auf "resource" innerhalb von "Definition" auf. Vielleicht würde ich "Defnition" durch "Reletion to resource" ersetzen, um nur noch ein oder zwei gut vergleichbare und die Unterschiede deutlich heruasstellende Begriffe gegenüberstellen zu können. Aber ich werde mich nicht länger mit diesem Dokument auseinandersetzen.

Und war jetzt der Punkt, in dem sich diese Daten von der Auflistung der Metadaten des Dokuments am Dokumentanfang fundamental unterscheiden, sodass für die Elementliste eine Tabelle gebraucht werden sollte und für die Metadatenliste eine Listenstruktur? (Bitte nicht zum x-ten Mal die Theorie wiederholen...)

Ich wiederhole hier ersteinmal gar nichts, sage aber auch nichts Neues, da ich diesen Satz nicht verstehe. Hab ich mich in den Nebensätzen verfangen oder doch du?

Insofern halte ich die jetzige Aufteilung noch für angemessener, weil der Sprung in einer Spalte von Zeile zu Zeile nicht sehr notwendig ist, da das Springen von Eintrag zu Eintrag bereits über die Überschriften ermöglicht wird.

Das Springen des Auges von einem hervorgehobenen Eintrag zum nächsten ist sicher ebenso leicht.

Ähm... Es ging um die Struktur, von der du sagtest, sie solle als Tabelle ausgezeichnet werden, oder wie habe ich deinen Allgemeinplatz »Sobald die Vergleichbarkeit der Datensätze im Vordergrund steht, verwende ich Tabellen.« auf meine konkrete Frage zu verstehen, warum du gerade hier eine Tabelle für angemessen hältst?

Ahm... Ich kann zwar den Bezug zum von dir zitierten Teil des Dialogs nicht nachvollziehen, verstehe aber auch nicht, welche Frage meine Antwort offen gelassen haben sollte. Wenn ich die Vergleichbarkeit von Datensätzen zum vorrangigen Ziel habe und diese Semantik auch dem Leser suggerieren möchte, wähle ich eine Tabelle -- und nur dann. Dies funktioniert folglich nur dann, wenn ich weiß, welche Wirkung erzielt werden soll, was ich beim von dir angeführten Beispiel nur vermuten kann. Und da mir die Form des Beispiels keinen überzeugenden Hinweis auf einen Fokus des Autors auf Vergleichbarkeit liefert, deckt sich die verwendete Struktur nicht mit meiner Semantik.

Ich wollte doch gerade sagen, dass dieser Sachverhalt nichts daran ändert, dass die (möglichst) eindeutigen Indizes, also die Namen, für den Vorgang der geschilderten »Abfrage« der Datenbank von oberster Bedeutung sind. Dass die Namen direkt untereinander in einer Spalte aufgelistet sind, ermöglicht erst diese Nutzung, das Scannen, das schnelle Erfassen. Darauf bist du gar nicht eingegangen, ich sehe hier aber einen Knackpunkt in der Bedienung.

Den sehe ich nicht, da die visuelle Aufbereitung nicht der Struktur obliegt, sondern dem für die Darstellung verantwortlichen CSS.

Die gedanklichen Operationen des Lesers/Benutzers sind die des durchlaufens der Indexspalte und das Abgleichen mit dem gesuchten Namen. Man könnte sich die Liste also auch verkürzt als Namensliste vorstellen, die die Namen mit Dokumenten verlinkt, die den gesamten Datensatz enthalten (das nur zur Verdeutlichung der logischen Beziehungen).

Ja, dann mache das doch (zur Verdeutlichung der logischen Beziehungen).

Da bei der Adressliste die Namen wie gesagt als »Index« verwendet werden, sollten sie auch entsprechend formatiert sein; in deinem Vorschlag sehen sie wie alle Eigenschaften des Eintrags aus. Der Sprung mit dem Auge zum nächsten hervorgehobenen Text wäre also ebenfalls erschwert.

Selbst ohne weiteres HTML wäre dem mittels ":first-child" beizukommen.

Eben diese Auffassung kritisiere ich, da CSS nicht das Mittel ist, um Bedeutung hervorzuheben.

Daher ja auch "Selbst ...". HTML bietet hinreichende Möglichkeiten der semantischen Hervorhebung.

Natürlich will ich die Umstände der Informatiosnaufnahme weitesgehend in die gewünschte Richtung beeinflussen, daher denke ich, dass bei der Adressenliste die Tabellenstruktur den üblichen Aufgaben gerecht wird.

Wenn es mir um die statistische Verteilung der Postleitzahlen ginge, täte ich das doch auch. Wenn die Adressenliste einen solchen Fokus haben sollte, habe ich sie bisher falsch verstanden. Wenn es eine Auflistung von Daten gewesen sein soll, wie ich angenommen habe, ist es für mich in erster Linie eine Liste.

Zum Glück leben wir im Hypertext, da sind prinzipiell verschiedene Perspektiven möglich, sich einen Inhalt zu erschließen. Serverseitige Techniken erlauben verschiedene pointierte »Darstellungen« ein und derselben Datenstruktur, die verschiedenen Zwecken und Ansprüchen gerecht werden.

Yep. War das ein Schlusswort? ;-)
MfG, at