Kategorie-Archiv: Computer

System /370 Modell 145 von IBM

dv008

System /370 Modell 145 von IBM, IBM-Pressefoto (Bookattack Collection)

Literatur:
https://en.wikipedia.org/wiki/IBM_System/370_Model_145
https://de.wikipedia.org/wiki/System/370
https://de.wikipedia.org/wiki/System/360
https://www.arnnet.com.au/slideshow/541873/pictures-mostly-cool-history-ibm-mainframe/

IBM RAMAC 1401

dv009

IBM RAMAC 1401, IBM-Pressefoto (Bookattack Collection)

dv010

IBM RAMAC 1401, IBM-Pressefoto (Bookattack Collection)

Literatur:
https://de.wikipedia.org/wiki/IBM_1401
http://www.computerhistory.org/brochures/doc-437295709c350/
https://de.wikibooks.org/wiki/Computergeschichte:_1900_bis_heute#1959_IBM_1401

Ein IBM-System

dv001

IBM Plattenspeichereinheit 355 zu Magnettrommelrechner Type 650, IBM Pressefoto (Bookattack Collection).

dv003

IBM 650 mit Bändern, IBM Pressefoto (Bookattack Collection).

dv006

Stanzer 537 zu IBM RAMAC 650, IBM Pressefoto (Bookattack Collection).

Big Data mit Lochkarten

„Herman Hollerith schloss sein Studium der Ingenieurwissenschaften an der Columbia University im Alter von 19 Jahren ab und ging als Statistiker zum US-amerikanischen Volkszählungsamt, um die Bevölkerung im Rahmen der Volkszählung 1880 erfassen zu helfen. Die rasch wachsende Bevölkerung des Landes zu zählen und nach Alter, Geschlecht, Rasse und anderen Faktoren zu unterscheiden, war eine frustrierend langsame und kostspielige Aufgabe.
[…] Hollerith wusste sowohl von [Charles] Babbage als auch von [Joseph Marie] Jacquard [Steuerkarte für Webstühle]. Ende des 19. Jahrhunderts wurden die ersten Pianolas populär, die Musik mit Hilfe von Lochmustern spielten …
In Holleriths Konzeption enthielt jede Karte, auf einer Größe von 7 mal 17 cm, die Daten einer Person. Ein Mitarbeiter las die Zensusrollen und stanzte die Angaben der Person in die entsprechende Stelle auf der Karte. Dabei entsprach jedes Loch einer Information, wie dem Alter, dem Familienstand oder dem Einkommen. Der Bediener der Maschine legte die Karte dann in eine Presse ein, die mit der Tabelliermaschine verbunden war, und schloss die Abdeckung. Die Nadeln, die die Löcher abtasteten, berührten zum Teil mit Quecksilber gefüllte Vertiefungen und schlossen dabei einen Stromkreis. Auf diesem Wege wurden elektrische Impulse an die uhrenähnlichen Zählvorrichtungen auf der Maschine übertragen. Wie viele ledige Frauen lebten 1890 in Dover, Delaware? Man legte einen Stapel mit den Karten der Einwohner von Dover in den Hollerith-Kartenleser und die Ergebnisse wurden auf der Zähltafel ausgegeben.“ (aus: „Im Dienst der Welt“, IBM-Pressbooks.com, 2011, S. 23 – 26)

„Über 60 Jahre setzten Unternehmen und Behörden auf Lochkarten, um Informationen zu speichern und wieder abzurufen. […]
Herman Hollerith machte aus gelochten Karten Datenspeichereinheiten […] Ein Loch an einer bestimmten Stelle bedeutete dunkle Haare, an einer anderen männlich oder weiblich. Hollerith stellte fest, dass er auf diese Weise von jedem US-Bürger eine passende >Loch-Fotografie< anfertigen konnte.
[…] Die Karten entwickelten sich weiter und konnten immer mehr Informationen erfassen. Die ersten Versionen hatten 45 Spalten. IBM gelang 1928 ein Durchbruch und es entstanden Karten mit 80 Spalten. Remington Rand konterte mit einer 90-Spalten-Karte […]. Die 90-Spalten-Karte konnte zwar mehr Daten speichern, war aber nicht so einfach zu handhaben wie die 80-Spalten-Karte von IBM.
Immer mehr Behörden stiegen von Akten und handgeschriebenen Büchern auf Lochkarten um. Die Bahnunternehmen waren unter den Ersten, die Informationen zu Wagen, Fracht und Fahrgästen automatisierten. Auch Einzelhändler, wie Marshall Field’s, stellten ihre Lagerbestandshaltung auf das Kartensystem um. Als die US-Regierung die Sozialversicherung einführte, wurden die Karten zum Finanzspeicher des Landes, der alle Lohninformationen der Arbeiter enthielt. Ende der 1930er Jahre hatten sich die Lochkartenmaschinen europaweit ausgebreitet […] 1937 hatte IBM 32 Pressen in Endicott, New York, die zwischen fünf und zehn Millionen Lochkarten täglich druckten, schnitten und stapelten. Die Karten machten in den 1950ern zwei Drittel des Umsatzes von IBM aus.“ (aus: „Im Dienst der Welt“, IBM-Pressbooks.com, 2011, S. 39, 40)

dv004

Lochkarte (Bookattack Collection).

dv005

Lochkarte („Artikel-Stammkarte“) von IBM (Bookattack Collection).

 

SGML Geschichte

Entwicklung und Anwendung von SGML

Die Entwicklung zum Standard

Die Wurzeln der Standard Generalized Markup Lanuage (SGML) begannen bereits in den 1960er Jahren zu wachsen. Die Herren Tunnicliffe und Rice werden als Urväter betrachtet. William Tunnicliffe von der Graphic Communications Association (GCA) hatte 1967 die Idee, die Information eines Dokumentes von der äußeren Form zu trennen. Er stellte seine Gedanken im Oktober des gleichen Jahres während des Treffens der kanadischen „Government Printing Office“ vor. Ebenfalls in den späten 1960er Jahren kam dem New Yorker Buch-Designer Standley Rice die Idee eines universiellen Kataloges von „parameterized editorial structure tags“.

Der Direktor der GCA, Norman Scharpf, erkannte die Bedeutung dieser Ideen und bildete ein Projekt mit dem Namen „generic coding“.

Ebenfalls auf den Ideen von Tunnicliffe und Rice basierte die Forschungsarbeit bei IBM im Jahre 1969 die von Charles F. Goldfarb, Edward Mosher und Raymond Lorie durchgeführt wurde. Aus dieser Arbeit resultierte die „Generalized Markup Lanuage“ (GML). Goldfarb setzte anschließend seine Bemühungen um die Erforschung von Dokumentstrukturen fort und entwickelte Konzepte die später mit in SGML einflossen.

Im Jahre 1978 begann die Entwicklung zu einem Standard. Beim American National Standard Instistute (ANSI) wurde ein Komitee („Computer Languages for the Processing of Text“) gegründet, das von Charles Card und Norman Scharpf geführt wurde. Goldfarb wurde gebeten dem Komitee beizutreten und führte schließlich ein Projekt für einen Textbeschreibungs-sprachenstandard basierend auf GML. Das aus dem „generic coding“-Projekt gebildete „GCA GenCode-„Komitee unterstützte die Bemühungen und stellte einen Kern von Mitarbeitern zusammen, die die Aufgabe hatten Goldfarb´s Basissprache für SGML zu einem Standard zu entwickeln.

Der erste Arbeitsentwurf von SGML wurde 1980 veröffentlicht. Im Jahre 1983 konnte die GCA den sechsten Arbeitsentwurf als Industriestandard (GCA 101-1983) vorstellen. 1984 fand dann eine Neuorganisation des Projektes statt. Die Leitung fand unter der ANSI und der International Organisation for Standardization (ISO) statt. Die sich bildende Arbeitsgruppe, die von James Mason geleitet wurde, nennt sich heute ISO/IEC JTC1/SC18/WG8.

1985 wurde ein Vorschlag für einen internationalen Standard veröffentlicht. Im selben Jahr wurde in Großbritanien die „SGML User´s Group“ von Joan Smith gegründet. Zusammen mit der amerikanischen GCA, spielte diese Gruppe eine wichtige Rolle bei der Schulung der Öffentlichkeit über die SGML.

Buch „SGML für die Praxis“ (1995) von Diplom-Mathematiker Wolfgang Rieger.

Nach einem weiteren Jahr der Kommentierung und Überarbeitung wurde die SGML 1986 als ISO-Norm veröffentlicht (ISO 8879:1986). Eine entsprechende DIN-Norm EN 28 879 erschien im März 1991 unter dem Titel „Textverarbeitung und -kommunikation. Genormte Verallgemeinerte Auszeichnungssprache (SGML) (ISO 8879 : 1986 + A1 : 1988) EN 28 879 : 1990“. Die Norm enhält vor dem ISO-Norm einige Seiten Text in deutsch. Die ISO-Norm erhält als Anhang A eine „Introduction to Generalized Markup“ (Bezug über Beuth Verlag GmbH).

