Informationsdarstellung mit XML

1. Informationsdarstellung mit XML Klaus Becker 2008

2. Ziele und Inhalte <?xml version="1.0" encoding="ISO-8859-1"?> <Fortbildung> <Titel>Informationsdarstellung mit XML</Titel> <Ziele> <Ziel>XML - ein Thema für den Informatikunterricht</Ziel> <Ziel>Einblick in XML</Ziel> </Ziele> <Inhalte> <Inhalt>Schach dem König</Inhalt> <Inhalt>Datenformate - Ein Blick hinter die Kulissen</Inhalt> <Inhalt>Grundlagen von XML</Inhalt> <Inhalt>Dokumenttypen und ihre Validierung</Inhalt> <Inhalt>XML-Vokabulare</Inhalt> <Inhalt>Exkurs: Namensräume, Formatierung, ...</Inhalt> <Inhalt>Verarbeitung von XML-Dokumenten</Inhalt> <Inhalt>XML im Informatikunterricht</Inhalt> </Inhalte> </Fortbildung>

3. Teil 1 Schach dem König

4. Schach-Spielzustände Oktober 1999: "Garri Kasparow setzt die Welt matt." "Die Welt ist doch noch matt gegangen. Nach 62 Zügen hat sich der beste Schachspieler des Planeten, Garri Kasparow, im Internet gegen mehr als 3,5 Millionen Gegner durchgesetzt. ... " siehe: http://www.rochadekuppenheim.de/meko/diewelt.html Nach 29 Zügen ist auf dem Schachbrett folgender Spielzustand entstanden. Kasparow (weiß) ist jetzt am Zug.

5. Schach-Spielzustände Möglichkeiten zur Fortsetzung der Partie sollen mit verschiedenen Schachprogrammen durchgespielt werden. Der gewünschte Spielzustand wird hierzu rekonstruiert und abgespeichert.

6. Schach-Spielzustände Will man den gespeicherten Spielzustand mit anderen Schachprogrammen verwenden, so ergeben sich Schwierigkeiten.

7. Schach-Spielzustände Ein Blick hinter die Kulissen soll klären, wodurch die Schwierigkeiten zustande kommen.

8. Schach-Spielzustände Die Programme benutzen unterschiedliche Speicherformate. ........ .p.kpQ.. ..np.... .p..b.BP ..q..p.. ........ .....PP. .....RK. W0000 8/1p1kpQ2/2np4/1p2b1BP/2q2p2/8/5PP1/5RK1 w -- - 1 30

9. Schach-Spielzustände schwarze Figuren: Bauer: (p)awn Turm: (r)ook Springer: k(n)ight Läufer: (b)ishop Dame: (q)ueen König: (k)ing weiße Figuren: Bauer: (P)awn Turm: (R)ook Springer: k(N)ight Läufer: (B)ishop Dame: (Q)ueen König: (K)ing ........ .p.kpQ.. ..np.... .p..b.BP ..q..p.. ........ .....PP. .....RK. W0000

10. Schach-Spielzustände schwarze Figuren: Bauer: (p)awn Turm: (r)ook Springer: k(n)ight Läufer: (b)ishop Dame: (q)ueen König: (k)ing weiße Figuren: Bauer: (P)awn Turm: (R)ook Springer: k(N)ight Läufer: (B)ishop Dame: (Q)ueen König: (K)ing 8/1p1kpQ2/2np4/1p2b1BP/2q2p2/8/5PP1/5RK1 w -- - 1 30

11. Schach-Spielzustände Die Forsyth-Edwards-Notation (FEN) oder in der erweiterten Form (X-FEN) ist eine Kurznotation, mit der jede beliebige Brettstellung im Schach niedergeschrieben werden kann. siehe: http://de.wikipedia.org/wiki/Forsyth-Edwards-Notation Die FEN ist in 6 Gruppen aufgeteilt, die durch Leerzeichen getrennt sind (in EBNF): FEN := Position " " Spieler " " Rochade " " en-passant " " Halbzüge " " Zugnummer Beispiel: Die Grundstellung des Schachbrettes in FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

12. Schach-Spielzustände "Weiß ist am Zug. ..." Information Zur Darstellung der Information (Brettstellungen im Schach) wird eine formale Sprache (FEN) benutzt. Repräsentieren Darstellen Die Wörter dieser Sprache müssen nach bestimmten Regeln gebildet werden. Diese Regeln legen die Syntax der Sprache fest. Daten rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

