<!-- Die WT Art -->

<!-- Waren früher WH und HT zwei Dokumententypen, die nichts miteinander zu tun hatten, so teilen sich WH und ein minimiertes HT namens WT nun die Masse der ursprünglichen WH, die WHWT heißt.

WT ist die Zusammenfassung von WH und HT zu WT. WT ist ein minimiertes HT, das sich nahezu des gesamten Dokumenteninhalts einer WH.dtd bemächtigt und ihn sich samt dessen frontm, parta und backm (oder wie immer seine ersten Elemente heißen) in seinen body einverleibt.

Die Dokumentation der DTD und die DTD sind dasselbe vorliegende Dokument. Diese Datei als WT.txt gespeichert ist die DTD für die WT Anwendungen.

Eine WT app (und in der Folge auch die früher monolithische WH) besteht aus zwei (05/2021 drei) DTDs, eine kurze "Treiber DTD", (05/2021 die vorliegende WT.html/txt) und die für WH und WT gemeinsame WHWT.dtd, in der die Masse des Inhalts steht.

Das vorliegende Dokument enthält die ersten im Ausgust 2017 entstandenen Deklarationen der Treiber-DTD einer WT, mit der echtes SGML für das Netz geschrieben wird. Sie ist länger als die WH.dtd, der WH-Treiber, weil sich WH nur seine von ihm abgetrennten Elemente wiederholt und weil der html Teil, der die Führung über den docContent von WH als BodyContent übernehmen soll, teilweise neu deklariert werden muss, teilweise aus html übernommen wird. Für einen solchen Treiber gibt es noch keine Vorlagen. Seine html Teile kommen aus html4.

WT Dokumente sind für alle Dokumente gut, die die Vorteile von reinen SGML Dokumenten mit den Vorteilen von reinen HTML Dokumenten kombinieren sollen. Da ihre Entdekkung noch relativ jung ist, ist ihr Einsatzbereich noch nicht recht absehbar, wird aber wohl einlösen, was sich die Autoren von XML seinerzeit vorgenommen hatten.Die Entdeckung von WT hat in kurzer Frist eine Reihe weiterer Entdeckungen nach sich gezogen, die derzeit lose in Part A gesammelt sind, wie die app WHHT, in der html nicht die Macht über eine WH.DTD übernimmt, sondern in der WH und HT als gleichberechtigte Partner fusionieren. -->

<!-- Der WT body -->

<!-- Der WT body vereinigt die Vorzüge der bodies aus WH und HT. Aus WH bringt er die Fähigkeit, frontmatter, parta, backmatter nacheinander auftreten zu lassen, aus HT die Fähigkeit, dies in beliebiger Anzahl und Folge zu tun. Aus WH bringt er die sicheren Grenzen im Innern. Aus HT die Freiheit, mit a und der URI überall hinzuhüpfen (ab 08.11.2017 kann auch WH a benutzen). Der WT-Typ ist das SGML für das Internet, wie ein Blick in den Quelltext des vorliegenden Dokuments zeigt, das mit WT geschrieben ist. Die Erstellung eines WT Dokumententyps ist die bisher anspuchvollste Herausfoderung an einen DTD-Autor. Einmal weil dieser Dokumententyp erst im August 2017 entdeckt worden ist (vgl. die beiliegenden Tagebuchaufzeichnungen an Anfang der WHWT.dtd) und bisher nur als Unikat vorliegt. Zum anderen weil er intime Kenntnisse von SGML voraussetzt, die sich die Welt erst wieder aneignen muss. Das mit dem Unikat traf schon kurz nach Erstellung der ersten WT app nicht mehr zu. Das vorliegende Dokument beinhaltet bereits drei verschiedene WT DTDs.-->

<!-- Die WT DTDs -->