Von vornehmer Zurückhaltung bis zu schroffer Ablehnung

In Deutschland beschäftigte man sich bereits im Frühjahr 1986 bei einem Seminar in Heidelberg mit SGML. Hans-Georg Wenke berichtete in der Fachzeitschrift „Deutscher Drucker“ über dieses Seminar. Er schrieb, daß die Diskussion über Auszeichnungssprachen „schon seit geraumer Zeit im Gange“ sei und beklagte, daß diese Diskussion „außerhalb der drucktechnischen Her-stellungsbetriebe geführt“ würde. Als Erklärung könne man heranziehen, dass

„die Thematik eigentlich ein ureigenes Computer- und/oder Informatik-Problem ist. Doch jetzt, da Satz ein Teil der Informatik wird (oder schon geworden ist), müssen auch wir uns in der Druckindustrie damit beschäftigen – zunächst einmal unabhängig davon, welchen Weg wir einnehmen und welche Entwicklung sich durchsetzen wird.“

In den folgenden Jahren war dies nicht SGML, sondern Desktop Publishing, welches der Druckindustrie, die lang ersehnte Echtdarstellung auf dem Bildschirm (What you see is what you get = WYSIWYG) brachte. Die Setzer wurden durch DTP durch die lästigen Satzbefehle befreit. Mit der Einführung von DTP beschäftigte man sich in den Betrieben der Druckindustrie bis in die 1990er Jahre. SGML wurde nur noch selten erwähnt und verschwand in Deutschland nahezu in der Versenkung.

Die Problematik von SGML besprach Wenke bereits 1986. Er meinte, dass

„SGML eben alles andere als eine Fachleute- und Insider-Sprache bzw. Terminologie bleiben darf und soll – denn dann wäre ihr Sinn völlig verfehlt.

Es geht ja gerade darum, die Dokumenterfassung und -gestaltung zu ‚popularisieren‘, sprich jedem Autor selbst zu überlassen.

Demzufolge müssen in erster Linie die Autoren (also jeder, der ein Dokument erfaßt oder schreibt) diese Auszeichnungssystematik beherrschen. Der Sinn einer allgemeinen Sprache/Codierung wäre verfehlt, wenn beispielsweise ein Verlag hingeht und seinen Autoren als Bedingung zur Veröffentlichung ihrer Werke erst einmal eine Ansammlung von Kommandos vorsetzt, die nichts anderes bewirken sollen, als den Setzer überflüssig zu machen. Dies ist nicht SGML-like, es ist nur eine Verlagerung der Arbeit.

Also hat sich in erster Linie der Autor und weniger der Verleger, Setzer, Drucker mit SGML ‚herumzuschlagen‘; letztere müssen lediglich in der Lage sein, SGML zu verstehen und so anzuwenden, als bekämen sie ein ‚ganz normales‘ Manuskript ‚in die Hand gedrückt‘.

Wird es in Zukunft möglich sein, eine Vielzahl von Dokumenten so herzustellen, daß die notwendigen Codierungen von Anfang an eingearbeitet sind? Sicher, bei einer Behörde (EG) kann man dies anordnen und kontrollieren, aber in der ‚freien Wirtschaft‘ auch?“

Buch „SGML – Eine praktische Einführung“ (1995) von Horst Szillat.

Durch das Aufkommen von Kleinstcomputern (heute sprechen wir von Personal Computern) in den 1970er Jahren, befaßte man sich auch in der Druckindustrie mit dem kommerziellen Einsatz dieser Kleinstcomputer für die Texterfassung. Im „Deutscher Drucker“ (Nr. 19/9-6-19983) war folgendes 1983 zu lesen:

„Besonders aber in Bezug auf die Satzbefehle bietet der Kleinstcomputer Möglichkeiten, die Ihnen die Arbeit erleichtern – ohne den Kunden deshalb zu belasten. Denn Sie können mit dem Kunden ‚Schlüsselwörter‘ vereinbaren – etwa ‚Absatz‘ oder ‚Zwischenüberschrift‘ -, die von Sonderzeichen ‚eingerahmt‘ sind, die in einem normalen Text nicht vorkommen. Zu jedem Schlüsselwort geben Sie einmalig in den Computer die entsprechende Kette von Satzbefehlen ein (eine solche Befehlskette bezeichnet man auch als ‚Makrobefehl‘), worauf der Computer sobald in einem Eingabetext ein Schlüsselwort auftaucht, dieses automatisch in die entsprechende Befehlskette umsetzt. Das ist an und für sich nichts Neues; hier kommt jedoch hinzu, daß ein Schlüsselwort bei jedem Kunden eine andere Befehlskette abrufen kann, Sie müssen nur bei der Einspeicherung der Befehlskette außer dem Schlüsselwort auch die Kundennummer oder den Kundennamen mit abspeichern und bei der Texteingabe Kundennummer/-name ebenfalls eingeben.

Das ganze lässt sich – wenn die Anwendungen des Kunden es erfordern – noch weiter verfeinern, indem zusätzliche Kennzeichen gespeichert bzw. eingegeben werden. Will beispielsweise der Kunde Meier bei Prospekten die Zwischenüberschriften in 15 Punkt Helvetica, in Preislisten aber in 12 Punkt Times, so speichert man eben für ‚Meier-Zwischenüberschriften‘ zwei Befehlsketten – einmal mit dem Zusatz ‚Prospekte‘, einmal mit dem Zusatz ‚Preislisten‘. Der erste Satz des angelieferten Textes würde dann als obersten Schlüsselbegriff beispielsweise ‚Meier-Preislisten‘ enthalten.“

Der Bundesverband Druck in Wiesbaden arbeitete seit Beginn der 1980er Jahre an einer Vereinheitlichung der verschiedenen Satzsprachen. Verständlicherweise stellten sich die Satzmaschinenhersteller gegen dieses Projekt und brachten es so zum Scheitern. Ende 1985 bildeten die Verbände Bundesverband Druck und der Börsenverein des Deutschen Buchhandels eine Arbeitsgruppe, die die Aufgabe hatte, eine logisch, neutral strukturierte Auszeichnungssprache für Autoren, Verlage und Druckereien zu entwickeln. Leiter dieser Arbeitsgruppe war Manfred Krüger. Die Ergebnisse der Arbeit wurden 1986 als Autorensprache „strukTEXT“ vorgestellt, welche sich an SGML anlehnt.

Ein Mitarbeiter des strukTEXT-Projektes berichtete im „Börsenblatt“ (Nr. 96, 2. 12.1986):

„Das Echo ist sehr unterschiedlich. Ich habe gerade das Struktext-Konzept auf der Woche der Druckindustrie vor Setzern vorgestellt. Und der Vorsitzende, Heinz Schornstein vom Vogel-Verlag, Würzburg, hat die Reaktion folgendermaßen beschrieben: von vornehmer Zurückhaltung bis zu schroffer Ablehnung.“

Zwei Jahre später sieht es für strukTEXT nicht besser aus. Manfred Seidel gibt auf der Woche der Druckindustrie 1988 einen von KITTELBERGER vorgetragenen strukTEXT-Erfahrungsbericht zusammenfassend wieder:

„Neben dem Fehlen einfacher Hilfestellung, also verständlicher Materialien und elektronischer Hilfsmittel sowie einfacher und komfortabler SGML-Editoren . . . wird irrtümlich angenommen, daß es sich hier um gängige Codierlisten handele, die man schon habe.

Das Wichtigste ist aber in der Interessenlage begründet. . . . Bekommt der Autor für sein elektronisches Manuskript mehr Geld, wenn er nach SGML/Struktext codiert? Oder der Setzer: Kann es überhaupt in seinem Interesse liegen, sich via SGML selbst auswechselbar zu machen?“

Letztendlich blieb strukTEXT weit hinter den Erwartungen zurück. Es zeichnete sich ab, daß man der deutschsprachigen SGML-Variante die original SGML-Variante vorziehen würde. StrukTEXT erreichte kaum die Betriebe der Druckindustrie.

Erste SGML-Anwendungen

Es waren andere Projekte die SGML in Schwung hielten:

  • das Electronic Manuscript Projekt der Association of American Publishers (AAP) in den Jahren 1983 bis 1987.
  • die CALS-Initiative des Department of Defense (DoD) in den USA ab 1987.
  • die Eintwicklung der DTD „MAJOUR“ (Modular Application for Journals) von der European Workgroup on SGML (EWS) für Zeitschriften.
  • die Entwicklung der „Hypertext Markup Language“ (HTML) von Tim Berners-Lee am Centre Européen de Recherche Nucléaire (CERN) in Meyrin bei Genf, ab 1989.