13. Schach-Spielzustände "Weiß ist am Zug. ..." Information Zur Darstellung der Information (Brettstellungen im Schach) wird eine formale Sprache (FEN) benutzt. Interpretieren Deuten Schachexperten (und manche Schachprogramme) verstehen diese Sprache. Sie können zu den Wörtern der Sprache die entsprechenden Brettstellungen erzeugen und somit die Bedeutung / Semantik der Wörter erschließen. Daten rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

14. Schach-Spielzustände http://de.wikipedia.org/wiki/Bild:Meister_der_Weltenchronik_001.jpg Neben der FEN gibt es andere Sprachen zur Beschreibung von Brettstellungen im Schach. Wünschenswert ist eine Standardisierung der Sprachen, um eine babylonische Sprachverwirrung zu vermeiden. http://de.wikipedia.org/wiki/Bild:Brueghel-tower-of-babel.jpg ........ .p.kpQ.. ..np.... .p..b.BP ..q..p.. ........ .....PP. .....RK. W0000 rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

15. Aufgabe Neben speziellen Spielzuständen ermöglichen Schachprogramme es auch, den Spielverlauf zu speichern. Schauen Sie auch hier hinter die Kulissen und erkunden Sie die Sprache PGN (Portable Game Notation).

17. Teil 2 Datenformate - Ein Blick hinter die Kulissen

18. Darstellung von Schachspielen Unten finden Sie verschiedene Formate zur Darstellung von Schachspielen. Welche Vor- und Nachteile haben diese Darstellungen? [Event "F/S Return Match"] [Site "Belgrade, Serbia JUG"] [Date "1992.11.04"] [Round "29"] [White "Fischer, Robert J."] [Black "Spassky, Boris V."] [Result "1/2-1/2"] 1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2 Quelle: Wikipedia ChessGML PGN