<!-- Da WT die Besitzergreifung einer DTD durch eine andere ist, bestand sie wie WH aus zwei DTD-Teilen, die aber nicht wie die beiden Teile von WH die zuvor getrennten Teile desselben Dokumententyps sind, sondern Teile zweier verschiedener Dokumententypen, von denen Teile des einen, der WH Kopf und body, weichen müssen.

Das minimierte html besteht aus dem document element html, dem head und body und einigen anderen html Elementen. Dazu kommt der bodylose Rumpfinhalt"Rumpf", weil sich in ihm auch die frontm und die backm befinden, die in einer WH vor und hinter deren body stehen, während sie in WT Teile des WT body sind. der WH.dtd. Und fertig ist WT.

Das document element der ursprünglichen whole.dtd hat WT einfach abgetrennt und den body ausgegliedert, sich sich an deren Stelle gesetzt und kann nun verkünden: "Ich bin das SGML für das WWW!" Denn die gleiche Methode des Köpfenwechselns und Bodyaufsaugens ist mit beliebigen SGML.dtds möglich, ein unblutiger Robespierre (head) und Dracula (body).

Mit demselben Recht kann aber der alte WH-Kopf WT köpfen und mit seinem body wieder seinen eigenen Rumpf umschließen und sagen: "Ich bin das Ganze!", weil er dann wieder die ursprüngliche whole.dtd ist.

Die beiden "Treiber.dtds" (vgl. Maler/Andaloussi C.2.1 Main DTD Files, S. 438) sind kurz und bei WH sogar sehr kurz, weil es nur das vorübergehend ausgegliederte document element und das body element der whole.dtd sind, während der HT-head und sein body ein wenig mehr auf den WH-Körperinhalt einwirken müssen, um eine gute Figur abzugeben.

Der Hauptinhalt der Menge nach ist der Körperinhalt der whole.dtd, der den beiden Treibern (WH und WT) gemeinsam ist. Und der ist wiegesagt weitgehend der general.dtd aus dem Standard SGML entnommen. Jedes Element und jede entity, die der general.dtd entnommen sind, verweisen mit einem a element auf die Quelle.

Die WT.dtd enthält nur die Teile 3 und 4 aus dem unten gezeigten Gebilde, dem Teil, der nur für WT gilt und dem, der in HT und WT gilt und eine Referenz auf den Teil 2. Es handelt sich bei allen Teilen von 3 und 4 um html Elemente, aber der WT body und einige entities unterscheiden sich von den entsprechenden Deklarationen in HT. -->

<!-- Physischer Zusammenhang der WH, HT, WT. -->

<!-- Man kann WT so betrachten, dass aus WH und HT ein Drittes wird, eben WT.

kein bild

Diese Darstellung ist zwar richtig und trifft auch für WH und HT physisch zu, weil WH und HT keinen Teil gemeinsam haben, sie ist aber ungenau, weil WH, WT und HT nicht drei Getrennte sind, sondern sich teilweise überschneiden, teilweise getrennt sind.Juni 2021 Was mir bei der Erstellung des Bildes vorgeschwebt hat, wird erst in der vierten WT app verwirklicht werden, die dann auch passend zum Bild WHHT heißen wird.

WH und WT, sowie WT und HT bilden die beiden echten Teilmengen 2 und 4 (»Durchschnitte«), die die Teile 1, 2, 3 und 4 und die Teile 2, 3, 4 und 5 des Gesamtgebildes (»Vereinigungsmenge«) in der unteren Darstellung von WH-WT-HT ausfüllen. Der Teil 3 WT ist der Teil, der weder WH, noch HT ist und der allein zu WT gehört. Während WH und HT aus je zwei Teilen bestehen, besteht WT aus drei Teilen, dem großen Teil 2 von WH, einem kleineren Teil 4 von HT (html, die head elements, a, img und noch einige) und dem Teil 3 WT, der im wesentlichen der neue html body mit WH-Inhalt ist.kein bildDen weitaus größten Teil 2 haben WH und WT gemeinsam, während WH und HT keinen gemeinsamen Teil haben. Dennoch übernehmen die 3 aus WT und ein kleiner Teil von HT 4 die Macht über die 2 von WH, indem sie die 1 von WH abschneiden und sich an deren Stelle setzen. Aber anders, als es die Zeichnung vermuten lässt, ist die kleine grüne 4 der umfangreichste Teil der WT Deklarationen, weil die HT Elemente neu deklariert werden müssen und die bereits deklarierten Elemente der 2 aus WH nur über eine reference auf eine externe entity eingebunden werden.