Auf der XV. Woche der Druckindustrie im Oktober 1989 sprach Roberto Minio vom Institut für Integrierte Publikations- und Informationssysteme der Gesellschaft für Mathematik und Datenverarbeitung (GMD-IPSI) über die CALS-Initiative und SGML. Hans Stein faßte damals für die Fachzeitschrift „Der Polygraph“ (4-1990) zusammen:

„Zusätzliche Impulse gingen auch vom US-amerikanischen Verteidigungsministeriums aus. Das dort initiierte CALS-Programm (Computer aided Acquistion and Logistic Support) forciere die notwendige effektive Integration und Entwicklung systematischer Publikationswerkzeuge. Dieses Programm geht weit über SGML-Anwendungen hinaus, denn mit den in CALS vereinigten Standards ist eine weitaus größere Bandbreite an Dokumenttypen abzudecken, als dies mit der überwiegend textorientierten SGML der Fall ist.

(. . .) Die Aufbereitung des Stoffes ist unterteilt in vier Schritte: Dokumentanalyse, Dokumenttypdefinition, Inhaltsbeschaffung und Validierung, Spezifikation von Präsentation und Formatierung. Im letzten Punkt wird unter anderem entschieden, ob das Dokument formatiert oder für spätere Weiterverarbeitung in eine Datenbank überführt werden soll.

(. . .) In der anschließenden Diskussion machte Joachim Peters noch einige interessante Anmerkungen zur CALS-Initiative. Diese Initiative bedeute konkret, daß, zumindest in den USA, in wenigen Jahren ein Zehntel aller Setzer ihre Arbeit verlieren werde, wenn sie nicht imstande seien, entsprechend der CALS-Initiative, SGML-strukturierte Texte zu erstellen, zu lesen und weiterzuverarbeiten. Der Hintergrung ist folgender: Die umfangreichen Wartungs- und Bedienungsanleitungen der Waffensysteme lassen sich überhaupt nicht mehr auf Papier darstellen. Deshalb hat das US-amerikanische Verteidigungsministerium beschlossen, daß künftig jeder Lieferant bereits im Angebotsstadium sein komplettes Informationsmaterial in der durch CALS vorgegebenen spezifizierten, elektronischen Form einreichen muß.

Im Rahmen der NATO hat dies zwangsläufig auch Auswirkungen auf Europa. Alle amerikanischen Zulieferer werden von ihren europäischen Sublieferanten verlangen müssen, sich der CALS-Initiative anzuschließen. Dies betrifft auch viele Betriebe in der Bundesrepublik. So kann sich Peters durchaus vorstellen, daß Unternehmen wie der Daimler-Benz-Konzern in wenigen Jahren die durch CALS gegebenen Standards aufgreifen werden. Daraus müsse die bundesdeutsche Druckindustrie ihre Konsequenzen ziehen.“

Buch „Informationsmodellierung in XML und SGML“ (1998) von Henning Lobin.

In einem Interview im Börsenblatt (1990) sprachen Holger Wendt und Ingo Scholz vom Springer-Verlag über die CALS-Initiative:

„Neue Power hat SGML durch die Entscheidung des Department of Defense (DoD) bekommen, im Rahmen der CALS-Initiative SGML einzusetzen.

Durch die Entscheidung des DoD hat sich die Marktsituation verändert. Bisher fehlte die Akzeptanz auf breiter Basis, jetzt liegen neue Gegebenheiten vor.“

Die Mitarbeiter des Kernforschungszentrums Karlsruhe Knud Böhle, Ulrich Riehm und Bernd Wingert sowie Ingrid Gabel-Becker vom Institut für Integrierte Publikations- und Informationssysteme der Gesellschaft für Mathematik und Datenverarbeitung (GMD-IPSI) veröffentlichten 1991 das Buch „Elektronisches Publizieren – Eine kritische Bestandsaufnahme“. Dort heißt es:

„Die CALS-Initiative wird Kreise ziehen und irgendwann auch den Verlagsbereich erreichen. Wann das sein wird, hängt davon ab, wie schnell sich Verlage auf die Entwicklung zubewegen. Im Börsenblatt wird schon gefragt: ‚Was muß nun geschehen, daß etwa deutsche Verlage nicht von dieser Entwicklung abgeschnitten werden.‘

Man sollte aber nicht aus diesen neuen Entwicklungen schließen, daß SGML-Anwendungen im Verlagsbereich nun allseits vor der Tür stünden und noch weniger, daß sie kurzfristig die Übergabepraxis elektronischer Manuskripte verändern werden. Unserer Einschätzung nach haben nur jene Verlage ein Interesse an SGML-Anwendungen, die Verlagsdatenbanken aufbauen, Mehrfachverwertung von Daten anstreben und elektronische Publikationen herausbringen wollen. Diese Verlage werden sich eine Systemumgebung aufbauen, in der die SGML-Anwendungen eingebettet sind. Die anderen Verlage werden weiterhin ’nur‘ an praktikablen Austauschformaten, ohne den ganzen SGML-‚Overhead‘, interessiert sein.“

Um den SGML-Standard zu unterstützen gibt es verschiedene Vereinigungen. Im Deutschen Drucker (Nr. 18/1993) wurde 1993 über die Gründung von SGML-Open berichtet:

„Anläßlich der Seybold-Tagung (14. bis 16.4.1993) in Boston wurde auf Initiative von Interleaf das SGML-Open-Forum offiziel gegründet. Larry Bohn, Senior Vice President und SGML-Experte von Interleaf, wurde als Präsident in den Vorstand gerufen.

Gründungsfirmen sind neben dem Publishing-Unternehmen sechzehn weitere System- und Softwarehäuser, darunter ArborText, Avalanche, EBT, Fulcrum, Intergraph, Object Design und Oracle. Ziel ist es, sowohl über die Vorteile von SGML aufzuklären als auch Anwendern beim Implementieren dieses Standards beratend zur Seite zu stehen.

Der Standard ist bereits in vielen Branchen, wie beispielsweise der Automobil- oder der Luft- und Raumfahrtindustrie, verbreitet. Nach Angaben von Experten wird SGML in den nächsten Jahren die gleiche Bedeutung zukommen, wie sie die Abfragesprache SQL bei Datenbanken erfährt.“

In diesem Artikel werden als SGML-Anwender die Automobil- und die Luft- und Raum-fahrtindustrie erwähnt. In den USA hat die Society of Automotive Engineers (SAE) eine DTD entwickelt, die von den US-Behörden für die Dokumentation von Autoteilen vorgeschrieben ist. Flugzeughersteller wie BOING oder Lockheed Martin liefern die Dokumentationen ihrer Flugzeuge als elektronisches Produkt an die Fluggesellschaften. Die Dokumente werden mit SGML erstellt. Die Air Transport Association (ATA) entwickelt ebenfalls DTDs für den Austausch von Flugzeugdokumentationen. Im militärischen Bereich werden die Fahrzeugdokumentation ebenfalls mit SGML/CALS erstellt und elektronisch ausgeliefert, u.a. um in den Fahrzeugen Gewicht zu sparen.

Eine bekannte DTD ist die DocBook-DTD von HaL Computer Systems International und O’Reilly & Associates. Mit dieser umfangreichen DTD werden Dokumentationen von Computer-programmen geschrieben.

Buch „XML in der Praxis“ (1998) von Henning Behme und Stefan Mintert.

Hypertext Markup Language

Tim Berners-Lee hatte 1989 begonnen die auf SGML basierende „Hypertext Markup Language“ (HTML) zu entwickeln. Aus seinen Ideen entstand zu Beginn der 1990er Jahre das World Wide Web. Ab 1994 waren die Begriffe „Internet“, „World Wide Web“, „WWW“, „das Web“, „EMail“ und „Homepage“ in aller Munde. Mit HTML erreichte SGML die breite Öffentlichkeit, ohne das diese direkt von SGML wußte. In den zahlreichen Berichten und Büchern wurde SGML meistens nur kurz erwähnt und HTML als Untergruppe oder als Ableger von SGML bezeichnet, worunter sich kaum ein HTML-Anwender etwas vorstellen konnte. Mit Zunahme der Internet-Anschlüsse, wuchs auch das Bedürfnis eine eigene Homepage zu erstellen. Im WWW kann jeder seine Dokumente veröffentlichen, Firmen und Privatpersonen. HTML wurde in der zweiten Hälfte der 1990er Jahre für viele Computeranwender zum Hobby und immer mehr Firmen verlangten von ihren Mitarbeitern HTML-Kenntnisse.

