Elemente

Die Elemente einer WHWT.dtd sind kopf- und körperlos, weil die Köpfe und Körper in ihren WH- und WT-Treibern deklariert werden. Die Elemente von WHWT sind somit der Körperinhalt und alles, was davor und danach kommt, im vorliegenden Fall die frontm und die backm.

Da viele der hier auftretenden Elemente aus der general.dtd sind und dort bereits dokumentiert sind, kann sich die vorliegende Dokumentation auf die neu hinzugekommenen Elemente und auf die Aufgabe konzentrieren, die WHWT.dtd als das gemeinsame Dritte der WH und WT.dtds zu schildern und die Kenntnisse über SGML vertiefen.

Document Structure frontm titlep, toc?, (%fm.d;|partb)*, figlist? 21

Die Deklaration der frontm und die content token im content model des element type stehen sich als entity structure und element structure gegenüber, sind aber nicht spiegelbildlich, weil die Deklaration das lineare Abbild (oder Vorbild) des teilehabenden content ist. Da es sich bei der declaration um Algorithmen handelt, in denen das Getrennte das Geteilte dominiert, ist ihre Darstellung als entity structure angemessen.

Deklaration content model
frontm is ( titlep toc? ( %fm.d; partb)* figlist?) element type content model model group content token content token model group content token content token content token

Und da im content model das Geteilte das Getrennte dominiert, ist seine Darstellung als element structure erforderlich. Diese Gegenüberstellung mache ich in erster Linie, um das content model in Aktion vorzuführen, das in einer Deklaration nicht sichtbar auftritt, also die Verknüpfung der model groups (Klammernpaare) und die sie enthaltenden content tokens mit ihren connectors und occurance indicators. Dem content model entspricht in der Deklaration der zweite Winkel direkt neben frontm. Ich habe spaßeshalber dort das is element eingegeben, das der firefox browser im inspector in der element instance gar nicht so dumm als Behälter der rechten Seite der Gleichung interpretiert, obwohl es den declared content EMPTY hat. Er hat hier offenbar das content model im Auge und hat erkannt, dass das Getrennte dem Geteilten folgt. Denn in Wahrheit sind die beiden Modelle von relabise und entabise, mit denen die Gegenüberstellung gezeigt wird, dieselben Modelle und haben nur andere Namen (die Papas sind in beiden sogar gleich).

Aber nun zum Unterschied zwischen WH und WT!

In einem WH Dokument ist die front matter vor dem BODY.

In einem WT Dokument ist die front matter das erste Element im body, weil vor dem body nur der head ist. Da die Elemente im WT body in einer repeatable or group stehen, können frontm, parta, backm in dieser Reihenfolge auftreten.

In einem WH Dokument sind der appendix und die back matter die beiden Elemente nach dem BODY.

appendix parta 23 backm (%bm.d;|partb*), index? 24

In einem WT Dokument sind der appendix und die back matter die beiden letzten Elemente im body, weil nach dem body nichts mehr ist.

figlist|index EMPTY26, 27 figure list and index have generated content toc relabiseIVZ|tababiseIVZ|divabiseIVZ 25 tababiseIVZ|divabiseIVZ #PCDATA