(30.06.2021 Der Zufall oder wer auch immer hat es gefügt, dass den drei Teilen von WT auch drei DTDs entsprechen, einen 10-zeiligen »Calling-Treiber«, den unten beschriebenen »WT-Treiber« und den WH-Rumpf. Die Dreiteilung wurde erforderlich, nachdem sich mehrere WTs die WT.dtd teilen mussten. Siehe unten, Aufruf der BodyContents der bisherigen drei WTs).

Nun die WT.dtd im Einzelnen. -->

<!-- Der WT Treiber

Die WT.dtd sieht aus wie eine kleine html.dtd, ist aber ein Pirat, der jeden SGML document type kapern und unter seiner Flagge ins Netz stellen kann. Um als html auftreten zu können, sind html, die head Elemente und body zwingend erforderlich.

Im Innern sind das a Element, img, div, ein geeignetes Tabellenmodell sowie einige inline Elemente das Minimum. Je weniger Entities, Elemente und Attribute aus HT zu verwalten sind, desto einfacher der Kaperungsmechanismus.

Die Reihenfolge und Strukturierung der Deklarationen hier und in der WT.dtd entspricht der zum Zeitpunkt ihrer Entdeckung.

Nun beginnt die DTD.

Entities --> local.ps.elem |TURBLE|div|img|map|br 8

<!-- Wird der WHWT Teil hier aufgerufen, müssen in der dort leeren local.ps.elem einige Elemente aus HT stehen, mit denen WHWT nichts anfangen kann. Sie werden daher hier als "locals" deklariert und ersetzen die von WHWT, weil sie hier zuerst deklariert sind und immer die entity siegt, die zuerst dran war. Sollte man in WT Sehnsucht etwa nach dem Element br bekommen, so kann man es hier in die "locals" eintragen und hier deklarieren. WT apps, die die local.ps.elem nicht benötigen wie ElemKat ignoriert sie, weil sie selbst keine eigenen "locals" hat. -->

<!-- Aufruf der BodyContents der bisherigen drei WTs

Mit dem Inhalt des body einer WH DTD macht sich eine WT app zum SGML für das WEB. WTs body selbst ist der HT body in neuer Form. Er hat nun nicht mehr wie früher mixed content, sondern element content, nämlich die obersten body elements der gekaperten WH DTD.

Es folgen die drei bodyContents der bisher erstellten WTs, nämlich die zuerst erstellte WT selbst (WH+HT), dann die ElemKat799 (WT+ der Elementkatalog von FrameMaker) und DtdEdd (WT+ die DTD zum Schreiben von DTDs und Standards). Sie stehen in marked sections, deren Inhalt von den jeweiligen mini-Treibern mit Hilfe des status keywords IGNORE oder INCLUDE übernommen werden oder nicht. -->

WT bodyContent ..∖WHWTFm∖WHWT.dtd entities, elementes und attributes, die wh und wt gemeinsam haben. ElemKat799 bodyContent ..∖ElemKat799Fm∖dtd.txt entities, elementes und attributes, die ElemKat799 und driverdtd gemeinsam haben. DtdEdd bodyContent ..∖DTFm∖DTD.txt entities, elementes und attributes, die DtdEdd und driverdtd gemeinsam haben. Das ist in diesem Fall die gesamte DTD von DtdEdd. %bodyContent;