Die Normierung der HTML-DTD obliegt dem 1991 gegründeten World Wide Web Consortium (W3C). Das W3C entwickelte 1996 die Layoutsprache Cascading Style Sheets (CSS) für HTML und 1996-1998 die Extensible Markup Language (XML) als abgespeckte SGML für das WWW.

Nichts hat SGML bekannter gemacht wie HTML. Während man bei HTML im Zusammenhang mit dem WWW von einem Boom sprechen kann, ist SGML weit davon entfernt. Mit XML wird die Entwicklung von DTDs eine breitere Öffentlichkeit erlangen. Die Prognosen für XML gehen dahin, daß große Firmen XML für den Austausch von Daten und mit CSS für die Erstellung ihrer WWW-Seiten verwenden werden. Der „normale“ Web-Publisher wird von XML unberührt bleiben.

SGML oder nicht SGML

Wie bereits in Abschnitt 1.1 erwähnt, soll man bei SGML möglichst in Dokumenttypenklassen denken. In der Ausgabe Nr. 41/1997 kündigte man in der Druck-Fachzeitschrift „Deutscher Drucker“ eine DTD für den Dokumenttyp juristische Loseblattwerke an:

„Das Geschäftsfeld Structured Document Publishing der Siemens Nixdorf Informationssysteme AG hat zusammen mit der Firma IlmDat GmbH, Ilmenau, einen Arbeitskreis für SGML-gestützte Loseblattherstellung gegründet. Ziel ist, eine allgemein gültige DTD (Document Type Definition) für juristische Texte zu entwickeln. Unter der Beteiligung von zahlreichen Verlagen fand die Auftaktveranstaltung des SGML-Arbeitskreises für Loseblattwerke am 16. Oktober 1997 im Rahmen der Buchmesse statt.“

Im einem Artikel des „Deutschen Drucker“ diskutiert Wolfgang Hilbig vom Satz-Rechen-Zentrum in Berlin die „Mehrfachnutzung von Daten“. Für die juristischen Loseblattsammlung „BRV Berliner Rechtsvorschriften“ des Berliner Kulturbuch-Verlag sollte sowohl der Satz (Neuerfassung aller 8 500 Seiten) als auch eine CD-ROM erstellt werden. Beim SRZ entschied man sich gegen SGML und für die Anwendung von Adobe Acrobat mit dem PDF. Hilbig begründete dies so:

„Die Typorafie des vorliegenden Werks war vielfältig genug, daß selbst bei allen zulässigen Vereinfachungen (bei juristischen Werken gibt der Gesetzgeber einen guten Teil der Typografie vor, der Verlag darf sie nur in Grenzen verändern) der Umgang mit den Daten durch die Fülle der notwendigen (z.T. auch nur durch die Typografie bedingten) Markierungen aufwendig und damit fehleranfällig und teuer geworden wäre. Hinzu kam, daß es einfach bleiben sollte, ‚lokal‘ von den sonst im Werk üblichen typografischen Regeln abzuweichen. Entgegen anderen Äußerungen von Spezialisten sind die Kosten für Datenerfassung, Datenbearbeitung und Satz bei SGML-Daten zumindest für juristische Werke immer noch anderthalb bis zweimal höher als beim konventionellen Satz.“

Für die beschriebene Loseblattsammlung scheint es wirklich besser auf SGML zu verzichten und mit DTP-Programmen zu arbeiten, denn eine DTD gibt mehr oder weniger strenge Regeln vor, die es nicht erlauben beliebig ‚lokal‘ von den Regeln abzuweichen.

Hilbig sieht SGML dort als sinnvoll an, wo:

  • die Inhalte ohnehin ‚repetetiver‘ Art sind, sich also weitgehend gleichförmig wiederholen. Beispiel: Adreßverzeichnisse, Bibliographien, (einfache) Lexika
  • der Herausgeber oder Verlag die vollständige Kontrolle über das typografische Erscheinungsbild hat, die Typografie also so einfach halten kann, daß der Tag-Mechanismus von SGML nicht zu einer typografischen Auszeichnungssprache verkommt. Beispiel: Technische Manuale
  • die Verwaltung von großen Dokumentbeständen eine rechnergesteuerte Kontrolle des ändernden Zugriffs (wer darf ändern und welchen Änderungsstand hat das Dokument) und der Verweise (sowohl innerhalb des Dokuments als auch zwischen den Dokumenten) notwendig macht.

Außer in diesen Bereichen sei die Akzeptanz von SGML weit hinter den Erwartungen zurückgeblieben.

Hilbig machte sich auch über die elektronische Nutzung des Loseblattwerkes seine Gedanken:

„Das Werk befindet sich bislang nicht im Internet. Daran Schuld sind weder mangelnde technische Weitsicht bei der Konzeption des Systems noch die Kosten für die technische Realisierung: Der Grund ist in der außerhalb unseres Einflußbereichs liegenden Frage zu suchen, wie denn Werke dieser Art über das Internet verkauft werden können.

Dies ist eine Frage für den Verleger und eine schwierige Frage obendrein. Leicht erkennbar wird dies an den Verzweiflungsakten, den Internetzugang zu Publikationen nur den Kunden zu öffnen, die auch das gedruckte Produkt kaufen. Der Mehrwert besteht hier in der Möglichkeit zu recherchieren – auch in zurückliegendem Material – und eigene, lokale Dokumentbestände durch gezieltes Download aufzubauen.“

Andere juristische Fachverlage wie der Verlag Dr. Otto Schmidt (Köln), der Verlag Neue Wirtschafts-Briefe (Herne), der Carl Heymanns Verlag (Köln), der Stollfuß Verlag (Bonn) oder der Hermann Luchterhand Verlag (Neuwied) setzen bei Loseblattwerken und bei Büchern auf SGML.

 SGML bei Zeitungsverlagen

Justin Arundale, von der University of Brighton, schrieb 1995 in der Fachzeitschrift „Zeitungs-technik“ (Feb. 1995):

„Die einfachste Art des elektronischen Publizierens ist die Verbreitung von reinem Text ohne Layout und ohne grafischen Inhalt.

Welche Probleme können bei reinen Textdatenbanken auftreten? Überschriften können hier Schwierigkeiten bereiten. Die Hauptprobleme entstehen durch den Verlust der Layoutinformationen.

Es gibt einen Quasi-Standard mit der Bezeichnung SGML, der zunehmend Verwendung findet, um die Layoutmerkmale von elektronisch und konventionell veröffentlichten Dokumenten zu definieren. Derzeit ist er in der Zeitungsindustrie noch nicht weit verbreitet, obwohl sich bei einem verstärkten Einsatz einige Probleme im Zusammenhang mit der Standardisierung elektronischer Dokumente verringern ließen.“

Ebenfalls 1995 schrieb Klaus v. Prümmer von der IFRA in der „Zeitungstechnik“ (Mai 1995):

„Der elektronische Zugriff auf den Volltext und speziell die Serviceinformation werden unmittelbar eine Verbindung zwischen Zeitung und Lesern schaffen.

Das erfordert in der Zeitungsredaktion eine perfekt strukturierte Datenbank, die ohnehin der Schlüssel für den Erfolg der nächsten Generation von Redaktionssystemen ist. Wir müssen lernen, die Ressourcen einer Redaktion elektronisch zu verwalten, (. . .) damit die Beiträge in unterschiedlichen Formen publiziert werden können.

Eine der wesentlichen Entwicklungen hat in den letzten Jahren die Fachpublikationen revolutioniert: die Standard Generalized Markup Language (SGML). SGML beschreibt die Elemente eines Dokumentes, also Überschrift, Vorspann, Autor und Grundtext. Ebenso kann man mit den SGML-Tags kennzeichen, was eine Person, eine Firma oder ein geografischer Begriff ist. Man kann dann zum Beispiel die Suche nach „Münster“ dadurch eingrenzen, daß man sagt, ob man die Stadt, das Gebäude oder eine Person mit diesem Namen meint.

. . . wir diskutieren die gegensätzlichen Aspekte zur Zeit intensiv mit den Nachrichtenagenturen. Für Archiv und elektronische Weiterverarbeitung ist SGML extrem wichtig; für das Tagesgeschäft eines Zeitungsreporters ist es noch eher ein Alptraum. Die Industrie arbeitet mit Hochdruck an Lösungen.

In der klassischen Redaktion wird SGML wenig ändern, da die Kennzeichnung der Elemente in der Regel verborgen bleibt. Trotzdem wird SGML zusammen mit künftigen Redaktionsdatenbanken dazu führen, daß die Redakteure die vollständige Kontrolle über Texte, Bilder, Grafiken und Layout, aber auch über akustische Aufzeichnungen und alle möglichen Ausgabeformen haben werden.“

