WHSD ist die zweite WHHT app, die Vereinigung zweier ganzer Dokumententypen unter dem Dokumentenelement html.
Nachdem ich vor einigen Tagen einen weiteren Leckerbissen von FrameMaker,
Dass das nicht ganz ernst gemeint ist, siehst du daran, dass der Wust von Arrtibuten in den coreattrs auf die vier aus HT reduziert wurde. Aber da der Daumenkinoprogrammierer nun eine echte DTD vor sich hat, die nicht mit "categories" hochstapelt, sondern parameter entities hat, bei denen nur an einer Stelle Attributdeklarationen gemacht werden müssen, um überall zu gelten, kann er das schnell ändern. Bei dem Rest muss er sich an SGML anpassen, wenn er bei den großen Jungs mitspielen will.
Ähnlich wie bei WHHT waren einige Vorüberlegungen notwendig (siehe dort). Sollte eine zweite entity Vereinigung aus der Sammlung der entities von SDML und WH erfolgen? Das wäre nicht nur eine Riesenarbeit, sondern auch falsch gewesen. Nein, die DMLer mussten – bei mir jedenfalls – zu ihren Wurzeln zurückkehren und sich in das HT der WHHT integrieren, so dass die app auch WHHT.2 heißen könnte, aber bei WHSD ist der Zweck der Vereinigung von WH und SDML deutlicher im Namen zu erkennen als bei WHHT die Vereinigung von WH mit HT. Praktisch bedeutet das, dass die nicht in HT vorhandenen SDML Elemente in rumpfHT integriert wurden, die nun rumpfSD heißt, dass sie in den Standard Attributen coreattrs nicht mehr als in HT gekriegt haben und nur die einzeln bei den Elementen deklarierten Attribute nach WHSD mitnehmen durften. Dabei konnten einige Fehler von SDML korrigiert werden, wie die Nicht-Aufnahme der neuen Formularelemente in die formctrl entity, die bei den DMLern “Kategorien” mit “Interactive content” heißen. Durch die Nichtaufname hatten diese Formularelemente keinen nur ihnen gehörigen Ort in der Logik des Dokumententyps, sondern sind im Entity Brei Flow geschwommen, der das ganze Dokument umfassst.
Die beiden ../WHHT/rumpfWH und ../WHWT/dtd.html bleiben an ihren ursprünglichen Orten in WHHT und WHWT, weil sich an der WH app nichts ändert.
Änderungen sind in treiberWHSD und ../HT/rumpfSD (die vormaligen treiberWHHT und rumpfHT). Deren Änderungen im Vergleich zur ersten WHHT app werden dort dokumentiert.
Ein Problem hat der “Staubsauger” (SDML). Die markup minimization ist in allen apps von SGML2 abgeschafft, auch in SDML. Aber viele alte HTML Dokumente sind mit ihr ebenso verseucht wie mit FONT und Co. Ganz zu schweigen von den DMLern, die diese ranzige Soße wieder aufgewärmt haben. Ohne markup minimization kann der Parser gar nicht anders, als beim Import die Paragraphen in einer Endlosrekursion ineinanderzuschachteln, weil sie keinen end-tag haben, so dass der p im p im p im p … ist. Es müsste also gelingen, die minimization für den Import der Altware anzuknipsen, damit die Paragraphen hintereinander stehen. Das Anknipsen der minimization in der SGML declaration genügt nicht, da beschwert sich der parser beim Import nur, dass die erforderliche minimization information fehlt. Es musste also die DTD wieder mit - O, O O, O -, - -, verseucht werden!
Bei der Benziger Bros. edition, 1947 der Summa Theologica von Thomas von Aquin, die vollständig minimization verseucht ist, habe ich mir vor dem SDML Import so beholfen, dass ich mit dem Texteditor jedes Auftreten von <p> ersetzt habe durch </p><p>, oder von <center> mit </center><center>, ebenso bei </font>, so dass vor jedem Paragraphenanfang der vermutete vorherige Paragraph, das vorherige center, das vorherige font beendet wird. Das hat die Nachbearbeitung nach dem Import auf ein Minimum reduziert. Als Andenken daran steht dort vor vielen Absätzen der tagc delimiter >. Grund: Das vermutete </p> ist in vielen Fällen falsch. Den Anfang des end-tags mit dem etago delimiter </ mit p ignoriert der Parser, den tagc delimiter > stellt er als Zeichen dar, weil aus seiner Sicht kein offenes Element geschlossen wurde.
Ein weiteres Problem: Die WHSD lässt sich nicht als Erst-Staubsauger verwenden, sondern nur die SDML allein. Danach können die WHSD Elemente in das SDML Dokument importiert werden, so dass dann auch der Export und Import gelingt. Grund: Bereits HT hat eine gewisse Strenge, obwohl im body nahezu Alles erlaubt ist. Die Zusammenfügung von WH und SD(ML) macht aus WHSD eine DTD mit element content, also noch strenger. Die Chaotik, in der die alten Dokumente aus den 90er Jahren geschrieben sind, lässt sich nur mit der chaotischen Flow entity, pardon category, nachbilden, die sich in WHSD der ps.zz entity zu fügen hat. Aber die mit SDML aufgesaugten Dokumente können die Elemente von WHSD importieren, und müssen dann nachbearbeitet werden. Vielleicht erstelle ich auch mal eine minization verseuchte app? Eher nicht. Von wegen, unmittelbar danach habichs getan. Ich habe DtdEdd mit einem minimize element versehen und SDML verseucht und die minimization in der sgmldecl eingeknipst – mit dem Erfolg, dass die Paragraphen weiterhin endlosrekursiv importiert wurden und ich zwei Tage vertrödelt habe. Der Thomas ist dran schuld! Ich habe die verseuchte DTD als Andenken aufgehoben und die minimization schleunigst wieder rückgängig gemacht, habe aber das minimize element in der DtdEdd stehengelassen. Man weiß ja nie. Ich habe übrigens auch den Thomas wieder in die reine Staubsauger app gestellt und nicht in der WHSD app gelassen. Aber die Hinweise auf die WHSD in den Fußzeilen der Dokumente habe ich stehengelassen. Man weiß ja nie.
Die Namen der entities sind in WHHT und WHSD dieselben, nur haben sie oft andere Inhalte (entity texts). Die Spalte AAP Lists habe ich der AAP app (Association of American Publishers) übernommen, einer der ersten SGML apps. In ihr steht eine kurze Erläuterung der entities. Die Nummern verweisen auf die entities in der general.dtd. Die Entity Sammlung und -Namen sind in der AAP Anwendung dieselben wie in GE. HT hat auch eine Stufenfolge. So setzt sich inline aus fontstyle, phrase, font und formctrl zusammen und block aus heading, list und preformatted, die hier nicht aufgeführt ist. Flow bzw flow in DML und HT sind die obersten entities wie in GE. Nur setzt sich flow aus HT aus block und inline zusammen, während Flow in DML alle Elemente "ausmultipliziert" sein müssen, weil dort keine entities zur Verfügung stehen, die mehrere Elemente zu Einheiten zusammenfassen. Die Flow entity, pardon category als body content, qualifiziert DML genau wie HT mit mixed content im body als Staubsauger. Nur kommen hier auch alle Veteranen wie font oder center hinzu. Die vollständige Liste sieht so aus:
| special "a | applet | br | wbr | script | template | source | map | q | sup | sub | font | basefont" | |||
Die beiden entities rumpfWH und rumpfSD rufen die beiden Rümpfe von rumpfWH und rumpfSD auf. Die rumpfWH ist dieselbe wie in WHHT. Sie besteht nur aus wenigen Deklarationen, da der Großteil der Elemente mit WHWT identisch ist, die als externe entity aufgerufen wird. Dagegen ist rumpfSD eine Revision der bisherigen HT DTDs auf Grundlage der rumpfHT aus WHHT. Da sich die Deklaration auf die references der entities hinter dem Rücken des html Nutzers abspielen und alle html Elemente in ihrer bisherigen Form erhalten bleiben, kann jeder, der html kann, auch WHSD-html. Frage mich niemand nach dem Sinn des meter element oder anderer DMLer, ich deklariere nur aus Vergnügen.
Für alte html und xml Dateien gibt es mittlerweile drei Staubsauger apps.
Die aus WHATWG html5 entstandene SDML ist am leichtesten zu handhaben.
Hier müssen die Dateien vor dem Import wie bei allen Staubsaugern
nur den richtigen DOCTYPE mit lokalem Pfad der DTD bekommen.
In den xml Dateien beim WHHT Import müssen die non-html Elemente und Attribute in WH Elemente und Attribute umbenannt werden. Beispiel: die Lutherbibel hatte div1 bis div3 mit h1 bis h3, die in parta bis partc mit ha bis hc umbenannt worden sind. Oder Attributwerte wie 3Paul mussten in iiiPaul geändert werden, weil 3 kein name start character ist. Da xml bodies in der Regel element content haben, muss im body nichts geändert werden. Die nicht umbenannten und nicht in der DTD vorhandenen Elemente und Attribute ignoriert der SGML Parser beim Import. Der xml Import ist ein lohnender Einsatz, weil die meisten xml Dokumente ein Mix aus html und non-html Elementen sind, der die Träume des W3C, das SGML für das WWW zu schaffen, nicht verwirklichen konnte.
Die zuletzt (Stand 2021) entstandene WHSD muss vor dem Import den body zu element content machen, indem sie alle <body> in <div><body> und alle </body> in </div></body> umwandelt. Bei ihr bin ich mir noch nicht sicher, ob es ein totgeborenes Kind ist oder nicht. Ihr Vorteil ist sicher, dass sie alle html Elemente hat.
Bei WHHT und WHSD ist zu sehen, dass viele Doppeldeklarationen sind. Wenn ich genügend Erfahrungen mit den drei Staubsaugern gemacht habe, wird es sicher nur noch eine app zum Saugen geben, oder wenigstens die Wiedervereinigung von WHHT und WHSD. Zuerst hatte ich nämlich einfach in WHHT die fehlenden SD Elemente reindeklariert, bin aber dann durcheinandergeraten, so das ich WHHT und WHSD erstmal wieder getrennt habe.