<!-- Der WT mini-Treiber, die dritte DTD der WT app, verdeutlicht den Gebrauch der marked sections. Er schließt nur die WT Teile ein und die Teile der beiden anderen apps aus. Anschließend deklariert er die externe entity des vorliegenden Dokuments und ruft sie auf. Die Treiber von ElemKat799 und DtdEdd sind analog mit dem INCLUDE und IGNORE an den passenden Stellen, so dass gewährleistet ist, dass der bodyContent über diesem Absatz den richtigen Inhalt hat.-->

<!--Entitäten und einige Elemente aus der HT.dtd Character Entity Sets aus isoall juli 2018

12.7.18 Die tutorial application isoall ist Teil von Part D von SGML2. Die aus ihr entnommene isoall.ent macht die drei character entity sets von HTML 4 überflüssig.-->

isoall C:∖e∖c∖apps∖isoallFm∖isoall.ent %isoall;

<!−− Γριϵχηισχη ωιρδ αβ ϕϵτζτ μιτ ΦμΣψμβoλ γϵσχηριϵβϵν, κψριλλισχη ιστ ϵτωασ υμστäνδλιχηϵρ. −−>

<!-- Generic Attributes aus HT

Die wichtigsten Attribute aus HT gelten auch in WT. -->

coreattrs id ID #IMPLIED -- document-wide unique id -- class CDATA #IMPLIED -- space-separated list of classes -- style CDATA #IMPLIED -- associated style info -- title CDATA #IMPLIED -- advisory title -- i18n i18n steht für internationalization, das aus 18+2 Buchstaben (i und n) besteht. lang CDATA #IMPLIED -- language code -- dir (ltr|rtl) #IMPLIED -- direction for weak/neutral text -- attrs %coreattrs; %i18n; Die attrs werden wegen dir in den tables von WT und HT benötigt. align align (left|center|right|justify) #IMPLIED default is left for ltr paragraphs, right for rtl. Die entity align ist nicht in der strict.dtd. Ich will nicht auf sie verzichten, um Ausnahmen der CSS Formatierungen zu erlauben, die mir aber auch bei der Arbeit mit SGML und beim Import älterer html Dateien fehlen.
<!-- Document Head Entity aus HT

Der HT head wird unverändert nach WT übernommen. -->

head.misc script|style|meta|link|object repeatable head elements
<!-- Formatierungsattribute aus HT, die müssen dieselben Werte bekommen (immer aus HT kopieren!).

Die Formatierungsattribute -->

em em(em | em2 | em3 | em4 | em5 | em6 | em7 | em8 | em9 | em10 | quote | quoteAlt | sub | super | page | emDate | quelle | symbol | dingbats | emTimes | emGrotesk | emKAP | big | small) #IMPLIED Inline-Formatierung, em1 ist eine class, weil der Attributwert aus welchen Gründen auch immer nicht funktioniert. emP emP(em | em1 | em2 | em3 | em4 | em5 | em6 | em7 | em8 | em9 | em10 | quote | quoteAlt | sub | super | symbol | quelle | emTimes | emGrotesk | emKAP | dateP | small) #IMPLIED wie die Inline-Formatierung für Absätze. Beim Paragraphen klappt em1. p p(p | pInline | pSatzspiegel | pSpiegelSteg | pSteg | pSteg8pt | pEingerueckt) #IMPLIED Layout-Formatierung
<!-- Die table entity für WT

Die Tabellen für HT, WT und ElemKat799 sind weitgehend identisch und werden daher mit wenigen marked sections in einer Datei tableWTHT.txt verwaltet. DtdEdd benutzt dasselbe Modell wie ElemKat799 -->