In Barcelona fand 1997 ein IFRA-Symposion zum Thema „Moderne Zeitungsarchive“ statt. Dazu schrieb Richard Everett, Axel Springer Verlag:

„Eine Zeitung, die ihr Archiv abschafft, wäre nicht mehr die Zeitung, wie wir sie heute kennen. Es ist sicher nicht vermessen, wenn wir behaupten, daß das Archiv für die Qualität der Zeitung von entscheidender Bedeutung ist.

Es gibt drei bedeutende technologische Entwicklungen, die uns veranlassen sollten, den Einsatz von digitalen Archivsystemen in unseren Zeitungsverlagen zu erwägen: die Speicherkapazität, die vollständig digitale Zeitungsproduktion und das, was ich als ‚Internet-Faktor‘ bezeichne.

Das Format, in dem die Dokumente gespeichert werden, bestimmt die Funktionalität des Archivsystems und den Umfang, in dem die Inhalte künftig genutzt werden können. Ihr Archivsystem sollte Dokumente in Standard-Formaten (z. B. Textdokumente in SGML und/oder PDF, Bilder in TIFF oder JPEG usw.) speichern. Nur dann ist gewährleistet, daß die Daten leicht und kostengünstig für jede Art des elektronischen Publizierens, ob online oder offline, wiederverwertbar sind. Und nur dann ist sichergestellt, daß die Daten portiert werden können, wenn Ihr Archivsystem eines Tages durch ein neues System ersetzt werden sollte.“

Die Fachzeitschrift „Zeitungstechnik“ veröffentlichte 1997 einen Artikel über den International Press Telecommunications Council (IPTC), dessen Haupttätigkeit in der Entwicklung und Bewertung von Standards und Verfahren für den Einsatz in der Zeitungsindustrie besteht.

„Das wichtigste Format für die Übermittlung von Nachrichten ist das Information Interchange Modell (IIM). Das IIM läßt sich für Nachrichten in allen gebräuchlichen Formen (Text, digitale Fotos und Grafiken, Audio- und Videosequenzen) einsetzen und bietet eine große Flexibilität hinsichtlich der Möglichkeit, auch redaktionelle Informationen im Zusammenhang mit Nachrichten zu übermitteln.

Eng verbunden mit dem IIM ist der Digital Newsphoto Parameter Record (DNPR). Dieses Dateiformat wurde für die Übertragung von digitalen Pressefoto-Daten entwickelt und ermöglicht die Übertragung von redaktioneller und technischer Daten zusammen mit Bilddaten in einer Datei.

Der jüngste Standard ist das News Industry Text Format (NITF). Der Standard wurde dafür konzipiert, den ‚Wert‘ von Nachrichtentexten durch das Hinzufügen struktureller Auszeichnungen zu steigern. Es handelt sich um eine SGML DTD, die mit der im World Wide Web verwendeten HTML abgestimmt wurde. Durch die Verwendung dieses Formats ist es möglich, Nachrichtendaten zusammen mit den dazugehörigen Auszeichnungen zu übertragen, die für die nachfolgende Verarbeitung im Druck oder in elektronischen Versionen erforderlich sind. Daten, die im NITF oder im DNPR übermittelt werden, lassen sich in das IIM einschließen, so daß damit ein höchst flexibles Übertragungsverfahren zur Verfügung steht.“

Das Buch in Vergangenheit und Zufunft

Walther Umstätter, Professor am Institut für Bibliothekswissenschaft der Humboldt-Universität in Berlin, schrieb in der Zeitschrift „Spektrum der Wissenschaft – Dossier: Die Welt im Internet“ (1998) einen Artikel über „Die Zukunft des Buches“:

„Das Buch hat in seiner Geschichte eine Reihe von höchst interessanten Facetten entwickelt. Es ist eine äußerst praktische Fortentwicklung des Codex – einer Sammlung loser Blätter zwischen zwei Holzdeckeln -, des Diptychons – der zweiflügeligen Klapptafel – und der Buchrolle. (. . .) Über Jahrhunderte hinweg hatte es die wichtigste Archiv-, Informations- und Transportfunktion für geistiges Eigentum übernommen (. . .) Die meist hundert bis tausend Seiten, die durch Heftung oder Leimung verbunden sind, werden durch einen Einband oder Umschlag geschützt, der dem Buch auch die notwendige Stabilität zur mehrfachen Benutzung und langjährigen Lagerung in Bücherregalen gibt. Es ist in seiner wichtigsten Eigenschaft eine handhabbare informetrische Einheit, die man wie ein erweitertes Gedächnis mit sich führen, weitergeben und auf die man sich ’schwarz auf weiß‘ berufen kann. Das digitale Buch war anfangs zweifellos nichts anderes als die digital gespeicherte Form herkömmlicher Bücher. Aus ihr entwickelte sich allerdings im Laufe der letzten Jahre eine multimediale Buchform, die durch zusätzliche Ton- und Bewegtbildeigenschaften, durch Animation und Modellierungsmöglichkeiten völlig neue Charakterzüge gewann.

Für diese Form des multimedialen Buches hat sich auch schon eine Norm etabliert, die SGML, in der neben dem eigentlichen Text zusätzliche Informationen – die Markups – enthalten sind, die sich für Druckanweisungen, für Ausgabemöglichkeiten am Bildschirm oder auch für andere Anmerkungen in den Dokumenten verstecken lassen.

Sie können als Volltextindexierung verstanden werden, die bei der Recherche in Volltextretrievalsystemen wichtige Hilfen zur Wiedergewinnung von Informationen darstellen.

(. . .) SGML ist eine Metasprache zur Erzeugung von DTDs, womit die Voraussetzung geschaffen ist, mit Hilfe der Markups die jeweils vorhandene Basissprache (Texte in englisch oder deutsch) zusätzlich zu strukturieren. Damit bietet sie die ideale Voraussetzung, um Informationen aus Volltexten so zu organisieren, daß aus ihnen Wissensdatenbanken entstehen. Dies sind Datenbanken, in denen die Informationen so vernetzt werden, daß sie von Computerprogrammen interpretiert und zu begründeten Schlüssen herangezogen werden können.

Damit entstehen Bücher, deren Wissen nicht nur vom Menschen nachvollziehbar ist, sondern auch vom Computer.

(. . .) Die weit verbreitete Ansicht, das Buch sei auch heute noch das ideale Archivmedium, wird bei genauer Betrachtung relativiert. So haben fast alle Informationen, die wir aus der Geschichte heraus tradieren konnten, durch Kopieren überlebt und nur in äußerst seltenen Ausnahmen durch Aufbewahrung der alten Exemplare. Diese Kopien können heute rascher, fehlerfreier und preiswerter vorgenommen werden, so daß wir nicht mehr wie im Mittelalter Mönche als Kopisten beschäftigen müssen. Anstelle dessen haben wir Computer, die fast ohne Personalkosten tausendmal schneller und millionenmal fehlerfreier Kopien auf CD-ROMs erzeugen können. Bei diesen Verhältnissen ist es schon heute einfacher, eine CD-ROM alle zehn Jahre zu kopieren, als ein Buch alle hundert Jahre.“

In der gleichen Zeitschrift schrieb Michael Lesk, Wissenschaftler bei der Firma Bellcore in Morristown (New Jersey/USA) in dem Artikel „Die digitale Bücherwelt“:

„Wenn eines Tages alle Hindernisse aus dem Weg geräumt und Abermillionen von Büchern, Bildern und Tonaufzeichnungen digitalisiert sind – wird es unseren Kindern dann auch gelingen, sie überhaupt zu finden? Das Problem ist nicht die Entwicklung ausreichend beständiger Materialien für Speichermedien, sondern deren schnelle technische Entwicklung. Das Überspielen digitaler Information von einem Gerät zu einem gleichartigen ist nicht schwierig – Bits bleiben Bits. Doch neue Datenformate und Geräte werden im Abstand weniger Jahre immer wieder das Konvertieren der Bestände erfordern. Zudem lassen sich einige Formate nur unter Informationsverlust in andere umwandeln. Immerhin finden Normen wie die SGML für Texte oder Formate wie TIF (Tag Image File) für gescannte Bilder mehr und mehr Akzeptanz.“

 

SGML DTDs

Ein vollständiges SGML Dokument besteht aus drei Bestandteilen:

  • der SGML Deklaration,
  • dem Prolog,
  • dem eigentlichen Dokument.

Mit der SGML-Deklaration werden wir uns zum jetzigen Zeitpunkt nicht näher beschäftigen, es sei nur erwähnt, dass in ihr die Regeln von SGML hinterlegt sind. Der Prolog enthält die Document Type Declaration (DOCTYPE) und diese wiederum kann die Document Type Definition (DTD) enthalten. Im Dokument werden die Tags verwendet, die in der DTD definiert worden sind.