19. Datenformate für Schachspiele ChessGML: The Why and Wherefore Andreas Saremba Chapter 1. Brave new chess world Computers and the Internet have revolutionized the way how chess games are communicated to the public. ... Besides the two reasons everyone knows and acknowledges, the triumph of the Internet and the enormous development of chess database programs, there was one factor that was equally important for this development: A common language for the encoding of chess games. It is Stephen J. Edward's merit that such a language exists; he not only perceived the need for a lingua franca of the chess world but defined and implemented it in a strict and concise way. In short time PGN (Portable Game Notation) has become indispensable, and no chess software can afford not to be able to read and write this format. So why would anybody be foolish enough to propose something different? Chapter 2. On closer inspection, however ... The joy about the undeniable progress the chess world has made has blurred the view for some aspects of the situation that are a bit less obvious. Let us look at a few examples: - While you can get an ocean of uncommented games on the Internet, there is a remarkable lack of commented ones. I this due to mystery mongery, is it indolence or are there other reasons? - ... - There is a remarkable lack of quality and consistency in the published PGN files. For example, more often than not you will find several spellings of a player's name in one file, making it impossible to perform simple automatic processing like building a tournament table or gathering of statistical data. It is my conviction that the primary reason for these and other insufficiencies is the lack of an interchange format for chess that is not only open but also powerful. ... (Quelle: http://www.saremba.de/chessgml/why.htm)

20. Datenformate für Schachspiele Subject: XMl for chess Date: 2004-08-29 16:09:25 From: KymFarnik As a Chess player of many years and an IT Professional the idea of a new (XML) text game format is not a good idea. Why you ask? PGN is both human and machine readable. It is *very* easy for a human to read and that is the reason it is so successful and no one has 'updated' the spec since '96. PGN uses SAN. SAN is the official way players record their moves in a tourney. PGN adds some headers and a terminator (*, 1-0, 0-1 1/2-1/2). PGN allows the insertion of comments {} and nested variations (). As a Chess player what more do you need? The problem with any XML format is the tagging and the fact that Chess players need a readable text format. The fact that the de-facto PGN standards has lived without change for so long is a huge indication of stability and usefulness. I have a database of 3.4million games (using the Scid product) and have loaded all collected games from PGN! PGN is good for Email Chess as it is easily paresed by tools and readable by the players at the same time. *If aint broken - dont 'fix' it* Regards, kym Quelle: http://www.xml.com/cs/user/view/cs_msg/2194

21. Textverarbeitung Mit OpenOffice wurde ein Text über den Kölner Dom erstellt und anschließend in verschiedenen Ausgabeformaten abgespeichert ... Der digitale Dom Der Kölner Dom ist so etwas wie ein Star. Ein Meisterwerk, sagen Architekten. Eine Perle, sagen Historiker. Ein Glücksfall, sagen Archäologen. Das berühmteste Bauwerk seiner Epoche, der Gotik, und das Markenzeichen seiner Stadt. Kaum eine andere Kirche ist im Lauf der Zeit fotografisch so ausführlich dokumentiert worden wie der Kölner Dom. All diese Bilddokumente sollen demnächst per Mausklick abrufbar sein für eine virtuelle Entdeckungsreise. Mehrere tausend Fotos lagern dann in der eigens eingerichteten Bilddatenbank. Gescannt, im Computer digitalisiert- also in Nullen und Einsen verwandelt und als größere oder kleinere Datenpakete abgelegt. Auch der berühmte mittelalterliche Bauplan kommt dann per Klick auf den Bildschirm: Die Ansicht der Westfassade, der so genannte "Riss F". Der Originalbauplan ist eine Kostbarkeit und lagert lichtgeschützt im Inneren des Doms. 750 Jahre hat es überdauert: Tinte auf Pergament, die Vision des Baumeister im 13. Jahrhundert. Lesbar ist es auch heute noch. Denn der originale Bauplan wurde nicht codiert oder in Nullen und Einsen zerlegt. Nur deshalb konnte der Kölner Dom so erbaut werden, wie wir ihn heute kennen.

22. Darstellung des Textes ... als MS-Word-Datei im doc-Format (siehe "dom_koeln.doc"). Mit einem Text-Editor geöffnet sieht diese Datei so aus:

23. Darstellung des Textes ... als OpenOffice-Datei (siehe "dom_koeln.odt"). Mit einem Text-Editor geöffnet sieht diese Datei noch unverständlicher aus.

24. Darstellung des Textes Wenn man die von OpenOffice erzeugte Datei "dom_koeln.odt" entpackt, klärt sich einiges (siehe "content.xml").

25. Darstellung des Textes ... als DocBook-Datei (siehe "dom_koeln.xml"). Hier kann man deutlich die Struktur des Textes ablesen.

26. Formate zur Informationsdarstellung Repräsentieren Repräsentieren Interpretieren Interpretieren doc:proprietäres Format ODF:standardisiertes Format

27. Standardisierte Formate Macht über die Dokumente ODF ist ein lizenzfreier Standard und seit 2006 als internationale Norm ISO/IEC 26300 veröffentlicht. Zu diesen De-Facto-Standards zählt beispielsweise das Doc- oder Xls-Format von Microsoft. Software-Programme dürfen diese Formate nur laden, wenn der Hersteller für die Programme auch eine Lizenz von Microsoft kauft. Das Doc-Format konkurriert mit dem Open Document Format for Office Applications (ODF), einem Dokumentformat für den Austausch von Daten zwischen Büroanwendungen. ODF ist, im Gegensatz zu den Microsoft-Formaten, ein lizenzfreier Standard, der vielfältig interoperabel ist. Produkte, die den Standard verwenden sind unter anderem die Büro-Software-Pakete Openoffice, Staroffice, Neooffice und Koffice. Hinzu kommt die Online-Text- und Tabellenverarbeitung von Google. Über externe Plug-Ins wird auch der ODF-Import und -Export in Microsoft-Office-Anwendungen wie Word oder Excel unterstützt. Streit um Anerkennung Für Unternehmen und Behörden liegt damit der wirtschaftliche Nutzen von ODF auf der Hand. Anders als bei Microsoft fallen nämlich keine Lizenzgebühren an. In den letzten Jahren stiegen viele Organisationen aus Kostengründen sowie aus Gründen der Interoperabilität auf quelloffene Software-Produkte sowie auf den ODF-Standard für Daten- und Dateiaustausch um. Das wiederum konnte Microsoft nicht gefallen. Im Zuge der Einführung von Office 2007 beschloss der Computer-Konzern aus Redmond, das bisherige Doc- und Xls-Format durch das OOXML-Dateiformat (Open Office Extended Markup Language) abzulösen. Gleichzeitig wollte der Software-Konzern das neue Format als ISO-Standard anerkennen lassen, ohne jedoch etwaige Patentrechte daran aufzugeben. http://www.cio.de/knowledgecenter/open_source/852833/index3.html

28. Standardisierung Es war wie ein verrücktes Fussballspiel. Die eine Mannschaft gehört einem reichen Konzern, die andere bestand aus brillanten, unabhängigen, aber mittellosen Spielern. Als die reiche Mannschaft zu verlieren drohte, schickte der Konzern mehr Spieler aufs Feld - und es gab keine Regel, die ihn daran hindern konnte. Am Ende standen einem freien Spieler fast vier Konzernspieler gegenüber. Der Kampf schien am Dienstag gelaufen. Hans Rudolf Thomann sagte gegenüber der WOZ: «Wir haben entschieden: Die Schweiz empfiehlt, Open XML von Microsoft als internationalen Standard anzuerkennen.» Thomann sagte noch, das dürfe nicht vor Donnerstag kommuniziert werden, es sei eine heisse Sache. Thomann ist ein wichtiger Mann: Er leitet das offizielle Schweizer ExpertInnenkomitee, das über die Microsoft-Frage zu befinden hat. ... Es geht um die Frage, wie ein Computerdokument verpackt sein soll, damit es später auch mit Programmen geöffnet werden kann, mit denen es nicht erstellt wurde. Firmen, aber auch Behörden, die ihre Dokumente elektronisch ablegen wollen, verursacht dieses Problem Kopfzerbrechen. Ein elektronisches Archiv ist nur brauchbar, wenn sich die archivierten Texte auch nach Jahren noch öffnen lassen, sonst sind sie für immer verloren. Um das zu vermeiden, braucht es einen Standard, der festlegt, wie die Datenstruktur eines Textes oder einer Tabelle aussehen muss. Der Standard muss einfach und für alle offen zugänglich sein, sonst kann er ja nicht in jede neue Software eingebaut werden. Ein solcher Computerstandard existiert bereits, er heisst Open Document Format (ODF), wurde von unabhängigen Softwareleuten entwickelt und im Mai 2006 von der internationalen Zertifizierungsbehörde ISO anerkannt. http://www.woz.ch/artikel/2007/nr35/schweiz/15329.html

29. Standardisierung http://www.wdr.de/tv/q21/1058.0.phtml Die Geschichte des Kölner Doms beginnt im Jahre 1248 mit der Grundsteinlegung für den Chor, der gigantisch war für mittelalterliche Maßstäbe. Es folgten der Abriss des alten Langhauses, die Arbeit an den Westtürmen - auch deren Ausmaße sprengten die damals üblichen Dimensionen. Allein diese Bauarbeiten dauern drei ganze Jahrhunderte, während derer man sich konsequent an die alten Baupläne hielt. Digital verschlüsselte Daten auf nicht beständigen Datenträgern wären zu dem Zeitpunkt längst unlesbar gewesen. Doch im 16. Jahrhundert kommen die Bauarbeiten am Großprojekt Dom zum Erliegen. Die genaue Ursache ist bis heute unbekannt. Der Dom bleibt unvollendet, eine Bauruine, und zwar ganze 300 Jahre lang. Erst zu Beginn des 19. Jahrhunderts kommt plötzlich wieder Bewegung in das Projekt "Dom". Und noch immer existiert der mittelalterliche Bauplan. 600 Jahre ist er mittlerweile alt. Das Pergament brüchig, die Tinte vergilbt und - uncodiert. Und damit ohne jegliche Software oder Hardware lesbar. Wäre er digital gespeichert gewesen, wohl niemand hätte nach sechs Jahrhunderten geschafft, ihn zu lesen. Doch mit einem Plan aus Tinte und Pergament war es kein Problem, den Dom bis zum Ende des 19. Jahrhunderts genau so zu vollenden, wie es sich sein visionärer mittelalterlicher Baumeister einst ausgedacht hat.

30. Standardisierung Users tend to think about software in terms of functionality and usability; they use to under-estimate the importance of data formats. How should they know better – it is the very purpose of good software to provide a wealth of functions while hiding the (necessary) complexity of the underlying data from the innocent user. After all, nobody cares for the bits and bytes that are scribbled on the disk. In fact, everybody should care. Not for the details of the bits and bytes, of course, but for their data. They are, after all, for what all the effort is made. You may not have noticed so far that data in a proprietary (i.e. vendor-specific) format is less valuable than data in an open and standardized format. But you will notice this once you try to switch to a different software, only to learn that you have to say Goodbye to most of your data because they cannot be read by the new program. A comparable, although less dramatic situation will occur when you try to send your data to somebody else who does not happen to use the same software as you do. The usual justification offered by software vendors says they have to use their own format because it's highly optimized for the particular needs of their program and that it saves both processing time and (main memory as well as disk) space. This would be more convincing if they wouldn't, at the same time, try to keep their formats secret by not documenting them or by even encrypting the data. http://www.saremba.de/chessgml/why.htm

31. Informationsdarstellung mit XML Information kann auf ganz unterschiedliche Weise dargestellt und auch strukturiert werden. XML (eXtensible Markup Language) bietet eine Art Standard zur strukturierten Darstellung von Information, den inzwischen sehr viele Werkzeuge nutzen. Repräsentieren Repräsentieren Interpretieren Interpretieren <?xml version="1.0" encoding="UTF-8"?> <nsc version="0.2"> <sequence> ... </sequence> </nsc>

32. Aufgabe Mit Hilfe von verschiedenen Struktogramm-Editoren wurde der Algorithmus zur Berechnung des ggT in Struktogrammform dargestellt. Vergleichen Sie die benutzten Datenformate. Öffnen Sie hierzu die Dateien mit einem Editor. StruktEdit NSCEdit

33. Datenformate für Struktogramme StruktEdit-Datei betrachtet mit einem Hex-Editor NSCEdit-Datei betrachtet mit einem Text-Editor

34. Aufgabe Das Simulationsprogramm JFlap wurde in den letzten Jahren mehrfach überarbeitet und weiterentwickelt. Insbesondere wurde auch das Speicherformat verändert. Vergleichen Sie das von JFlap40b8 und JFlap40b14 benutzte Format.

35. Datenformate für Automaten erstellt mit JFlap40b8 erstellt mit JFlap40b14

36. Aufgabe Erstellen Sie mit GeoGebra eine Zeichnung und speichern Sie diese unter einem geeigneten Dateinamen (z. B. "ableitung.ggb") ab. Entpacken Sie anschließend diese Datei und schauen Sie sich die entpackte Datei mit einem Editor an.

37. Datenformat für geometrische Konstr. ...<construction title="" author="" date=""><expression label ="f" exp="f(x) = x^(2) - x + 2"/><element type="function" label="f"> <show object="true" label="true"/> <objColor r="0" g="0" b="0" alpha="0.0"/> <labelMode val="0"/> <animation step="0.1"/> <fixed val="false"/> <breakpoint val="false"/> <lineStyle thickness="2" type="0"/></element>...<element type="point" label="A"> <show object="true" label="true"/> <objColor r="125" g="125" b="255" alpha="0.0"/> <labelMode val="0"/> <animation step="0.1"/> <fixed val="false"/> <breakpoint val="false"/> <coords x="1.4" y="2.5599999999999996" z="1.0"/> ...</element>... hinter den Kulissen von GeoGebra

38. Aufgabe Das folgende XML-Dokument soll den aktuellen Schach-Spielzustand darstellen. Welche Vor- und Nachteile hat diese Darstellung? 8/1p1kpQ2/2np4/1p2b1BP/2q2p2/8/5PP1/5RK1 w -- - 1 30 <?xml version="1.0" encoding="iso-8859-1"?> <Schach-Spielzustand> <schwarz> <Bauer>b7</Bauer> <Bauer>e7</Bauer> <Bauer>d6</Bauer> <Bauer>b5</Bauer> <Bauer>f4</Bauer> <Springer>c6</Springer> <Läufer>e5</Läufer> <Dame>c4</Dame> <König>d7</König> </schwarz> <weiss> <Bauer>h5</Bauer> <Bauer>f2</Bauer> <Bauer>g2</Bauer> <Läufer>f5</Läufer> <Turm>f1</Turm> <Dame>f7</Dame> <König>g1</König> <amZug/> </weiss> </Schach-Spielzustand>

39. Aufgabe Ist XML ein guter Standard? Lesen Sie die folgenden Textauszüge. Als "beste Erfindung seit der Kreide" feierte ein Kommentator einmal XML, und dieser Vergleich trifft nicht schlecht: Beide Schreibwerkzeuge sind technisch unkompliziert, praktisch umsonst nutzbar, und beide helfen gerade dort, wo mehrere Parteien Information teilen wollen. Besonders dort, wo große Datenmengen aus verschiedenen Quellen zusammenfließen, etwa in Schnittbereichen mehrerer wissenschaftlicher Disziplinen oder in der Logistik zwischen Unternehmen und ihren Zulieferern, hat XML sich als mächtiges Werkzeug erwiesen. Inzwischen speichern auch viele Text- und Datenbankprogramme für Heimcomputer ihre Dateien in XML. Trotz des "Language" im Namen ist XML keine Sprache, sondern ein Sprachgerüst, Ähnlich der Grammatik natürlicher Sprachen: Die Regeln von XML legen fest, welche Struktur ein sinnvoller Ausdruck haben muss. Der Wortschatz dagegen bleibt bewusst offen. Er kann für jede Anwendung angepasst werden. Inzwischen sind XML-Dialekte für alle erdenklichen Gebiete entwickelt, vom Versicherungswesen über die biologische Bildgebung bis hin zu Schach. http://www.heise.de/tr/Beste-Erfindung-seit-der-Kreide--/artikel/56485

40. Gute Standards Was ist ein guter Standard? Ein Essay über die Designprinzipien des W3C Autor: Bert BosDeutsche Übersetzung: Michael Jendryschik Binär- oder Textformat Die meisten W3C-Spezifikationen definieren eine formale Sprache zur Beschreibung einer Art von Ressource: HTML beschreibt einfache Text-Dokumente, SVG beschreibt Vektorgrafiken, PNG beschreibt Rastergrafiken, HTTP beschreibt den Dialog zwischen einem Client und einem Server und URLs beschreiben den Pfad zu einer bestimmten Ressource. Es gibt Ausnahmen wie die verschiedenen WAI-Richtlinien, die Meta-Regeln beschreiben, wie Programme und Spezifikationen entworfen werden sollten (ein wenig wie dieser Essay, allerdings präziser...). Aber die meisten Menschen, die an W3C-Spezifikationen arbeiten, stehen am Anfang vor der Frage: Sollen wir ein Binär- oder ein Textformat entwerfen? In den meisten Fällen wird die Antwort »Textformat« lauten, denn Textformate sind einfacher zu laden, und Fehler lassen sich leichter finden und beseitigen: man kann Dateien mit einem Texteditor erzeugen, sodass der Entwurf eines geeigneten Editors oder Konverters auf einen späteren Zeitpunkt verschoben werden kann; man kann eine Datei überprüfen, um zu sehen, was passiert ist, wenn ein Programm nicht das macht, was man erwartet hat; und nicht zuletzt: wenn die Spezifikation in etwa 50 Jahren versehentlich verloren gegangen ist, gibt es eine Chance, allein durch das Analysieren einiger Dateien ausreichend viel von der Spezifikation zu rekonstruieren, um die essentiellen Informationen zurückzugewinnen. (Das wird manchmal, wohl eher optimistisch, »selbstbeschreibend« genannt. Das Format würde nur dann wirklich selbstbeschreibend sein, wenn jede Datei den Text der Spezifikation mit einbände...) http://jendryschik.de/wsdev/trans/designguide/

41. Gute Standards Was ist ein guter Standard? Ein Essay über die Designprinzipien des W3C Autor: Bert BosDeutsche Übersetzung: Michael Jendryschik Lesbarkeit Eine Notation kann zu kurz sein. Wenn der Name einer selten verwendeten Funktion nur aus einem Buchstaben besteht (»t«), dann muss man sie womöglich die wenigen Male, die man sie sieht, nachschlagen, wenn man alle Buchstaben nicht auswendig komplett überblickt. Ein komplettes Wort (»translate«) ist da die bessere Lösung. Eine Notation kann auch zu lang sein. Wenn ein Schlüsselwort, das man sehr oft verwendet, 20 Zeichen lang ist (»shapeoutlinedata«), dann sollte es womöglich besser abgekürzt werden (»d«). Diese Beispiele habe ich aus SVG (das die richtigen Bezeichnungen gewählt hat) entnommen, aber man kann ähnliche Fälle in den meisten Sprachen finden. Bedauerlicherweise stellen sich die besten Vermutungen als falsch heraus. Die Designer von XML dachten, es wäre hilfreich, ein Element mit dem vollen Elementnamen zu öffnen und zu schließen (<heading>...</heading>), und für die Verwendung, die sie voraussahen, war das in der Tat vollkommen angemessen: in langen Texten mit wenig Markup ist die geringe Menge an Redundanz, die hinzukommt, gegenüber der Möglichkeit, zu sehen, welches Element geschlossen wird, zu vernachlässigen [XMLgoals]. Sie dachten, eine kürzere Form (etwa </> oder <>) zu erlauben, würde die Komplexität der Sprache erhöhen. Heute wird XML allerdings häufiger für Daten benutzt, deren Markup den eingeschlossene Inhalt übersteigt, und die vielen Start-Tags, die direkt End-Tags des gleichen Elementtyps folgen, verstecken die wesentliche Information durch ihre Redundanz. XML ist dadurch nicht kaputt, aber im Nachhinein betrachtet, hätte es so gestaltet werden können, dass dessen Verwendung nicht mit solchen Problemen verbunden ist. http://jendryschik.de/wsdev/trans/designguide/

42. Aufgabe Verschaffen Sie sich einen ersten Überblick über XML. Lesen Sie sich hierzu die Seite "XML in 10 Punkten" durch. 1. XML steht für strukturierte Daten2. XML sieht ein wenig wie HTML aus3. XML ist Text, aber nicht zum Lesen4. XML ist vom Design her ausführlich5. XML ist eine Familie von Techniken6. XML ist neu, aber nicht so neu7. XML überführt HTML in XHTML8. XML ist modular9. XML ist die Basis für RDF und das Semantic Web10. XML ist lizenzfrei, plattformunabhängig und gut unterstützt siehe: http://www.w3c.de/Misc/XML-in-10-Punkten.html

43. Teil 3 Grundlagen von XML

44. Strukturierte Darstellung v. Information XML-Dokumente werden benutzt, um Information strukturiert darzustellen. <?xml version="1.0" encoding="iso-8859-1"?> <Schach-Spielzustand> <schwarz> <Bauer>b7</Bauer> <Bauer>e7</Bauer> <Bauer>d6</Bauer> <Bauer>b5</Bauer> <Bauer>f4</Bauer> <Springer>c6</Springer> <Läufer>e5</Läufer> <Dame>c4</Dame> <König>d7</König> </schwarz> <weiss> <Bauer>h5</Bauer> <Bauer>f2</Bauer> <Bauer>g2</Bauer> <Läufer>f5</Läufer> <Turm>f1</Turm> <Dame>f7</Dame> <König>g1</König> <amZug/> </weiss> </Schach-Spielzustand> <?xml version="1.0" encoding="iso-8859-1"?> <Schach-Spielzustand> <!--Spieler mit schwarzen Figuren--> <schwarz amZug="nein"> <Bauer Spalte="b" Zeile="7"/> <Bauer Spalte="e" Zeile="7"/> <Bauer Spalte="d" Zeile="6"/> <Bauer Spalte="b" Zeile="5"/> <Bauer Spalte="f" Zeile="4"/> <Springer Spalte="c" Zeile="6"/> <Läufer Spalte="e" Zeile="5"/> <Dame Spalte="c" Zeile="4"/> <König Spalte="d" Zeile="7"/> </schwarz> <!--Spieler mit weißen Figuren--> <weiss amZug="ja"> <Bauer Spalte="h" Zeile="5"/> <Bauer Spalte="f" Zeile="2"/> <Bauer Spalte="g" Zeile="2"/> <Läufer Spalte="f" Zeile="5"/> <Turm Spalte="f" Zeile="1"/> <Dame Spalte="f" Zeile="7"/> <König Spalte="g" Zeile="1"/> </weiss> </Schach-Spielzustand>

45. Hierarchische Baumstruktur Die Strukturierung erfolgt in Form eines Baumes. <?xml version="1.0" encoding="iso-8859-1"?> <Schach-Spielzustand> <schwarz> <Bauer>b7</Bauer> <Bauer>e7</Bauer> <Bauer>d6</Bauer> <Bauer>b5</Bauer> <Bauer>f4</Bauer> <Springer>c6</Springer> <Läufer>e5</Läufer> <Dame>c4</Dame> <König>d7</König> </schwarz> <weiss> <Bauer>h5</Bauer> <Bauer>f2</Bauer> <Bauer>g2</Bauer> <Läufer>f5</Läufer> <Turm>f1</Turm> <Dame>f7</Dame> <König>g1</König> <amZug/> </weiss> </Schach-Spielzustand> Darstellung im Editor Anzeige mit einem Browser

46. Der Baum der Elemente • Grundbausteine eines XML-Dokuments sind die XML-Elemente. • Ein (XML-) Element wird mit Hilfe von Tags (Anfangs- und Endtag) markiert. • Ein Element kann selbst wieder Elemente enthalten (Container) oder nur noch Zeichen (eigentliche Daten) oder beides. • Das erste Element eines XML-Dokuments ist das Wurzelelement, das alle anderen Elemente in sich einschließt. Wurzelelement Element als Container Element mit Zeicheninhalt Ein XML-Dokument vermischt Inhalte mit Informationen über diese Inhalte (Meta-Information).

47. Tags • Mit Hilfe von Tags werden die verschiedenen Elemente begrenzt. Verschiedene Tags markieren dabei unterschiedliche Elementtypen. • Tags werden (wie bei HTML) mit spitzen Klammern gebildet. Die Tag-Namen sind (fast) frei wählbar. • Anfangs- und Endtag müssen immer exakt zueinander passen. Dabei wird auf Groß- und Kleinschreibung geachtet. • Tags müssen korrekte geschachtelt werden. • Bei einem leeren Element wird i. d. Regel eine verkürzte Tag-Schreibweise benutzt. Anfangstag Endtag leeres Element

48. Attribute • Elemente können mit Hilfe von Attributen näher beschrieben werden. Attribute können dabei zusätzliche Informationen über den Inhalt eines Elements liefern, ohne selbst Teil des Inhalts zu sein. Jedem Attribut muss ein bestimmter Wert zugewiesen werden, der in Anführungszeichen geschrieben wird. Attribut Attributwert

49. Kommentare • Kommentare erleichtern das Verständnis und werden vom Browser mit angezeigt. <?xml version="1.0" encoding="iso-8859-1"?> <Schach-Spielzustand> <!--Spieler mit schwarzen Figuren--> <schwarz amZug="nein"> <Bauer Spalte="b" Zeile="7"/> <Bauer Spalte="e" Zeile="7"/> <Bauer Spalte="d" Zeile="6"/> <Bauer Spalte="b" Zeile="5"/> <Bauer Spalte="f" Zeile="4"/> <Springer Spalte="c" Zeile="6"/> <Läufer Spalte="e" Zeile="5"/> <Dame Spalte="c" Zeile="4"/> <König Spalte="d" Zeile="7"/> </schwarz> <!--Spieler mit weißen Figuren--> <weiss amZug="ja"> <Bauer Spalte="h" Zeile="5"/> <Bauer Spalte="f" Zeile="2"/> <Bauer Spalte="g" Zeile="2"/> <Läufer Spalte="f" Zeile="5"/> <Turm Spalte="f" Zeile="1"/> <Dame Spalte="f" Zeile="7"/> <König Spalte="g" Zeile="1"/> </weiss> </Schach-Spielzustand> Kommentar

50. Prolog • Ein XML-Dokument beginnt in der Regel mit dem Prolog <?xml ... ?>. Der Prolog sollte hier stehen, um das Dokument als XML-Dokument zu kennzeichnen. <?xml version="1.0" encoding="iso-8859-1"?> <Schach-Spielzustand> <!--Spieler mit schwarzen Figuren--> <schwarz amZug="nein"> <Bauer Spalte="b" Zeile="7"/> <Bauer Spalte="e" Zeile="7"/> <Bauer Spalte="d" Zeile="6"/> <Bauer Spalte="b" Zeile="5"/> <Bauer Spalte="f" Zeile="4"/> <Springer Spalte="c" Zeile="6"/> <Läufer Spalte="e" Zeile="5"/> <Dame Spalte="c" Zeile="4"/> <König Spalte="d" Zeile="7"/> </schwarz> <!--Spieler mit weißen Figuren--> <weiss amZug="ja"> <Bauer Spalte="h" Zeile="5"/> <Bauer Spalte="f" Zeile="2"/> <Bauer Spalte="g" Zeile="2"/> <Läufer Spalte="f" Zeile="5"/> <Turm Spalte="f" Zeile="1"/> <Dame Spalte="f" Zeile="7"/> <König Spalte="g" Zeile="1"/> </weiss> </Schach-Spielzustand> • Im Prolog kann der Zeichensatz festgelegt werden, der zur Kodierung benutzt wird. Fehlt die Angabe des Zeichensatzes, so wird UTF-8 als Vorgabe benutzt. Wenn deutsche Umlaute korrekt dargestellt werden sollen, sollte man den Zeichensatz ISO-8859-1 verwenden.