WT HT IGNORE WT INCLUDE ElemKat IGNORE ElemKat799 HT IGNORE WT IGNORE ElemKat INCLUDE DtdEdd HT IGNORE WT IGNORE ElemKat INCLUDE table ..∖table∖tableWTHT.txt mit geändertem content von th/td, m.p statt flow IS NICH WAHR und mit m.ph in den Tabellenzellenelementen statt mit inline. Zwar muss es das Tabellenmodell von HTML sein, aber die Inhalte der Zellen können aus WH kommen. Die entity darf erst hier stehen, weil sie die attrs von html benutzt. %table;
<!-- Das Dokumentenelement aus HT gilt für alle WTs --> docType html 1 Document type generic identifier. This is a document type for a "html" document.

<!-- Hier enden die parameter entities aus HT, weil % block und % flow aus HT durch die WH entities... aus WHWT übernommen werden. -->

<!-- Elements Head Elements aus HT gelten ebenso bei allen WTs. Die head Elemente müssen komplett von HT übernommen werden, wobei script ein politisches Zugeständnis ist. --> head title & base? script|style|meta|link document head title #PCDATA%head.misc; document title base EMPTYThe base element allows authors to specify the document base URL. meta EMPTYgeneric metainformation style CDATAstyle info <!-- The link Element und br

br hat sich hier reingedrängelt, weil es in SGML oft vermisst wird. -->

link EMPTYa media-independent link br EMPTYforced line break br %coreattrs; id, class, style, title
<!-- Script Elemente aus HT --> script CDATA noscript link*|style*|meta*|(#PCDATA) <![ %WT; [ <!-- Document Structure von WT

Datum der Entdeckung: 31.07.2017 WT simuliert HTML, indem es die Elemente html, head und body an die Stelle von whole und BODY setzt. -->

%docType; head, bodyix | aix | tix | mix | Hypertext | %i.float; html mit head und body. attlist steht nach der declaration von coreattrs.

<!-- Mit WT kann ein HT body zum Träger der frontm, der body Elemente und der backm einer WH DTD werden, nur nicht nacheinander, sondern durcheinander. Da aber jedes Durcheinander sich in ein Nacheinander auflöst, bleibt sich das gleich. Der body eines WT Dokuments hat also den gleichen Inhalt wie das document element einer WH. Nur erscheint der body nicht mehr zwischen frontm und backm, sondern frontm und backm, sowie parta | partb | part |div treten in beliebiger Anzahl und Reihenfolge in ihm auf.

In einem WT Dokument tritt der HT body erstmals als element content auf und bekommt dadurch "sichere Grenzen im Inneren". Beim Druck auf die Ende Taste fliegt man nicht mehr aus dem Element hinaus, sondern kommt ans Ende des Elements. -->

body (parta | partb | part | appendix | backm | frontm | div)* a

<!-- Obwohl das div Element in einer WT nicht unbedingt erforderlich ist, vermisst man es schnell in den HT Teilen, die sich nicht an die parta bis parte halten wollen. Vermisst ist zu wenig, das div ist in diesem Fall die Minimalanforderung, damit der body element content hat.-->

div %m.pseq;

<!-- Ursprünglich stand hier das a Element. Aber da dies 2017 auch in den WH DTDs steht, ist es hier nicht mehr erforderlich. -->

]]>