Die Inhaltverzeichnisse werden zunächst von der Applikation generiert, dann mit einer Strukturierungstabelle strukturiert (einem Leckerbissen von FM, der im Structure FM Developer's Guide Appendix A: Conversion Tables for Adding Structure to Documents beschrieben wird) und zum Schluss in das toc Element eingegliedert. divabiseIVZ ergibt das bekannte eindimensionale IVZ, relabiseIVZ ein zweidimensionales IVZ, tababise steht nur aus historischem Interesse da und soll durch I23ABC abgelöst werden.

Alternativ können die Inhaltsverzeichnisse händisch erstellt werden, wie es in der AAP application vorgeschlagen ist. 17.10.2018 relabiesIVZ rausgenommen, steht unten.

AAP toc mit Elter aaptoc %m.toc;a tocparta %m.tocparta; tocpartb %m.tocpartb; tocpartc %m.tocpartc; tocpartd %m.tocpartd; tocparte %m.tocparte; relabiseIVZ, toc mit Eltern, papa ist tocpart, mama ist reln2 vgl. relabise relabiseIVZ relaIVZ generiertes IVZ relaIVZtocparta, rela2IVZ+ Stufe a rela2IVZrelbIVZ* Mama zeugt Nachwuchs relbIVZtocpartb, relb2IVZ+ Stufe b relb2IVZrelcIVZ* Mamb zeugt Nachwuchs relcIVZtocpartc, relc2IVZ+ Stufe c relc2IVZreldIVZ* Mamc zeugt Nachwuchs reldIVZtocpartd, reld2IVZ+ Stufe d reld2IVZreleIVZ* Mamd zeugt Nachwuchs releIVZ tocparte Stufe e
Title Page Elements titlep titel & docnum? & abstract? & datum? & (author|(%s.zz;))* 28 Document number etc. 3.12.2015 tue datum dazu

Das title page element titlep aus der front matter ist das einzige in dieser DTD, bei der der and connector auftritt. Alle durch and verbundnenen tokens müssen (in beliebiger Reihenfolge) auftreten. Da aber alle außter titel einen optionalen oder optional repeatable occurance indicator haben, ist nur der titel obligatorisch.

Formal handelt es sich bei einer and group um ein "non-repeatable or" aller n verbundnen tokens, das in nn Vatiationen auftreten kann, vielleicht auch nn-1, das weiß ich nicht genau.

body titlep titel | docnum? | abstract? | datum? | (author | %s.zz;)*

Vier Elemente der titlep im Einzelnen.

docnum|author %m.ph; 29, 31 datum wird durch die Attribute em und emP erledigt, Oktober 2012. Habe im nov 2015 ein datum Element hinzugefügt titel tline+ 32 document title auf deutsch, weil title von table und vom html head benutzt wird. tline %m.ph; 33
Parts

Hierarchie hat meist den Charakter des zu kleinen Kopfes auf dem zu großen Körper wie bei einem Dinosaurier.

Luther spuckt noch Gift und Galle gegen die Hierarchie (wörtlich: die heilige Herrschaft, vor hieros heilig und arche Herrschaft), mit der der katholische Klerus seinerzeit das Ganze und den Teil als entity structure verhundst hat, statt seine element structure offenzulegen, wie auch Tim Berners Lee gegen die starren Strukturen innerhalb des Cern wettert, das damals mit den ersten SGML Applikationen arbeitete (und die DMLer wettern gegen die Hierarchie des W3C). Aber jeder weiß, dass es ohne ein formales Gerüst einer Teilung und Unterteilung des Ganzen nicht klappt. Zwar verspricht jeder, etwas Bessseres and die Stelle der Hierarchie zu setzen. Die Meisten lösen wie Luther ihr Versprechen nicht ein.

SGML zeigt, dass das nicht so sein muss, weil SGML ein System ist, das das Trennende und das Teilende gemeinsam betrachtet und nicht nur das eine oder das andere. Betrachten wir zunächst das gemeinhin als "Hierarchie" bezeichnete Modell.

parta bis parte = Headed Sections = das Elter Modell

Die headed sections in WHWT unterscheiden sich von denen der general.dtd nur durch ihre Namen parta bis parte anstelle von h0 bis h4. Die Namen sollen den Aufbau der element strucure reflektieren.

Sie füllen in einem WH Dokument den BODY vollständig aus, während sie in einem WT Dokument in der Mitte zwischen der front matter und der back matter im body sind und zusammen mit diesen den body ausfüllen.

partaha, (%s.zz;)*, partb* 34 Part partb|%bm.d;|%fm.d; hb, (%s.zz;)*, partc* 35, 36, 37 Chapter partc hc, (%s.zz;)*, partd* 38 Section partd hd, (%s.zz;)*, parte* 39 Subsection parte he, (%s.zz;)* 40 Subsubsection ha|hb|hc|hd|he|HEAD %m.ph; 41, 42, 43, 44, 45 Überschriften, HEAD als Überschrift, weil head für HTML benötigt wird, lösche h 10.08.2017
Entity structure Element structure
parta partb partc partd parte text text text text text parta partb partc partd parte text text text text text

Jeder part einer solchen "hierarchischen" Struktur füllt sein "elter" Element vollständig mit text und einem oder mehreren Folgeparts aus. parta besteht aus text und partbs, partb besteht aus text und partcs und so weiter. Nur parte besteht nur aus text und hat keinen Folgepart "partf", sondern nur noch weitere parte mit text (in partd). Mit diesem Modell arbeitet die Menschheit seit mehreren Jahrtausenden ohne ISO 8879 (SGML). Aber erst SGML hat dessen Struktur in eine für Mensch und Maschine lesbare Form gebracht, wobei in SGML nicht die Maschine, sondern die Form und der Mensch die Hauptrollen spielen, was die Maschinenbesitzer anfangs verzagt, und dann immer beherzter wieder in die aus ihrer Sicht richtige Form gebracht haben, in der die Maschine den Menschen beherrscht. Aber das ist nicht das Thema.

Das Thema ist, dass in einer solchen Form der Teilung eines Ganzen stets ein Eines am Anfang ist, das sich in zwei oder mehr Teile teilt.

Ob hier die entity structure genannte Darstellung oder die element structure angmessen ist, hängt davon ab, ob man lieber das Trennende oder das Teilende sehen möchte. In der entity structure kommt die Trennung der parts und des text besser zum Ausdruck, in der entity structure ihr Teilsein. Beides ist hier miteinander verwoben.

part = rekursive section part datum?, HEAD, (%s.zz;)*, part*
Entity structure Element structure
part part part part part ... text text text text part part part part part ... text text text text

Die rekursive section part ist wie das elter Modell aufgebaut, hat jedoch keine letzte Teilungsstufe, sondern ist "endlos" rekursiv wie ein Kettenbruch.

Der HEAD im part ist großgeschrieben, weil der head eines der beide Elemente von html ist, das das Ganze des WT Dokuments is: [+]html = [+](head, body).

Relationales SGML = das Eltern Modell

relabise, entabis und I23ABC sind Modelle zur relationalen Verknüpfung und Darstellung von Tabellen in HT. Es handelt sich bei ihnen zwar im deduktive Modelle wie alle Modelle in SGML, aber ihre Anfänge sind nicht ein Eines, sondern sind Zwei.

Dabei handelt es sich in keinem der folgenden Modelle im SGML Editor oder im markup um Tabellen, sondern nur um container Elemente, die erst durch die CSS Anweisung display: table, display: table-row und display: table-cell zu Tabellenelementen werden. Denn der SGML Editor kann zwar rekursive container, aber keine rekursiven Tabellen haben.

Diese Modelle ergeben nur mit einem html parser (browser) einen Sinn, weil nur ein darstellungsorientierter Dokumententyp mit rekursiven Tabellen wie HT zur Darstellung des Beziehungsgeflechts in der Lage ist.

relAbisE, das Eltern Modell

Zweifellos sind in den numerierten oder rekursiven sections parta bis parte oder in part zwischen allen zwei Strukturierungsstufen Eins zu n Verknüpfungen gegeben, weil sich auf jeder Stufe ein Ganzes in n Teile teilt. Warum sieht man diese Relationen nicht, wenn sie doch da sind?

Leute, die weder von SGML noch von Datenbanken große Ahnung hatten, haben zur Zeit der SGML Begeisterung meist gesagt, SGML ist keine Datenbank, wenn das Gespräch auf die Ähnlichkeit zwischen den Relationen in Datenbanken und SGML kam. Da hatten sie, ohne es zu wissen, recht. Denn SGML ist besser als jede Datenbank, weil es keine Indexe braucht, um Relationen zwischen zwei oder mehr Tabellen zu erzwingen, sondern weil die Relationen hier Teile des Schreibflusses sind, der keinen Zwang und keine Zeile Programmcode benötigt. Dass sich das auch tabellarisch zeigen lässt, ist mir 2008 auf einem Waldspaziergang aufgeleuchtet. Das relAbisE Modell geht den Schritt vom Elter zu den Eltern, indem es Zwei an den Anfang setzt, die ein Drittes zeugen und damit die Monarchie, die nur das Eine im Anfang kennt, daran erinnert, dass in der Natur das Werden aus Zweien geschieht. Wer philosophisches Interesse am Urvater der eingeschlechtlichen Fortpflanzung im elter Modell hat, der lese die Metaphysik des Aristoteles (hier besonders das zwölfte Buch), der dort deren eifersüchtiger Verteidiger ist. Die zweigeschlechtliche Fortpflanzung auf universeller Ebene findet sich im Urvater der Ontologie, in Platons Parmenides oder seinem Lehrgedicht über das Sein.

Man sieht die relationalen Verknüpfungen im elter Modell von parta bis parte nicht, weil in dem sectioning der Text und das Teilungselement nicht getrennt voneinander sind, sondern die Überschrift und %s.zz; unmittelbar vor partx auf einer Ebene stehen. Werden die beiden Aufgaben des Textens und des Teilens in getrennten Behältern ausgeführt, sieht man die Relationen. Erst die von SGML begründete, aber nicht in die letzte Konsequenz durchgeführte Trennung von Text und Struktur macht sichtbar, was jeder durch die wissenschaftliche Notation im elter Modell zum Ausdruck bringen will, was aber bisher nur im Kopf des Autors oder Lesers war. Das Atom der relationalen Struktur ist nicht eine Eines, sondern das Molekül der Struktur sind Zwei.

In der relationalen Datenbank sind die Verknüpfungen zwei Verweise in einer "Indextabelle", die die Relation simulieren. Die einzeilige zweizellige Tabelle rela in relabise ist das Element, das der erste Baustein einer solchen Relation ist und sie nicht nur simuliert. Denn die beiden nebeneinander stehenden Zellen papa und mama sind so getrennt, wie zwei Elemente nur getrennt sein können, und sie sind ein Nebeneinander im Ineinander. Nun das Modell.

relabise rela+ die liebe Verwandtschaft relapapa, mama+ Eltern, Papa ist nicht monogam papaha, (%s.zz;)* und Papa textet mamarelb* Mama zeugt Nachwuchs relbpapb, mamb+ Eltern papbhb, (%s.zz;)* Papb textet mambrelc* Mamb zeugt Nachwuchs relcpapc, mamc+ Eltern papchc, (%s.zz;)* Papc textet mamcreld* Mamc zeugt Nachwuchs reldpapd, mamd+ Eltern papdhd, (%s.zz;)* Papd textet mamdrele* Mamd zeugt Nachwuchs relepapePape ist Single papehe, (%s.zz;)* und textet

rela, relb, relc, reld und rele sind Tabellen.

papa, mama, papb, mamb, papc, mamc, papd, mamd sind Zellenpaare, und

pape ist eine Single-Zelle.

Das wird für die Darstellung in CSS einfach mit der display Eigenschaft so festgelegt. Reihen werden in relabise vom browser aus dem Nebeneinander (einer) zweier oder mehrerer Zellen "erschlossen" und sind keine expliziten Teile von relabise.

Vielleicht wird die Darstellung der element structure des Eltern Modells in relabise deutlicher, wenn wir sie der element structure des elter Modells gegenüberstellen.

Element structure relabise Element structure partabise
rela mama relb mamb relc mamc reld mamd rele pape text papd text papc text papb text papa text parta partb partc partd parte text text text text text
rela besteht aus mama und papa parta besteht aus partb und text
mama besteht aus relb
papa besteht aus text
relb besteht aus mamb und papb partb besteht aus partc und text
mamb besteht aus relc
papb besteht aus text
relc besteht aus mamc und papc partc besteht aus partd und text
mamc besteht aus reld
papc besteht aus text
reld besteht aus mamd und papd partd besteht aus parte und text
mamd besteht aus rele
papd besteht aus text
rele besteht aus pape parte besteht text
pape besteht aus text

rela bis rele enthalten zunächst nur element content, der sich erst im nächsten Schritt in seiner Rolle als Vermehrer oder als Texter darstellt. Während die parta bis parte Vermehrung und Text in Einem erledigen, sind die Vermehrer mama bis mamd von den Textern papa bis papd getrennt. Die einem machen nur das eine, die anderen nur das andere.

Text und Struktur sind in diesem Modell erstmals wirklich getrennt. In CSS müssen nur die geraden und die ungeraden Tabellenstufen unterschiedlich eingefärbt werden, und die Darstellung der relationalen Verknüpfung von fünf oder mehr Stufen ergibt sich automatisch.

Zur Darstellung

Das relabise habe ich erfunden, um eine fünfstufige Verknüpfung etwa von partabise optisch darzustellen. Soll das relabise Modell wie oben links selbst dargestellt werden, das sich nicht mit dem papa im Anfang begnügt, sondern die mama dabeihat, kommt man mit fünf Stufen nicht aus. So müssen wir für die obige Darstellung von relabise papf, papg, paph und den papi hinzufügen, der seinen Text im papk in der mami hat. Hier bin ich noch auf der Suche nach der "richtigen" Darstellung, wie sie etwa Eve Maler im Appendix B Tree Diagram Reference S. 405ff gibt. Wenn partabise mit relabise dargestellt wird (für dessen text in parte ich auch schon einen papf benutzen musste), müsste es dann für relabise auch eine übergeordnete Instanz geben, mit der relabise dargestellt wird? Oder ist es nur die Anzahl der Strukturierungsstufen, die den Unterschied macht?

Ursprünglich wollte ich die neu hinzugekommenen Stufen nach der Demonstration wieder löschen. Aber da diese Tabellenmodelle nicht zum Schreiben gedacht sind, wo eine zu tiefe Strukturierung bald verwirrend ist, sondern sich auch für technische Dinge nutzen lässt, die oft viele Gliederungsstufen benötigen, lasse ich sie stehen. Sie können jederzeit verkürzt oder verlängert werden.

entAbisE wie relabise, zur Demonstration der entity structure mit CSS, die papas holen sich die emamas aus relabise

Das entabise Modell unterscheidet sich in nichts außer den Namen von relabise. Es hebt nur die Darstellung des Getrennten hervor, während relabise das Geteilte zeigt. Das tut es einfach, indem es in CSS zwei Grenzen der Tabellen hervorhebt, während relabise abwechselnd gefärbte Hintergrundfarben der Tabellen haben.

entabise enta+ die liebe Verwandtschaft enta papa, emama+ Eltern emamaentb* eMama zeugt Nachwuchs entb papb, emamb+ Eltern emambentc* eMamb zeugt Nachwuchs entc papc, emamc+ Eltern emamcentd* eMamc zeugt Nachwuchs entd papd, emamd+ Eltern emamdente* eMamd zeugt Nachwuchs ente pape In der Ente ist Pape allein
Entity structure entabise
enta emama entb emamb entc mamc reld emamd ente pape textet papd text papc text papb text papa text
enta besteht aus emama und papa
emama besteht aus entb
papa besteht aus text
entb besteht aus emamb und papb
emamb besteht aus entc
papb besteht aus text
entc besteht aus emamc und papc
emamc besteht aus entd
papc besteht aus text
entd besteht aus emamd und papd
emamd besteht aus ente
papd besteht aus text
ente besteht aus pape
pape besteht aus text
I23ABC, Reihenentwicklung

Das Problem der "richtigen" Darstellung ist eigentlich auf den ersten Blick auf die Element structure relabise von oben ersichtlich: Die beiden "nebeneinander stehenden Zellen papa und mama" stehen nicht nebeneinander, sondern übereinander! Der "tree" wird nicht, wie wir es gewohnt sind, von oben nach unten entwickelt, sondern mit dir = "rtl" oder dir ="ltr" von rechts nach links oder von links nach rechts.

I23ABC löst das Problem. I23ABC habe ich einige Jahre nach relabise ausgebrütet. Es beruht auf demselben Prinzip der Zwei im Anfang wie relabise, nur stellt es diese Relationen nicht von rechts nach links oder von links nach rechts dar, sondern von oben nach unten.

Das Strukturmolekül besteht aus einer zweizelligen zweireihigen Tabelle und ist deswegen etwas länger als relabise. Bei relabise ist die Reihe implizit. In I23ABC sind die zwei Reihen explizit. Hier wäre in CSS ein Attribut analog dir (ltr|rtl) angebracht mit den Werten (ttb|btt), top to bottom, bottom to top.

Bevor ich das Modell vorstelle, will ich seinen Einsatz an relabise demonstrieren.

rela papa txt mama relb papb txt mamb relc papc txt mamc reld papd txt mamd rele pape text

Das ist die richtige Darstellung von relabise. Wie es scheint, stellt die Struktur des Übereinander das Nebeneinander dar. Denn papa und mama werden mit dem Molekül zweier übereinanderstehenden Zellen nebeneinander dargestellt, wie wir es von einem "tree" gewohnt sind. Und die Strukturtiefe fängt oben in der Wurzel an und verzweigt sich auf die Äste und Blätter nach unten, ebenfalls wie gewohnt. Das Beste aber ist die Darstellung der Trennung von Text und Struktur, die hier unmittelbar einleuchtet, während man bei der Darstellung mit relabise sebst etwas grübeln muss.

Und ebenfalls gut, woran ich hier erinnern will, WT Dokumente lassen sich beliebig oft "aus dem Browser" in den SGML Editor imporieren und wieder zurück "in den Browser" schreiben. Alle html und non-html Elemente und Attribute bleiben hinzus und rückzus erhalten.

Nun das Modell

I23ABC I23ABCa+ table in div I23ABCa I23a, ABCa+ tr, tr in table I23atdatd in tr tda ha, (%s.zz;)* td ABCa tdaa* td in tr tdaa I23ABCb* table in td I23ABCb I23b, ABCb+ tr, tr in table I23btdbtd in tr tdb hb, (%s.zz;)* td ABCbtdbb* td in tr tdbbI23ABCc* table in td I23ABCc I23c, ABCc+ tr, tr in table I23ctdctd in tr tdc hc, (%s.zz;)* td ABCctdcc* td in tr tdccI23ABCd* table in td I23ABCd I23d, ABCd+ tr, tr in table I23dtddtd in tr tdd hd, (%s.zz;)* td ABCdtddd* td in tr tdddI23ABCe* table in td I23ABCe I23e tr I23etde* td tde he, (%s.zz;)* td

<!-- TabAbisE vielleicht aus historischem Interesse rein -->

I23ABCa, I23ABCb, I23ABCc, I23ABCd und I23ABCe sind Tabellen.

I23a ABCa, I23b ABCb, I23c ABCc, I23d ABCd sind übereinanderstehende Reihenpaare.

I23e ist eine einzelne Reihe.

tda tdaa, tdb tdbb, tdc tdcc, tdd tddd sind übereinanderstehende Zellenpaare.

tde ist eine einzelne Zelle.

Eine Strukturstufe umfasst jeweils fünf Elemente, die I12ABCx-Tabelle, die beiden Reihen und die beiden Zellen. Die Reihennamen leiten sich aus den beiden Hälften des Tabellennamens I23 und ABC mit dem jeweiligen Kürzel für x: a bis e ab. Und die zu ihnen gehörigen Zellen bekommen von html das td und die angehängten Kürzel a für die obere und aa für die untere Zelle, b für die obere, bb die untere usw.

Meine Phantasie hat bisher daran versagt, für I23ABC eine passende Darstellung zu finden. Ein Blick in die auf 25% verkleinerte Strukturansicht von einem Ausschnitt am Ende von I23ABC der obigen Darstellung von relabise zeigt ein nicht sehr einladendes Bild.

Eines zeigt das Bild aber in aller Deutlichkeit: Hier wäre verrückt, wer ein solches Dokument allein mit einem Texteditor strukturieren wollte. Selbst die Hilfestellung des Parsers in der SGML Umgebung und die Möglichkeit meines SGML Editors, bei der Eingabe eines root element beliebig viele untergeordnete Elemente automatisch einfügen zu lassen, erfordern dennoch die ganze Konzentration und ist von vielen Irrtümern des Autors begleitet, obwohl die Gerüste der besprochenen Modelle stets nur aus zwei drei oder vier Elementen bestehen, die in allen Stufen wiederkehren.

Auch ein vergrößerter Ausschnitt mit erkennbaren Elementnamen trägt nicht viel zur Anregung der Phantasie bei.

Aber wenn das Übereinander das Nebeneinander richtig darstellt, sollte dann nicht das Nebeneinander das richtige Modell zur Darstellung des Übereinander sein?

Gesagt, getan. Ich nehmen relabise und gebe seinen Textzellen die Namen der I23ABC Elemente. Zwar ist es immer noch eine Herausforderung, die Darstellung zu verstehen, aber sie kommt der Absicht scFür die Darstellung der fünf Stufen von I23ABCa bis e musste relabise auf 12 oder 13 Stufen bis papn und mamn vertieft werden! Wie alle a bis e Modelle ist es ursprünglich nur für fünf Stufen gedacht.hon recht nahe.

I12ABCa ABCa tdaa I23ABCb ABCb tdbb I12ABCc ABCc tdcc I23ABCd ABCd tddd I23ABCe ABCe tdee I23e tde I23e tdd I23c tdc I23b tdb 123a tda

Mit dem Nebeneinander von relabise wird das Untereinander von I23ABC richtig dargestellt.

Die Tabelle aus fünf Elementen ist in der ersten Stufe

I23ABCa

I23a tda

ABCa tdaa

Jede Tabelle I23ABCa bis I23ABCe besteht aus zwei Reihen I23a, ABCa bis I23e, ABCe, die alle je eine Zelle enthalten tda, tdaa bis tde, tdee. Die Reihen I23a ABCa sind untereinander wie ihre zugehörigen Zellen tda tdaa. Ebenso bei den anderen.

Der einzige Schönheitsfehler ist, dass die Reihen von unten nach oben dargestellt werden, aber von oben nach unten »gemeint« sind. Aber man kann es auch so lesen, dass die da unten ohne uns hier oben nichts sind.

Topics

Die Topics werden in der general.dtd besprochen.

topa%m.top; 46 Topic a neu am 12.01.2010 topb%m.top; topb 47 Topic b topc%m.top; topc 47 Topic c topd%m.top; topd 47 Topic d tope%m.top; tope 47 Topic b toph%m.ph; 50 Topic heading
Menüs im Fließtext analog Topics

Die Menüs sind genauso strukturiert wie die topics, werden aber in CSS als strukturierte Inhaltsmenüs mit fester Breite und float: left gestaltet, so dass mehrere strukturierte Inhaltsmenüspalten nebeneinander Platz haben. Ein Beispiel dafür ist das Inhaltsverzeichnis des ersten Bands des "Kapital" von Karl Marx. Diese Menüs lassen sich auch ohne SGML Editor im html code relativ leicht mit dem contabise attribute des div element anlegen.

conta%contentsContent; content a contb%contentsContent; contb content b contc%contentsContent; contc content c contd%contentsContent; contd content d conte%contentsContent; conte content e conth %m.ph; content heading
Elements in Sections or Paragraphs address aline+ 51 aline%m.ph; 52 Address line

defs ist ein vereinfachtes Definitionslistenmodell.

defsdef+Die dl wird nach Umwandlung aller bisherigen dl in defs überflüssig; 21.10.2012, 10.08.2017 im Gegenteil, die dl wird wieder in ihren Ursprungszustand versetzt, und defs ist die Definitionslistensammlung, siehe SGML. def dh, dd? dh %m.ph; 19.3.15 Aendere (dnum?, dnam)|(dnam, dnum?) in prozent_phraseContent_strichpunkt artwork|dropart|gleichung EMPTY53 In artwork wird nur der Wert des src Attributs der Grafik oder der Gleichung für den HTML Export eingegeben, dropart ist ein Grafikelement zur Anzeige und Bearbeitung in FM. Ebenso gleichung.

Ähnlich wie die container aus den obigen relationalen Tabellenmodellen ist artwork nur ein leeres container element, dass erst in dem html browser zu einem Grafikelement wird. Das hängt aber eher mit meiner Unfähigkeit zusammen, das img element aus html in den SGML Editor als Grafik zu importieren. Wird es in den Lese- und Schreibregeln als normales Element gekennzeichnet, funktioniert der Import und Export der Attributwerte problemlos. Wird es dagegen als Grafikelement gekennzeichnet, gelingt mir der Import nicht. Umgekehrt werden von den in FM erstellten Grafiken und Gleichungen Bildschirmabzüge erstellt und im artwork element über src referenziert.

dl(dthd+, ddhd)?, (dt+, dd)* 54 10.08.2017 wieder das Original aus der general.dtd dt %m.ph; 55 Definition term aus general.dtd dthd|ddhd #PCDATA56,57 Heading for dt and dd dd %m.pseq; 58 Definition description dltxt(num?, nam+, txt?)* inline Definitionsliste (im Text) quelle (quellnum?, SPAN?, quellnam+, SPAN?, txt?)* inline Quelle txt %m.ph; inline definition description

Das quelle element hat noch eine Ambiguität, die noch nicht beseitigt ist. Welche?

gl(gt, (gd|gdg))* 59 Glossary list gt #PCDATA60 Glossary term gdg gd+ 61 Glossary definition group gd %m.pseq; 62 Glossary definition %ps.ul.d; (li*), (%ps.ul.d;)* 63 Unit item lists, rekursiv li lip*|%m.p; 64 lip für list paragraph ist entweder das Produkt meines Unvermögens oder des Unvermögens meiner SGML app (Adobe FrameMaker 7.2). Dieses Programm erlaubt kontextabhängige Formatierungen, funktioniert bei mir jedoch bei Listenparagraphen nur, wenn diese keine Attribute haben. Ähnlich an anderen Stellen wie notes, wenn Absatzblöcke eingerückt werden sollen. Das Problem (deines Unvermögens) hast du doch gelöst und mal wieder nicht dokumentiert. Listen listenH?, listen+ Listenbehaelter mit Ueberschrift und grossem Ell. listenH %m.ph; listenH mit kleinem ell macht ein übergeordnetes Element notwendig. listen liste+ listelih, lip*, liste* liste als section, mit ausgiebiger Formatierung in der EDD lih %m.ph;

Bei Listen war ich im Teilungsrausch.

lines%m.pseq; 65 Line elements

lines ist für die Darstellung von ein- und ausgerückten Zeilen, etwa für computer code.

xmp|note|ich|blockCit|blockCitAlt %m.pseq; 67, 10, 66 example, note, meinSenf long quote, long quote alternate 28.10.12, april 2015 nehme die exclusion %i.float; raus Arbeit work ist mein bislang bester Versuch, die Zettelwirtschaft zu beenden, ohne die Zettel zu verlieren. Zwar lasse ich es nach wie vor an der nötigen Disziplin mangeln, in den zu tuenden und getanen Taten in Todo und Notizen Ordnung zu halten, aber nun ist der Fehler immer an Ort und Stelle sichtbar. Und sicher gibt es Menschen, die diese Disziplin aufbringen. Am dankbarsten bin ich für das Element Raus, das auch den Inhalt des Abfalleimers aufbewahrt und die vergeblichen Versuche, ein Archiv zu führen, überflüssig macht (Vielleicht hat mit ja die amtliche Vernichtung meiner beleghaften Vergangenheit von 1952 bis 2012 da ein wenig auf die Sprünge geholfen; man weiß nie wozu eine Zwangsräumung gut ist.). workTagebuch?, Notizen?, Todo?, Raus? Tagebuch HEAD, tagebuch+ Notizen HEAD, notizen+ TodoHEAD, todo+ RausHEAD, raus+

Die vier typischen Notizorte sind das Tagebuch, unzuordenbare Notizen, das Todo und Raus, jeweils für alle laufenden projekte. Ein Tagebuch hat so viele tagebuch Einträge wie die Anzahl der laufenden Projekte. Ebenso die anderen.

tagebuch|raus toph, eintrag+ Ma, Pa, Ka, He, A1, Ph, Me, Tg

Jedes Projekt innerhalb von tagebuch oder raus hat beliebig viele eintrag elements.

eintrag (datum | bekknum)+, (%s.p.d;|%ps.zz;)* (s.p.d|ps.zz)*, damit m.pseq vermieden wird

Ein eintrag besteht aus dem datum der Lokalisierung über das Numerierungselement bekknum innerhalb desProjekts und dem Eintrag selbst.

notizen toph, nichtdrin, drin todotoph, zutun, getan nichtdrin|drin|zutun|getan toph, eintrag+

Die Einträge in notizen und todo werden zweigeteilt in nichtdrin, drin und zutun, getan.

Ein Beispiel einer work element instance ist in...

Paragraphen %s.p.d; %m.p; 68 Paragraphs Tabelle

<!-- Die Tabellenentities für WH und für WT werden in den beiden (vormals calling.) dtds aufgerufen. Sie sind eine eigene kleine app.-->

DtdEdd

<!-- Die DtdEdd entity wird hier deklariert und aufgerufen, weil sie in beiden DTDs dieselbe ist. Sie ist eine eigene app, die in WH, WT und HT gilt und in keinem guten Haushalt fehlen sollte. -->

DtdEdd ..∖DtdEddFm∖DtdEdd.dtd.txt

%DtdEdd;

Phrases, Elements %p.em.ph; %m.ph; 76 Emphasized phrases %p.rf.d; EMPTY79 General references %numnam; %m.ph; Schattenindex phrases. Waren die Autoren von Datenbankanwendungen auf PC Ebene in den Steinzeitjahren von dBase und Clipper für die Erstellung und die Pflege der Relationen selbst verantwortlich, so ist diese lästige Angelegenheit mittlerweile automatisiert. Um ein Stück der alten Freiheit in den neuen Anwendungen wiederzugewinnen, habe ich mir bei meinen kleinen Datenbanken Textfelder als "Schattenindexe" angelegt, mit denen ich händisch die Reihenfolge und die Zuordnung zu einem anderen Index der automatisch generierten Indexe ändern kann, ohne in die automatische Numerierung einzugreifen. So habe ich den Nutzen beider. Dieses Prinzip habe ich auf SGML übertragen, um beispielsweise bei der Kommentierung einer Arbeit eines anderen Autors dessen Originalnumeriering parallel zu der automatisch generierten Numerierung meines Kommentars zu haben. Damit entfallen die meisten Quellenangaben, weil nur einmalig auf die Rolle der Originalnumerierung verwiesen werden muss und dennoch Leser und Autor in jedem Moment die Quelle vor Augen haben. Mehr und mehr verzichte ich unabhängig davon auf die automatische Numerierung und arbeite nur noch mit den num nam Pärchen. Includable Subelements figfigbody, (figcap, figdesc?)? %i.float; 80 figbody %m.pseq; 81 Figure body figcap %m.ph; 82 Figure caption figdesc %m.ph; 83 Figure description fn ((%s.p.d;)|(%m.ph;))* %i.float; 84 Footnote jan 2016 gebe fn s.p.d|m.ph ix|aix|tix|mix|Hypertext #PCDATA85 Index entry, autoren, themen, meine Die inclusions von figures und footnotes sind für Autoren unverzichtbar, für Programmierer ein Alptraum. Wer hier den kleinen Finger reicht, landet bei DML. Dagegen scheinen die inclusions von Indexelementen überflüssig, weil sie sich wie das a element aus html keinerlei Regeln unterwerfen lassen und darüber hinaus in einer nicht-Element Umgebung besser funktionieren. Da ich aber über zu wenig Erfahrungen in der Indexerstellung verfüge, bin ich hier noch zu keinem abschließenden Urteil gelangt.