Document Type Declaration

Die Document Type Declaration (auch: DOCTYPE declaration genannt) darf nicht mit der Document Type Definition verwechselt werden. In der Document Type Declaration wird das Wurzelelement (Name der DTD) und die entsprechende DTD angegeben. Dabei gibt es erstens die Möglichkeit, daß die DTD innerhalb des ‚Declaration subset‘ steht, der durch eckige Klammern begrenzt wird.

<!DOCTYPE Wurzelelement [Declaration subset]>

Bei der folgenden ersten Möglichkeit ist „Artikel“ das Wurzelelement. Die DTD steht zwischen eckigen Klammern, also im Declaration subset.

  1. Möglichkeit
<!DOCTYPE Artikel[

Inhalt der DTD

]>

Bei der zweiten Möglichkeit befindet sich die DTD nicht im Declaration subset, sondern in einer extra Datei. Vor der DTD befindet sich ein Kommentar, der angibt wie die Document Type Deklaration im Dokument zu schreiben ist. Nach DOCTYPE wird hier der Name des Wurzelelementes geschrieben, dann folgt die Angabe PUBLIC die einen ‚Public identifier‘ kennzeichnet. Bei einem Public identifier wird im Gegensatz zu einem ‚System identifier‘ kein Pfad- oder Dateiname angegeben, sondern ein öffentlicher Name, der von einem bestimmten Pfad auf einem Rechner unabhängig ist. Bei dem folgenden Ausdruck innerhalb der Anführungszeichen gilt die folgende Syntax:

„Zeichen für angemeldete oder nicht angemeldete DTD//Besitzer der DTD//Typ (Art des Objektes, hier DTD) Spezifikation//Sprache“

Zeichen für angemeldete DTD ist ein +

Zeichen für nicht angemeldete DTD ist ein –

Besitzer der DTD: Buergerblatt

Sprache: DE (für deutsch)

  1. Möglichkeit
DTD

<!--Artikel PUBLIC "-//Buergerblatt//DTD Artikel//DE"-->

Inhalt der DTD

SGML-Dokument

<!DOCTYPE Artikel PUBLIC "-//Buergerblatt//DTD Artikel//DE" "Artikel.DTD">
<Ueberschrift>Allianz: Freie Bahn auf dem Weg zur Nummer eins</Ueberschrift><Ort>München</Ort> <Inhalt>Dem Aufstieg des Allianz-Konzers zur weltweit größten Versicherung scheint nichts mehr im Wege zu stehen.</Inhalt><Verweis>(Wirtschaft)</Verweis>

Ebenfalls würde gelten (hier wird ein System identifier verwendet):

<!DOCTYPE Artikel SYSTEM "C:\eigene Dateien\SGML\Artikel.DTD"> . . .

bzw.

<!DOCTYPE Artikel SYSTEM "Artikel.DTD" [ ]> . . .

Document Type Definition

SGML hat keinen festen Sprachschatz. Die SGML-Tags werden vom Document Typ Definition-Ersteller (DTD-Designer) definiert. In der DTD werden die Regeln des Dokumentes hinterlegt und den Elementen frei wählbare Namen gegeben. Mit der Hilfe der DTD wird das SGML-Dokument erzeugt. Diesem SGML-Dokument wird ein Layout zugeordnet.

Element-Deklaration

Im Beispiel oben wären die Elemente „Artikel“, „Ueberschrift“, „Inhalt“, „Ort“ und „Verweis“. In der DTD wird dies so geschrieben:

<!ELEMENT Artikel - - (Ueberschrift, Ort, Inhalt, Verweis)>

