![[LinuxFocus-icon]](../../common/images/logolftop.gif){kind=small} |
|
|
 |
|
| Dieses Dokument ist verfübar auf: English Castellano Deutsch Francais Italiano Nederlands Portugues Russian Turkce |
![[Photo of the Author]](../../common/images/EgonWillighagen.jpg)
von Egon Willighagen Über den Autor: Egon erhält dieses Jahr seinen Masters und wird dann mit seiner
Doktorarbeit in Chemie beginnen. Ansonsten mag er Basktball
sowie LinuxFocus und Linux im allgemeinen.
|
![[Illustration]](../../common/images/illustration206.jpg){kind=small}
Zusammenfassung:
Dieser Artikel enthält die Präsentation, die Egon während des Libre Software Meetings in Bordeaux gegeben hat. Er erklärt die XML Datenbank, die für die automatische Generierung der LinuxFocus.org(/Nederlands) Webseite benutzt wird.
Das für die Dokumentations- und Übersetzungsverwaltung benutzte System beim LinuxFocus Projekt besteht aus einigen ASCII Dateien, einschließlich resdb.txt, issuedb.txt und maindb.txt. Diese Dateien haben ein festes Format und sie werden benutzt, um Webseiten zu generieren. Sie sind jedoch schwierig zu erweitern und die getrennte Natur der Daten macht es schwierig, alle Informationen, die zu einem Artikel verfügbar sind, zu verwalten.
LinuxFocus hat nicht viel Webinhalt automatisch generiert als ich mit der neuen Datenbank anfing. Als Redaktuer des holländischen Teams wollte ich unbedingt die index.html Dateien auf der Webseite dynamisch generieren. Jedes Mal einige HTML Dateien editieren zu müssen, wenn ein neuer Artikel übersetzt war, verschlang eine Menge Zeit und verursachte viele zerbrochene Links. Deshalb wollte ich ein neues System, zu dem ich Informationen leicht hinzufügen konnte und von dem aus ich auf einfache Weise Indexseiten für die Webseite erzeugen konnte. Ich begann im Sommer 2000 daran zu arbeiten.
Die Wahl für XML war ein bißchen willkürlich. Es gab Vorschläge, eine relationale Datenbank zu benutzen, aber ich hatte Erfahrung in XML und bevorzugte ein System mit textbasierten Dateien. Es zeigte sich bald, daß ein neues Nummerierungsschema nützlich sein würde, da die Datenbank dann einen ID Typ benutzen konnte, statt der 2 oder 3 Schematas, die dann in Gebrauch waren. Guido Socher machte all die Umnummerierungen, was einiges an Arbeit war (vielen Dank!).
Die Document Type Definition (DTD) war bereits in Entwicklung und ein bißchen Inhalt war für Testzwecke in der Datenbank. Mit dem neuen einheitlichen Nummerierungsschema war die Zeit gekommen, um die Datenbank mit Inhalt zu laden. Nachdem ungefähr 20 Artikel hinzugefügt worden waren, wurde klar, daß dies ein enormes Projekt war. Es war möglich, Skripte zu schreiben, um die alten Dateien zu benutzen, aber nicht alle Informationen, die die neue Datenbank aufnehmen konnte, waren verfügbar und, wie erwähnt, waren die verfügbaren Informationenn über mehrere Dateien verteilt. Glücklicherweise kam Floris Lambrechts dazu und ich habe ihm tief zu danken für das Hinzufügen des meisten Inhalts zu der Datenbank. Ohne seine Hilfe wäre das System nicht das, was es heute ist.
Mit dem neuen Format kam die Möglichkeit, neue Informationen hinzuzufügen. Und während des vergangenen Jahres wurden einige neue Arten von Daten zu der Datenbank hinzugefügt. Frühe Erweiterungen waren eine Tabelle mit Autoren, Übersetzern, Editoren und anderen Leuten, die bei LinuxFocus mitmachen sowie Dateispeicherorte. Der Grund für das Hinzufügen des letzten war, daß es seit Beginn von Linuxfocus einige Dateibenennungsschemata gab. Während der Umnummerierung wurden sie auf zwei Schemata reduziert. Einige Dateien benutzen Server Side Includes und benutzen die Erweiterung .shtml, während ältere Artikel die Erweiterung .html benutzen. Der <file> tag kann benutzt werden, um eine Standardeinstellung zu überschreiben. (Die aktuelle Standardeinstellung benutzt das Format "article" + article number (Artikelnummer) + ".shtml". Dies kann ein optionales ".meta" enthalten für den Fall, daß die Datei im meta Format von LinuxFocus vorliegt.)
Jetzt, wo die Datenbank eine kritische Masse erreicht hatte, konnte ich schließlich die Performance der Software, die ich geschrieben hatte, überprüfen. Die jetzigen XSLT Stylesheets sind nicht die erste Implementation. Voraus ging ein auf Perl basierender Code. Aber mit der wachsenden Größe der Datenbank wurde die Performance wichtig. Der erste Versuch war einfach nicht gut genug. Aber bevor ich die Werkzeuge erkläre, werde ich das Datenbankformat erklären.
XML ist zuerst einmal eine Syntaxspezifikation für markup Sprachen. XML definiert, wie das Markup aussehen soll. Die Syntax beschreibt die Folge von Zeichen, die in "gut geformten" XML Dokumenten erlaubt sind. Es erklärt, daß ein Dokument ein Wurzelelement hat und daß ein Element aus einem start tag, Inhalt (Text, Kindelemente oder beides) besteht und einem Endetag. Diese tags bestehen aus einem "<" Zeichen gefolgt von einem Namen und am Ende einem ">" Zeichen. Der Endetag muß noch ein "/" vor dem Namen stehen haben. Leere tags, wie HTML's <br>, haben ein "/" nach dem Namen. Ein start tag darf Attribute enthalten und diese haben auch eine bestimmte Syntax. XML tags sehen so aus:
<greeting>Hello, world!</greeting>oder für einen leeren tag
<br/>
Außer Syntax enthalten Sprachen auch Semantik. Diese beschreibt, wie sich bestimmte Elemente zueinander verhalten. Die Semantik von HTML erklärt, daß der <body> tag im <html> Element enthalten sein soll und nicht umgekehrt. Die Semantik beschreibt auch, daß das <img> Element leer ist genauso wie das <br> Element. Wenn diese Semantik in einer formalen Schreibweise gegeben wird, kann sie mit einem Programm analysiert und dazu benutzt werden, die Dokumente, die diese Semantik benutzen, zu validieren. Eine dieser formalen Schreibweisen wird Document Type Definition, oder kurzr DTD, genannt. Wenn ein Dokument den Validationsprozess überstanden hat, wird es ein wahres Dokument genannt. Man muß mit XML sehr aufpassen, da seine Überprüfung sehr strikt ist.
Jetzt, wo wir wissen, was eine DTD ist, laßt uns einen Blick auf die XML Datenbank DTD von LinuxFocus werfen. Für mehrere der Spezifikationen werden wir ein Beispiel geben. Beim Untersuchen dieser Beispiele wirst du eine Idee davon bekommen, wie die Informationen in der XML Datenbank von LinuxFocus erhalten werden.
Das Wurzelelement in der LinuxFocus XML Datenbank oder eine ihrer Erweiterungen oder Lokalisationen ist das <database> Element.
<!ELEMENT database (themes?, persons?, issues?, articles?)>
Zuerst beachte, daß das "?" bedeutet, daß das Kindelement 0 oder einmal auftreten darf. Auf diese Weise kann die Datenbank Informationen über die Themen, Personen, Ausgaben und Artikel von LinuxFocus haben. Da dies sehr eindeutig ist, gehe ich jetzt zu einem interessanteren Beispiel.
Die Themen sind innerhalb des <themes> Elements enthalten, die ein Kindelement <database> sind. Jedes Thema hat eine eigene ID, einen Titel und optional eine Zusammenfassung und ein Bild.
<!ELEMENT themes (theme+)>
<!ELEMENT theme (title*, desc?, img?)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT desc (#PCDATA)>
<!ELEMENT img (EMPTY)>
Einige dieser Elemente müssen Attribute besitzen. Sie werden auch in der DTD angegeben. Jeder textliche Inhalt ist in einem Element mit dem xml:lang Attribut enthalten. Der Wert dieses Attributs kann jedes Zeichen sein, daß konform zum ISO 3166 Standard für den Ländercode ist. Beispiele sind "en", "fr" und "nl". Beide Attribute, das id und das xml:lang Attribut sind in der Original XML Spezifikation spezifiziert und Teil der XML Syntax.
<!ATTLIST theme id ID #REQUIRED>
<!ATTLIST title xml:lang NMTOKEN #REQUIRED>
<!ATTLIST desc xml:lang NMTOKEN #REQUIRED>
<!ATTLIST img src CDATA #REQUIRED>
Eine Beispieldatenbank sieht z.B. so aus::
<database>
<themes>
<theme id="hw">
<title xml:lang="en">Hardware</title>
<img src="Hardware.jpg"/>
<theme>
<themes>
</database>
Die Ausgaben sind immer im <issues> Element enthalten. Wie die Themen so hat auch jede Ausgabe eine eigene ID.
<!ELEMENT issues (issue+)>
<!ELEMENT issue (title+, published?, file*)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT published (EMPTY)>
<!ELEMENT file (#PCDATA)>
Das Element <published> markiert schon veröffentlichte Ausgaben. Die nächste Ausgabe und die SomeLanguage2Eng pseudo Ausgaben enthalten dieses Element nicht. Das <title> Element hat wiederum ein @xml:lang Attribut. Das <file> Element bedeutet das Verzeichnis, in dem sich die Ausgabe befindet. Es darf nicht auf index.html zeigen, da es dazu benutzt wird, um die Dateilokation zu bestimmen.
Ein Beispiel (beachte, daß wir das @code Attribut zum Sortieren benutzen):
<issue id="ToBeWritten" code="999996">
<title xml:lang="en">Not yet written articles</title>
</issue>
<issue id="September2001" code="200109">
<title xml:lang="en">September2001</title>
</issue>
Informationen über Autoren und Übersetzer sind in den <person> Elementen gespeichert. Jede Person muß eine eigene ID besitzen.
<!ELEMENT persons (person+)>
<!ELEMENT person
((name|email)*,(homepage|nickname|desc|team)*)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT homepage (#PCDATA)>
<!ELEMENT nickname (#PCDATA)>
<!ELEMENT desc (#PCDATA|%html-els;)*>
<!ELEMENT team EMPTY>
Jede Person kann die folgenden Informationen besitzen: einen Namen, eine Emailadresse (oder mehrere), Homepage(s) und Spitznamen. Wenn die Person auch zum Übersetzerteam gehört, fügen wir ein <team> Element hinzu. Zum Beispiel bedeutet die folgende Zeile im <person> Element, daß Floris zum holländischen Team <team xml:lang="nl"/> gehört. Schließlich kann jede Person eine Beschreibung haben, die z.B. zusätzliche Weblinks enthält.
Ein Beispiel:
<person id="nl-ew">
<name>Egon Willighagen</name>
<email>egonw@linuxfocus.org</email>
<team xml:lang="nl"/>
</person>
Die Artikel sind natürlich der interessanteste Teil der Datenbank.
<!ELEMENT articles (article+)>
<!ELEMENT article (title+,
(file|personref|abstract|issueref|themeref|
nometa|nohtml|translation|proofread)*)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT nohtml EMPTY>
<!ELEMENT nometa EMPTY>
<!ELEMENT translation
(personref*, (reserved|finished|proofread)*)>
<!ELEMENT reserved (#PCDATA)>
<!ELEMENT finished (#PCDATA)>
<!ELEMENT proofread (personref*, (reserved|finished)*)>
<!ATTLIST article id ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
type (article|coverpage)
"article"
next IDREF #IMPLIED
prev IDREF #IMPLIED>
<!ATTLIST file xml:lang NMTOKEN #REQUIRED
type (target|meta) "target">
<!ATTLIST translation from NMTOKEN #REQUIRED
to NMTOKEN #REQUIRED>
Jeder Artikel hat zumindestens einen Titel, einen für jede Sprache. Das <file> Element kann dazu benutzt werden, um die Speicheradresse des Artikels anzugeben, für beide, das META Format und die HTML Version (siehe Beispiel unten). In Fällen, wo keine META oder HTML Version verfügbar ist, können die optionalen Elemente <nohtml/> und <nometa/> benutzt werden. Jeder Artikel kann eine Zusammenfassung haben. Wenn sich die Zusammenfassung in der Datenbank befindet, bedeutet das, daß sie dazu benutzt werden kann, um Indexwebseiten zu erstellen.
Das <article> Element hat fünf Attribute: die erforderliche @ID, ein optionales Attribut xml:lang, um die Sprache, in der er ursprünglich geschrieben worden ist, anzugeben, ein @type Attribut, das für die Titelseiten benutzt wird, die für Übersetzungszwecke genauso wie Artikel behandelt werden. Und schließlich zwei weitere optionale Attribute, @next und @prev, um Artikel aus einer Serie zusammenzuhalten.
Ein Artikel gehört zu einer Ausgabe und zu einem Thema mit den <issueref> und <themeref> Elementen, beide haben ein @href Attribut. Der Wert dieses Attributs muß eine eigene ID, die ID der dazugehörigen Ausgabe oder des Themas sein.
Ein Beispiel:
<article id="article206" xml:lang="en">
<title xml:lang="en">Using XML and XSLT to build
LinuxFocus.org(/Nederlands)</title>
<personref href="nl-ew"/>
<issueref href="ToBeWritten"/>
<themeref href="appl"/>
<abstract xml:lang="en">
This article shows you how parts of the Dutch web site of LinuxFocus is
generated with XSLT tools from the XML database. It compares this with
the (very) much slower DOM tools in Perl.
</abstract>
</article>
Ein lokal angepaßtes <article> Element sieht wie folgt aus:
<article id="52">
<title xml:lang="nl">Enlightenment</title>
<file xml:lang="nl">Nederlands/July1998/article52.html</file>
<translation from="en" to="nl">
<personref href="nl-tu"/>
<reserved>2000-09-06</reserved>
<finished>2000-10-04</finished>
<proofread>
<personref href="nl-fl"/>
<reserved>2000-10-04</reserved>
<finished>2000-10-04</finished>
</proofread>
</translation>
<abstract xml:lang="nl">
Enlightenment is een Linux window-manager met
uitgebreide mogelijkheden. Dit artikel bespreekt
ze, samen met de installatie en de instelling
van E. Dit alles is niet voor beginners daar
E op het moment nog in beta-stadium
verkeert.
</abstract>
</article>
Beachte, daß diese Übersetzung für eine Übersetzung zu einem bestimmten Datum reserviert ist, aber auch zum Korrekturlesen. In allen Fällen ist die Person, die die Arbeit gemacht hat, mit den <personref> Elementen verlinkt.
Für alle Elemente ist das beste Tutorium die aktuelle Datenbank selbst:
Einer der Gründe für das Erstellen dieses neuen Formats war das automatische Erzeugen von Webindizes davon. Jetzt, wo wir das Datenbankformat verstehen (?), laßt uns anschauen, wie wir es benutzen können, um Webseiten zu generieren.
Zuerst ein bißchen Geschichte. Die erste Implementation benutzte Perlmodule als Schnittstelle zur Datenbank. Auch wenn die Schnittstelle sehr sauber war, war die Implementation sehr langsam. Die Informationen wurden in einem XML container namens Document Object Model (DOM) erhalten. Die meisten Implementationen für DOM sind jedoch sehr langsam, zumindest langsamer als das alternative Simple Application interface für XML (SAX).
Aber wenn die Aufgabe darin besteht, einfach nur Webseiten zu generieren, scheint eine dritte Alternative das beste zu sein: XSLT. Dies ist eine auf XML basierende Umwandlungssprache. Viele XSLT Prozessoren existieren heutzutage und die meisten Programmiersprachen werden unterstützt. Vor einiger Zeit gab es einen LinuxFocus Artikel Einführung in das PERL XML::XSLT Modul. Seit der Veröffentlichung dieses Artikles sind mehrere Implementationen herausgekommen und es gibt ein paar, die ich empfehle:
Die Beispiele im restlichen Artikel benutzen Sablotron.Ein XSLT Prozessor nimmt zwei Dateien als Eingabe. Einer ist die XML source, die umgewandelt werden muß. Das andere ist das XSLT Stylesheet, das die Umformung definiert. Für Generationen von LinuxFocus Webseiten sind die folgenden XSLT Stylesheets verfügbar:
Um z.B. die mainindex.html Seite zu generieren, läßt das holländische Team den folgenden Befehl laufen:
sabcmd stylesheets/mainindex.xslt db/lfdb.nl.xml > ../mainindex.html
Die Stylesheets wissen, wo sich die englische Wurzeldatenbank befindet und brauchen nur die lokale Datenbank als XML Eingabe. Einige Sheets brauchen einen zusätzlichen Parameter:
sabcmd stylesheets/theme.xslt db/lfdb.nl.xml '$theme=appl' > ../Themes/appl.html
Die holländische index.html Seite wird auch von der Datenbank erzeugt, benutzt aber ein etwas komplexeres Setup. Die index.html Seite wird mit Guidos lfpagecomposer von einem Set vorbearbeiteter Eingabedateien gemacht. Und diese vorbearbeiteten Eingabedateien werden von einem Set von .pre Dateien wie folgt generiert :
<H2>Vorige nummers</H2> <p>Dit zijn de uitgaven van LinuxFocus in het Nederlands: <ul> <!-- macro xslt previssues --> </ul>
<H2>Recent vertaalde artikelen</H2> < macro xslt recently_translated -->Diese Dateien sind einfach HTML Fragmente mit einem Makro, daß das Stylesheet auf deine lokale Datenbank anwendet. Die Bearbeitung geschieht mit einem Programm namens apply_stylesheets.pl, daß nach <!-- macro xslt [stylesheet] --> Befehlen sucht und die Datenbank mit diesem Befehl analysiert. Beachte, daß die .xslt Erweiterung weggelassen wurde. Unser Makefile enthält:
%.shtml: %.pre
@echo "Making $*..."
@../../xml/bin/apply_stylesheets.pl $*.pre
Die resultierenden *.shtml Dateien werden von dem lfpagecomposer Skript benutzt. Die Stylesheets, die zum Erzeugen der index.html Seite benutzt werden, sind: issuetoc.xslt, previssues.xslt und recently_translated.xslt.
Um dieses Sytem in anderen Sprachen zu benutzen, mußt du das folgende machen:
Der zweite Schritt ist ein bißchen unglücklich. Im Prinzip muß nur der Text in der Ausgabe angepaßt werden, aber die Stylesheets haben bisher noch keine Anpassungseigenschaften. Die ist aber möglich und ich würde es gerne implementiert sehen.
Ich empfehle, einen DTD bewußten XML Editor zu benutzen. In Emacs kann man zum Beispiel den psgml major mode benutzen. Dies gibt dir die Fähigkeit, das Dokument zu validieren (mit nsgmls). Dies ist sehr hilfreich, um Fehler zu vermeiden. In Emacs kann man dann auch durch rechten Mausklick die Elemente und Attribute sehen, die man an dieser speziellen Stelle in die XML Datei einfügen kann. (Dank an Jaime Villate für seinen exellenten Vortrag auf der LSM Konferenz in Bordeaux dieses Jahr.)
Eine weitere große Hilfe ist die holländische lokale Anpassung der XML Datenbank. Wenn Probleme bei dir auftauchen, kannst du diese Datei konsultieren. Auch wenn der Inhalt überwiegend auf Holländisch ist, kannst du sehen, wie die Datenbankelemente organisiert sind. wenn das nicht hilft, kannst du mir jederzeit emailen.
Das lokale Anpassen der Stylesheets ist wahrscheinlich ein bißchen trickreich. Text ist vermischt mit XSLT Befehlen. Die letzteren mußt du nicht anfassen (außer, du weißt, was du tust), um seine Funktionalität zu erhalten. Ich plane, die Stylesheets in Zukunft lokal anzupassen, was bedeutet, daß du dann nur eine Datei editieren mußt, die deine Übersetzungen beinhalten und keine XSLT Befehle, aber das ist noch nicht gemacht.
OK, dies sollte genügen, damit du anfangen kannst: Das meiste kannst du von den holländischen Dateien kopieren und pasten. Alle Dateien sind FDL und GPL. Im nächsten Jahr sind dies meine Pläne für das System:
|
|
Der LinuxFocus Redaktion schreiben
© Egon Willighagen, FDL LinuxFocus.org Einen Fehler melden oder einen Kommentar an LinuxFocus schicken |
Autoren und Übersetzer:
|
2001-09-02, generated by lfparser version 2.17