<![ %ElemKat799; [ <!-- Document Structure von ElemKat799

24.06.2018 Elementkatalog simuliert HTML, indem es die Elemente html, head und body an die Stelle von Elementkatalog setzt. -->

%docType; head, bodyhtml mit head und body. attlist steht nach der declaration von coreattrs. body Elementkatalog* a | TURBLE | img | div | map 22 Der body von edd799 hat element content. Er besteht nur aus dem Elementkatalog, der beliebig häufig auftreten kann. Der Elementkatalog bleibt durch die fünf inclusions als "Monolith" erhalten und kann dennoch an beliebigen Stellen Zusatzinformationen wie Tabellen enthalten. Das heißt, beliebig sind die Stellen nicht, sondern es sind die Stellen, die die separators normalerweise einnehmen. Die TURBLE oder das div können nur zwischen Deklarationen auftreten. div (#PCDATA)*HTML4: generic language/style container SgWhatwgHTML5: If the element is a child of a dl element: one or more dt elements followed by one or more dd elements, optionally intermixed with script-supporting elements. In der Definitionsliste hat das div nichts verloren! Nachdem die Autoren etliche überflüssige divs eingeführt haben, ist es nur konsequent, das div selbst überflüssig zu machen.
<![ %DtdEdd; [ <!-- Document Structure von DtdEdd

29.06.2018 DtdEdd simuliert HTML, indem es die Elemente html, head und body an die Stelle von DtdEdd setzt. -->

%docType; head, bodyhtml mit head und body aus HT. attlist steht nach der declaration von coreattrs. body DtdEdd*a | TURBLE | img | div | map | p | lip | pre 22 Der body von DtdEdd besteht im wesentlichen aus sich selbst. Einige Elemente aus HT und anderswoher werden als inclusion erlaubt, um DtdEdd dokumentieren zu können. div(#PCDATA)* HTML4: generic language/style container SgWhatwgHTML5: If the element is a child of a dl element: one or more dt elements followed by one or more dd elements, optionally intermixed with script-supporting elements. In der Definitionsliste hat das div nichts verloren! Nachdem die Autoren etliche überflüssige divs eingeführt haben, ist es nur konsequent, das div selbst überflüssig zu machen.

<!-- Hier begann die größte (achtseitige) marked section, die für WH und WT gilt, als WH und WT noch in einem Dkument mit marked sections verwaltet wurden. August 2017 nenne sie WHWT bei der Trennung von WH und WT --> ]]>

<![ %ElemKat799; [ <!-- Hyperlinks aus HT --> a(#PCDATA)* ain ElemKat799 erforderlich, da kein WH im body a anchor %coreattrs; charset char encoding of linked resource type advisory content type name named link end, zwar "erlaubt", aber NICHT in SgWhatwg und HTML5. Web developers can use the id attribute instead, heißt es in Differences from HTML4.htm href URI for linked resource hreflang language code rel forward link types rev reverse link types accesskey accessibility key character shape(rect|circle|poly|default) for use with client-side image maps coords for use with client-side image maps tabindex position in tabbing order onfocus the element got the focus onblur the element lost the focus

]]>

<![ %DtdEdd; [ <!-- Hyperlinks aus HT --> a (#PCDATA)* ain DtdEdd erforderlich, da kein WHi m body a anchor %coreattrs; charset char encoding of linked resource type advisory content type name named link end, zwar "erlaubt", aber NICHT in SgWhatwg und HTML5. Web developers can use the id attribute instead, heißt es in Differences from HTML4.htm href URI for linked resource hreflang language code rel forward link types rev reverse link types accesskey accessibility key character shape(rect|circle|poly|default) for use with client-side image maps coords for use with client-side image maps tabindex position in tabbing order onfocus the element got the focus onblur the element lost the focus

]]>

<!-- img

Das img Element ist im SGML Editor leer im doppelten Sinn. Einmal hat es den declared content EMPTY. Zum anderen zeigt es keine Grafik an, sondern ist nur der Träger der Grafikattribute wie src, die erst im Browser als Grafik angezeigt werden. -->

img EMPTY
<!-- Client-side image maps

map habe ich wegen meiner "Pyramiden" liebgewonnen. Es ist für eine WT nicht erforderlich. -->

map (area)+client-side image map map %attrs; %coreattrs, %i18n, %events name CDATA for reference by usemap area EMPTYclient-side image map area area %attrs; %coreattrs, %i18n, %events shape rect controls interpretation of coords coords comma-separated list of lengths href URI for linked resource nohref (nohref) this region has no action alt short description tabindex position in tabbing order accesskey accessibility key character target newfür maps in iframes Dezember 2018
<![ %DtdEdd; [ <!-- Elemente und Attribute aus sonstwoher --> p | lip | pre #PCDATA p | pre %em; Formatierungsattribute in HT %p; legt den Ort des Absatzes fest, ist in den Tabellenelementen überflüssig und nur für p gedacht %emP; wie % em für Ps, erlaubt verschieden formatierte Absätze

]]>

<!-- Attributes document type --> %docType; %i18n; <!-- head --> head | title | noscript %coreattrs; base %coreattrs; href Document base URL target Default browsing context for hyperlink navigation and form submission meta %coreattrs; ich brauche auch charset in meta http-equiv HTTP response header name name Metadata name content Value of the element charset Character encoding declaration style %coreattrs; Global attributes type content type of style language media designed for use with these media link %coreattrs; charset char encoding of linked resource href URI for linked resource hreflang language code type advisory content type rel forward link types rev reverse link types media for rendering on these media <!-- body

Die Tabellengefüge relabise und entabise aus WHWT, die in SGML2 oft zur Illustration der entity structure und der element structure verwendet werden, müssen für diese Gegenüberstellung von links nach rechts oder von rechts nach links darstellbar sein. Sie bekommen daher das Attribut dir mit den Werten rtl|ltr aus der internationalization entity i18n von html4. -->

WT script src Address of the resource type Type of embedded resource charset Character encoding of the external script resource defer defer Defer script execution rela|enta %i18n; div %coreattrs; %align; text alignment. align ist nicht in der strict.dtd, sgwhatwg partAbisE (parta | partb | partc | partd | parte) Dokumentenstruktur topAbisE (topa | topb | topc | topd | tope) topics contAbisE (conta | contb | contc | contd | conte) Inhaltsmenüs relAbisE (rela | relb | relc | reld | rele) relationale Verknüpfung Die abise Attribute von div sind aus HT, wo sie dazu dienen, die WH in HT abzubilden. In WT sind sie eigentlich überflüssig, weil hier (auch im Texteditor ohne SGML Editor) mit den abise Elementen gearbeitet werden kann. Das gilt besonders für relabise, das aber im Texteditor ohne Unterstützung des Parsers eine Zumutung ist. Das in HTML3 eingeführte div element ist für das zweite der beiden universellen Strukturelemente geeignet: Jedes element des Ineinander aus einem beliebigen strukturierten Dokument kann in HTML auch mit dem div element ausgedrückt werden, wenn man nicht die Muße hat, den WH content zu studieren. Um die Attribute partAbisE, topAbisE usw. nutzen zu können, sollte man mit deren Inhaltsmodellen aber wenigstens vertraut sein, die in der Dokumentation der WHWT.dtd beschrieben wird. Die div Attribute sind HTML-Abbilder der gleichnamigen Elemente aus der whole.dtd (WH), also des parta Elements, des partb Elements usw. In das class Attribut können Werte wie ich, note, xmp oder lines eingegeben werden, die ebenfalls aus der whole.dtd sind. Das kann auch ohne Umweg über die classes direkt mit parta bis parte gemacht werden. Der html Weg empfiehlt sich bei importierten älteren html Dateien, die man nachträglich strukturieren will. Der direkte Weg empfiehlt sich beim Neuschreiben von parta, partb elements. Die Neueingabe eines relabise in einem Texteditor ohne eine SGML Software ist nur für geübte und ausdauernde und masochistisch veranlagte Anwender und hier mehr für den Import bestehender relabise Dateien gedacht. Aber bei allen AbisEs ist eine Kenntnis der Struktur erforderlich, die in WHWT, teilweise auch in HT bei den abise Attributen erklärt wird. img %coreattrs; Global attributes src URI of image to embed alt short description longdesc link to long description (complements alt) name name of image for scripting height override height width override width usemap use client-side image map ismap ismap use server-side image map align(top|middle|bottom|left|right) vertical or horizontal alignment, nicht in strict.dtd border link border width, nicht in strict.dtd hspace horizontal gutter, nicht in strict.dtd vspace vertical gutter, nicht in strict.dtd