<!ELEMENT Ueberschrift - - (#PCDATA)>

<!ELEMENT Inhalt - - (#PCDATA)>

<!ELEMENT Ort - - (#PCDATA)>

<!ELEMENT Verweis - - (#PCDATA)>

In der Element-Deklaration wird der Elementname, die Verkürzung und das Inhaltsmodell beschrieben:

<!ELEMENT Elementname Verkürzung Inhaltsmodell>

Elementname: z.B. Artikel.

Verkürzung: Die beiden Striche hinter dem Elementnamen zeigen an, daß der Start- und der Endetag im Dokument erscheinen müssen. Würde an Stelle des letzten Striches ein O stehen, könnte der Endetag entfallen (Hinweis: Das O steht für ottmited = auslassen). Wenn auch der erste Strich durch ein O ersetzt wird, kann auch der Starttag ausgelassen werden.

Inhaltsmodell (content modell): z.B. (Ueberschrift, Ort, Inhalt, Verweis)

Ohne Endetag

<!ELEMENT Artikel - O (Ueberschrift, Ort, Inhalt, Verweis)>
<Artikel><Ueberschrift>Allianz: Freie Bahn auf dem Weg zur Nummer eins</Ueberschrift><Ort>München</Ort> <Inhalt>Dem Aufstieg des Allianz-Konzers zur weltweit größten Versicherung scheint nichts mehr im Wege zu stehen.</Inhalt><Verweis>(Wirtschaft)</Verweis>

Ohne Start- und Endetag

<!ELEMENT Artikel O O (Ueberschrift, Ort, Inhalt, Verweis)>
<Ueberschrift>Allianz: Freie Bahn auf dem Weg zur Nummer eins</Ueberschrift><Ort>München</Ort> <Inhalt>Dem Aufstieg des Allianz-Konzers zur weltweit größten Versicherung scheint nichts mehr im Wege zu stehen.</Inhalt><Verweis>(Wirtschaft)</Verweis>

Attribut-Deklaration

Um Elemente zu erweitern, benutzt man bei SGML Attribute. Die Attribute und die Attributwerte stehen innerhalb des Starttags.

<ELEMENTNAME ATTRIBUT="ATTRIBUTWERT">

In der ‚attribute list declaration‘ (ATTLIST) schreibt man:

<!ATTLIST ELEMENTNAME

ATTRIBUTNAME (mögliche Attributwerte)>

In der Artikel-DTD könnte man dem Artikel noch eine Rubrik zuordnen. Wählbar ist zwischen den Rubriken „Politik“, „Wirtschaft“, „Kultur“, „Sport“ und „Lokales“. In der DTD schreibt man:

<!ATTLIST Artikel

Rubrik (Politik | Wirtschaft | Kultur | Sport | Lokales)#IMPLIED>

Das Wort „Implied“ zeigt an, daß das Attribut „Rubrik“ nicht notwendig ist. Würde an der gleichen Stelle „Required“ stehen, so wäre das Attribut notwendig.

Der Artikel:

<Artikel Rubrik="Wirtschaft"><Ueberschrift>Allianz: Freie Bahn auf dem Weg zur Nummer eins</Ueberschrift><Ort>München</Ort> <Inhalt>Dem Aufstieg des Allianz-Konzers zur weltweit größten Versicherung scheint nichts mehr im Wege zu stehen.</Inhalt><Verweis>(Wirtschaft)</Verweis></Artikel>

Entity-Deklaration

Entities (Mehrzahl von Entity) haben vielfältige Möglichkeiten. Mit ihnen kann man den Zeichenvorrat unbegrenzt erweitern. Man unterscheidet grundsätzlich zwischen dem ‚general entity‘ und dem ‚parameter entity‘. Das ‚general entiy‘ wird im SGML-Dokument verwendet und hat dort die Form:

&Name;

In der DTD wird das ‚general entity‘ bespielsweise wie folgt definiert:

<!ENTITY Name "Inhalt">

Hiermit ist es möglich lange Zeichenketten, die sich in einem Dokument öfters wiederholen, in einer Kurzform zu definieren.

<!ENTITY form "In ein Formblatt (vgl. Hinweise Ziff. 5) ist einzusetzen:">

Im Dokument schreibt man nur &form; und der Formatierer ersetzt dies durch: „In ein Formblatt (vgl. Hinweise Ziff. 5) ist einzusetzen:“

Das ‚parameter entity‘ wird nur in der DTD verwendet und hat dort die Form:

<!ENTITY % Name Parameter>

SGML-Dokumente bestehen aus 7-bit-ASCII Zeichen. Die Umlaute oder andere Sonderzeichen sind in 7-bit-ASCII nicht enthalten. Hierzu gibt es von der ISO spezielle Listen (siehe Anhang A), in denen steht wie Sonderzeichen in SGML Dokumenten zu codieren sind. Eine solche Liste wird Public Entity-Set genannt.

<!ENTITY auml; SDATA "[auml]" - - =small a, dieresis or umlautmark - ->

<!ENTITY Auml; SDATA "[Auml]" - - =capital a, dieresis or umlautmark - ->

<!ENTITY ouml; SDATA "[ouml]" - - =small o, dieresis or umlautmark - ->

<!ENTITY Ouml; SDATA "[Ouml]" - - =capital o, dieresis or umlautmark - ->

<!ENTITY uuml; SDATA "[uuml]" - - =small u, dieresis or umlautmark - ->

<!ENTITY Uuml; SDATA "[Uuml]" - - =capital a, dieresis or umlautmark - ->

<!ENTITY szlig; SDATA "[szlig]" - - =small sharp s, German(szligature - ->

Dies sind die Ersetzungen für die Umlaute und das ß.

<Artikel Rubrik="Wirtschaft"><Ueberschrift>Allianz: Freie Bahn auf dem Weg zur Nummer eins</Ueberschrift><Ort>M&uuml;nchen</Ort> <Inhalt>Dem Aufstieg des Allianz-Konzers zur weltweit gr&ouml;&szlig;ten Versicherung scheint nichts mehr im Wege zu stehen.</Inhalt><Verweis>(Wirtschaft)</Verweis></Artikel>

Die Umlaute und das ß befinden sich in der Liste mit den westeuropäischen Buchstaben, genannt „Latin 1“ (lateinisch 1/ISO-8859-1). In der DTD wird nicht die ganze Liste aufgeführt, sondern nur ein Verweis auf diese Liste:

<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN">

%ISOlat1;

In einigen SGML-Editoren kann man die Umlaute normal tasten. Die Software weiß: Wenn die Taste ä gedrückt wird, ist in den Quelltext ein &auml; einzufügen. Öffnet man das SGML-Dokument in einer Textverarbeitung, die von SGML nichts weiß, sieht man auf dem Bildschirm nicht die Umlaute, sondern deren Ersetzungen.

Entities für circumflex (z.B. Â), grave (z.B. À), acute (z.B. Á), tilde (z.B. Ã), umlaut (z.B. Ä), ring (z.B. Å), ligatur (z.B. ß), cedilla (z.B. Ç) und slash (z.B. Ø)

Circumflex: &Acirc;, &Ecirc;, &Icirc;, &Ocirc;, &Ucirc;, &acirc;, &ecirc;, &icirc;, &ocirc;, &ucirc;

Grave: &Agrave;, &Egrave;, &Igrave;, &Ograve;, &Ugrave;, &agrave;, &egrave;, &igrave;, &ograve;, &ugrave;

Acute: &Aacute;, &Eacute;, &Oacute;, &Uacute;, &aacute;, &eacute;, &oacute;, &uacute;

Tilde: &Atilde;, &Ntilde;, &Otilde;, &atilde;, &ntilde;, &otilde;

Umlaut: &Auml;, &Euml;, &Iuml;, &Ouml;, &Uuml;, &auml;, &euml;, &iuml;, &ouml;, &uuml;,

Ring: &Aring;, &aring;

Ligatur: &aelig;, &szlig;

Cedilla: &Ccedil;, &ccedil;

Slash: &Oslash;, &oslash;

Nach der Zuordnung:

Circumflex: Â, Ê, Î, Ô, Û, â, ê, î, ô, û

Grave: À, È, Ì, Ò, Ù, à, è, ì, ò, ù

Acute: Á, É, Ó, Ú, ´, é, ó, ú

Tilde: Ã, Ñ, Õ, ã, ñ, õ

Umlaut: Ä, Ë, Ï, Ö, Ü, ä, ë, ï, ö, ü

Ring: Å, å

Ligatur: æ, ß

Cedilla: Ç, ç

Slash: Ø, ø

Anführungszeichen, Zwischenräume und Striche in SGML

In der deutschen Sprache schreibt man die Anführungszeichen als 99 (unten) und die Abführungszeichen als 66 (oben) Im englischsprachigen Raum schreibt man hingegen die Anführungszeichen als 66 (oben) und die Abführungszeichen 99 (oben). Obwohl man bei SGML an die An- und Abführungen gedacht hat, wurde auf einzelne Länder keine Rücksicht genommen. Für die letztendliche Erscheinungsweise muß im Formatierer (Satzsoftware) gesorgt werden.

Anführungszeichen (quotation mark) in SGML (genormt in ISOpub):

einfache Anführungen (rising single quote, left [low]) &lsquor;

doppelte Anführungen (rising double qoute, left [low]) &ldquor;

einfache Abführungen (rising single quote, right [high]) &rsquor;

doppelte Abführungen (rising double quote, right [high]) &rdquor;

Typografische Zwischenräume (space) in SGML (genormt in ISOpub)

Benötigt werden hier Halb-, 1/3- und 1/4-Gevierte. Da bei den meisten Schriften die Breite des >m< dem Maß des Gevierts entspricht, spricht man im englischen von >em-space<. Das Halbgeviert entspricht des Breite des >n<, daher spricht man im englischen vom >en-space<.

Geviert (em space) &emsp;

Halbgeviert (en space) &ensp;

1/3-Geviert (1/3-em space) &emsp13;

1/4-Geviert (1/4-em space) &emsp14;

Striche (dash) in SGML (genormt in ISOpub)

Wichtig ist hier vor allem die Unterscheidung zwischen Binde- bzw. Trennstrich (Divis) und Gedankenstrichen. Das Divis wird ganz normal getastet. Als Gedankenstrich wird der Halbgeviertstrich (en dash) verwendet.

Divis –

Gedankenstrich &ndash;

Die DTD lautet damit:

<!DOCTYPE Artikel[

<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN">

%ISOlat1;

<!ENTITY % ISOpub PUBLIC "ISO 8879-1986//ENTITIES Publishing//EN">

%ISOpub;

<!ELEMENT Artikel - - (Ueberschrift, Ort, Inhalt, Verweis)>

<!ATTLIST Artikel

Rubrik (Politik | Wirtschaft | Kultur | Sport | Lokales)#IMPLIED>

<!ELEMENT Ueberschrift - - (#PCDATA)>

<!ELEMENT Inhalt - - (#PCDATA)>

<!ELEMENT Ort - - (#PCDATA)>

<!ELEMENT Verweis - - (#PCDATA)>

]>

Kommentare und Processing Instructions

Kommentare

Oft sind DTDs und SGML-Dokumente für Dritte nur schwer verständlich. Zu Erleichterung kann man sowohl in der DTD wie auch im SGML-Dokument Kommentare schreiben.

Kommentaranfang: <!–

Kommentarende: –>

In der Artikel-DTD befinden sich nun Kommentare:

<!DOCTYPE Artikel[

<!--Public entity sets-->

<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN">

%ISOlat1;

<!ENTITY % ISOpub PUBLIC "ISO 8879-1986//ENTITIES Publishing//EN">

%ISOpub;

<!--hier beginnt die eigentliche DTD-->

<!ELEMENT Artikel - - (Ueberschrift, Ort, Inhalt, Verweis)>

<!ATTLIST Artikel

Rubrik (Politik | Wirtschaft | Kultur | Sport | Lokales)#IMPLIED>

<!ELEMENT Ueberschrift - - (#PCDATA) -- Element fuer die Ueberschrift -- >

<!ELEMENT Inhalt - - (#PCDATA)>

<!ELEMENT Ort - - (#PCDATA)>

<!ELEMENT Verweis - - (#PCDATA)>

]>

Wie beim letzten Kommentar zu sehen ist, können Kommentare auch innerhalb der Element-Deklaration vorkommen, um das Element näher zu beschreiben.

Processing Instructions

Mittels Processing Instructions (PIs) ist es möglich einer bestimmten Software Verarbeitungshinweise zugeben. Die Satzsoftware Advent 3B2 stellt ihre eigenen Befehle als PIs dar. Für eine andere Software haben diese PIs keine Bedeutung. Von SGML-Parsern, die DTDs und SGML-Dokumente kontrollieren, werden PIs nicht kontrolliert und somit auch nicht als Fehler angezeigt. Durch die Verwendung von PIs wird die Allgemeingültigkeit des SGML-Dokumentes eingeschränkt. Werden viele Funktionen eines Dokumentes über PIs gesteuert, ist das Dokument in einem anderen SGML-System nicht direkt mit den gleichen Funktionen verfügbar. Sie müssen erst für das SGML-System definiert werden.

Eine PI beginnt mit <? und endet mit >.

Synex SGML Viewer (Bildschirmfoto 1998). Links die Struktursicht, rechts die typografische Darstellung.

Connectoren und Occurrence Indicators

Um Flexibilität zu ermöglichen, aber auch Grenzen in die DTD einzubauen, werden in DTDs Connectoren und Occurrence Indicators verwendet.

Mit den Connector-Symbolen kann man bestimmen, in welcher Reihenfolge (Sequenz) die Elemente erscheinen, und ermöglicht Alternativen. Mit den Occurrence Indicator-Symbolen wird definiert ob und wie oft ein Element erscheinen darf (Quantität). Damit kontrollieren die Connectors die Sequenz und die Occurrence Indicators die Quantität.

 

Symbol Sequenz (Connector)

Bedeutung

,

 Sequenz (meint: „gefolgt von“)

&

und (alle müssen erscheinen, die Reihenfolge ist egal)

|

oder (Alternativen)

Symbol Quantität (Kardinalität/Occurrence Indicators)

Bedeutung

?

Optional (nur null oder ein können erscheinen)

*

Optional und wiederholbar (null oder mehrere können erscheinen)

+

Notwendig und wiederholbar (ein oder mehrere müssen erscheinen)

13 Beispiel DTDs

Mittels der folgenden 13 kleinen DTDs soll die Sequenz- und Quantitätskontrolle veranschaulicht werden.

Darstellung einer DTD in der Software Near & Far des Herstellers Microstar.

Eine minimale SGML-DTD besteht aus mindestens einem Element.

 DTD Nr. 1

<!DOCTYPE einfach[
<!ELEMENT einfach - - (#PCDATA)>
]>

Eine SGML-Instanz kann nur Text zwischen dem Wurzelelement „einfach“ haben. Bei weiteren Elementen innerhalb des Dokumentes würde der Parser Fehler melden.

 <einfach>Hallo Welt!</einfach>

Bei der zweiten DTD sollen die Elemente eine bestimmte Reihenfolge einhalten. Erst wenn das erste Element beendet ist, darf das zweite Element folgen und dann erst das dritte. Bei dieser DTD wird der Sequenz-Connector verwendet. 

DTD Nr. 2

<!DOCTYPE Alfred[

<!ELEMENT Alfred - - (a, b, c)>

<!ELEMENT a - - (#PCDATA)>

<!ELEMENT b - - (#PCDATA)>

<!ELEMENT c - - (#PCDATA)>

]>

 Die Instanz muß dann so aussehen:

 <Alfred><a>text</a><b>text</b><c>text</c></Alfred>

In der nächsten DTD wird der Oder-Connector benutzt. Es darf nur eines der drei definierten Elemente erscheinen. 

DTD Nr. 3

<!DOCTYPE Berta[

<!ELEMENT Berta - - (d | e | f)>

<!ELEMENT d - - (#PCDATA)>

<!ELEMENT e - - (#PCDATA)>

<!ELEMENT f - - (#PCDATA)>

]>

 Bei dieser DTD sind nun folgende Instanzen möglich

<Berta><d>text</d></Berta>
<Berta><e>text</e></Berta>
<Berta><f>text</f></Berta>

Die DTD „Dagmar“ verwendet den Und-Connector. Hier ist es möglich, daß die Elemente je einmal in beliebiger Reihenfolge erscheinen.

DTD Nr. 4 

<!DOCTYPE Dagmar[

<!ELEMENT Dagmar - - (g & h & i)>

<!ELEMENT g - - (#PCDATA)>

<!ELEMENT h - - (#PCDATA)>

<!ELEMENT i - - (#PCDATA)>

 Möglichkeiten der DTD:

<Dagmar><i>text</i><h>text</h><g>text</g></Dagmar>

<Dagmar><h>text</h><g>text</g><i>text</i></Dagmar>

<Dagmar><g>text</g><h>text</h><i>text</i></Dagmar>

 Bei der folgenden DTD werden der Sequenz- und der Oder-Connector verwendet. Dabei stellt „m“ eine Alternative zu der Sequenz „j“, „k“ und „l“ dar.

DTD Nr. 5a

<!DOCTYPE Emil[

<!ELEMENT Emil - - ((j, k, l) | m)>

<!ELEMENT j - - (#PCDATA)>

<!ELEMENT k - - (#PCDATA)>

<!ELEMENT l - - (#PCDATA)>

<!ELEMENT m - - (#PCDATA)>

]>

 Als Alternative können wir die DTD auch so schreiben:

 DTD Nr. 5b 

<!DOCTYPE Emil[

<!ELEMENT Emil - - ((j, k, l) | m)>

<!ELEMENT (j, k, l, m) - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Emil><j>text</j><k>text</k><l>text</l></Emil>

<Emil><m>text</m></Emil>

In der DTD „Franziska“ müssen zunächst „n“ und „o“ erscheinen, anschließend muß „p“ oder „q“ folgen.

DTD Nr. 6 

<!DOCTYPE Franziska[

<!ELEMENT Franziska - - (n, o,(p | q))>

<!ELEMENT (u, o, p, q)- - (#PCDATA)>

Möglichkeiten der DTD:

<Franziska><n>text</n><o>text</o><q>text</q>

<Franziska><n>text</n><o>text</o><p>text</p>

Die DTDs 2-6 bezogen sich alle auf die Sequenzkontrolle. Die folgenden DTDs behandeln die Quantitätskontrolle.

In der DTD „Gustav“ muß das Element „a“ erscheinen, daß Element „b“ hingegen ist optional.

DTD Nr. 7 

<!DOCTYPE Gustav[

<!ELEMENT Gustav - - (a, b?)>

<!ELEMENT a - - (#PCDATA)>

<!ELEMENT b - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Gustav><a>text</a></Gustav>

<Gustav><a>text</a><b>text</b></Gustav>

Um das zweite Element beliebig oft zu ermöglichen wird das Fragezeichen durch ein Pluszeichen ersetzt. Hierbei muß das zweite Element mindestens einmal erscheinen (notwendig und wiederholbar).

 DTD Nr. 8 

<!DOCTYPE Hanna[

<!ELEMENT Hanna - - (c, d+)>

<!ELEMENT c - - (#PCDATA)>

<!ELEMENT d - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Hanna><c>text</c><d>text</d></Hanna>

<Hanna><c>text</c><d>text</d><d>text</d></Hanna>

<Hanna><c>text</c><d>text</d><d>text</d><d>text</d></Hanna>

usw.

Um die Vorteile (optional, wiederholbar) der beiden vorherigen DTD zu kombinieren, wird nun das Sternchen angewendet. Dadurch ist es möglich, daß das Element gar nicht erscheint oder beliebig oft.

DTD Nr. 9 

<!DOCTYPE Ingo[

<!ELEMENT Ingo - - (e, f*)>

<!ELEMENT e - - (#PCDATA)>

<!ELEMENT f - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Ingo><e>text</e></Ingo>

<Ingo><e>text</e><f>text</f></Ingo>

<Ingo><e>text</e><f>text</f><f>text</f></Ingo>

<Ingo><e>text</e><f>text</f><f>text</f><f>text</f></Ingo>

usw.

In der folgenden DTD müssen beide Elemente erscheinen oder beide gar nicht.

DTD Nr. 10 

<!DOCTYPE Jutta[

<!ELEMENT Jutta - - (g,h)?>

<!ELEMENT g - - (#PCDATA)>

<!ELEMENT h - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Jutta><g>text</g><h>text</h></Jutta>

<Jutta></Jutta>

 Nun können beide Elemente wiederholbar sein und optional.

DTD Nr. 11 

<!DOCTYPE Karl[

<!ELEMENT Karl - - (i,j)*>

<!ELEMENT i - - (#PCDATA)>

<!ELEMENT j - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Karl></Karl>

<Karl><i>text</i><j>text</j></Karl>

<Karl><i>text</i><j>text</j><i>text</i><j>text</j></Karl>

<Karl><i>text</i><j>text</j><i>text</i><j>text</j><i>text</i><j>text</j>

</Karl>
usw.

Die Elemente „k“ und „l“ sind notwendig und wiederholbar.

DTD Nr. 12

<!DOCTYPE Lydia[

<!ELEMENT Lydia - - (k,l)+>

<!ELEMENT k - - (#PCDATA)>

<!ELEMENT l - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Lydia><k>text</k><l>text</l></Lydia>

<Lydia><k>text</k><l>text</l><k>text</k><l>text</l></Lydia>

<Lydia><k>text</k><l>text</l><k>text</k><l>text</l><k>text</k><l>text</l>

</Lydia>

usw.

Die Elemente können in beliebiger Reihenfolge erscheinen (wiederholbar, optional, beliebige Reihenfolge).

DTD Nr. 13 

<!DOCTYPE Martin[

<!ELEMENT Martin - - (m | n)*>

<!ELEMENT m - - (#PCDATA)>

<!ELEMENT n - - (#PCDATA)>

]>

Möglichkeiten der DTD:

<Martin><m>text</m><n>text</n><m>text</m></Martin>

<Martin></Martin>

<Martin><m>text</m><n>text</n><m>text</m><n>text</n><n>text</n><m>text

</m><m>text</m></Martin>