-
Aufgrund
der weit verbreiteten Verwendung von Computern und zugeordneten
Technologien besteht ein ständiger
Bedarf, die Programme, die auf verschiedenen Computersystemen ablaufen,
zu aktualisieren. Häufige
Aktualisierungen sind notwendig, um z. B. Kompatibilität, zusätzliche
Funktionalität und/oder
Programmfehlerbehebungen bereitzustellen. Mit jeder Aktualisierung
liegen in der Regel Instruktionen an den Benutzer vor, die die neuen
Merkmale und/oder Programmfehlerbehebungen für das aktualisierte Programm
berücksichtigen.
-
In
einer befehlszeilenorientierten Betriebsumgebung (z. B. UNIX, LINUX
und DOS), z. B., kann eine Software-Hochrüstung (upgrade) neue Befehlssätze, neue
Optionen bezüglich
existierender Befehle, die Streichung vorangegangener Befehle und
dergleichen umfassen. Um den Benutzer bei der Nutzung der aktualisierten
Software zu unterstützen, können Hunderte
von Manual-Seiten (Man-Pages) bereitgestellt sein. Eine Man-Page
kann z. B. eine Beschreibung eines Befehls, die Syntax des Verwendens
des Befehls und verschiedene dem Befehl zugeordnete Optionen bereitstellen.
Dementsprechend ist die Genauigkeit der Man-Pages entscheidend für die Fähigkeit
eines Benutzers, die Befehlssätze
zu beeinflussen und die Produktivität aufrecht zu erhalten, insbesondere
nach einer Software-Hochrüstung.
-
Bislang
war jedoch der Prozeß des
Erzeugens von Man-Pages ziemlich arbeitsintensiv und fehleranfällig. Allgemein
gesprochen wurden die Befehle und die Man-Pages als zwei getrennte
Projekte behandelt, oft von unterschiedlichen Gruppen von Arbeitswissenschaftlern
besetzt. Aufgrund der mit Koordination, Kommunikation verknüpften Probleme und/oder
aufgrund einfacher menschlicher Interpretationsfehler führen Änderungen,
die durch eine Gruppe von Ingenieuren an Befehlen vorgenommen werden,
manchmal nicht zu Aktualisierungen an den richtigen Man-Pages durch
die Ingenieure, die für das
Aktualisieren der Man-Pages verantwortlich sind.
-
Ferner
besteht der typische Ansatz zum Entwickeln von Man-Pages darin, NROFF
zu verwenden, eine Sprache, die beschreibt, wie die Man-Pages aussehen
werden, wenn die Man-Page-Komponenten
codiert werden. Die Man-Page-Komponente, aufgerufen durch einen „menschlichen" Befehl (z. B. UNIX),
wird verarbeitet und die dem Befehl entsprechende Online-Manual-Seite angezeigt.
NROFF ist jedoch eine unflexible und schwierig zu verwendenden Sprache,
die mindestens 20 Jahre alt ist. Die einzige Möglichkeit, eine NROFF-Datei
zu validieren, besteht darin, die Datei auszuführen und das Ergebnis auf einer
Anzeige zu betrachten, um zu bestimmen, ob dieselbe gültig ist.
Ohne die Fähigkeit,
eine Dokumentenverifizierung durchzuführen, müssen die Ersteller von Man-Pages
auf zeitaufwendige Probeausführungen
der NROFF-Dateien
zurückgreifen und
durch Betrachten des Ausführungsergebnisses visuell
bestimmen, ob Fehler in den NROFF-Codes sind.
-
1 zeigt ein Flußdiagramm
des Stands der Technik, das den Prozeß zum Erstellen von Befehlen
und zugeordneten Man-Pages
darstellt. Die linke Hälfte
des Flußdiagramms
stellt die beispielhaften Handlungen dar, die durch die Entwicklungsingenieure,
die für
das Erstellen und/oder Modifizieren der Befehle verantwortlich sind,
vorgenommen werden, sowie die Arbeitsprodukte, die von denselben ausgegeben
werden. Die rechte Hälfte
des Flußdiagramms
stellt die beispielhaften Handlungen dar, die durch Lernproduktingenieure
durchgeführt
werden, die verantwortlich sind, zu gewährleisten, daß die Man-Pages
die durch die Entwicklungsingenieure erstellten Befehle berücksichtigen,
sowie die Arbeitsprodukte, die von denselben ausgegeben werden.
-
Das
Flußdiagramm
beginnt mit der externen Spezifikation bei Block 102. Allgemein
ist die externe Spezifikation ein Dokument, das die Produktmerkmale
skizziert, in der Regel ansprechend auf Marketingerfordernisse.
Die externe Spezifikation wird durch Lernproduktingenieure eingesetzt,
um einen Lernproduktplan zu entwickeln (104). Die Ausgabe
ist ein Lernproduktplan (106) einschließlich des Zeitplans, der verschiedene
Meilensteine und Lieferbares skizziert, wofür die Lernproduktingenieure
verantwortlich sind.
-
Die
externe Spezifikation (102) wird auch von den Entwicklungsingenieuren
eingesetzt, um einen Code zu entwickeln (108), der die
externe Spezifikation implementiert. Bei Block 110 entwerfen
die Entwicklungsingenieure Man-Pages, die den codierten Befehlen
zugeordnet sind, die gemäß der externen
Spezifikation erstellt wurden. Da die Entwicklungsingenieure über ein
profundes Wissen der erstellten Befehle verfügen, werden die Man-Page-Entwürfe daher
in der Regel von den Entwicklungsingenieuren erstellt, zumindest
am Anfang. Die Erstellung der vorläufigen Man-Pages auf dieser
Stufe kann durch die Entwicklungsingenieure allein oder mit der Unterstützung der
Lernproduktingenieure durchgeführt
werden.
-
Somit
wird ein vorläufiges
Man-Page-Dokument produziert (112). Bei Block 114 überprüfen die Lernproduktingenieure
das vorläufige
Man-Page-Dokument z. B. hinsichtlich richtiger Grammatik und richtigem
Englisch und codieren in manchen Fällen die Man-Page in NROFF.
Da die durch die Entwicklungsingenieure bereitgestellten Dokumente
in der Regel in einem Textverarbeitungsdateiformat (z. B. Word von
Microsoft Corporation aus Redmond, WA), ASCII oder einem anderen
vom Menschen lesbaren Format sind, müssen die Lernproduktingenieure
die bereitgestellten Informationen interpretieren und versuchen,
in NROFF Man-Pages zu erstellen, die das, was die Entwicklungsingenieure
beabsichtigen, berücksichtigen.
Wie es in Fällen,
in denen menschliche Interpretation und menschliche Kommunikation
zwischen Gruppen von Menschen beteiligt sind, typisch ist, werden
Fehler oft unbeabsichtigt eingeführt,
was zu potentiellen logischen Unterbrechungen zwischen den Befehlen
und den sich ergebenden Man-Pages führt. Hinzu kommt, daß eine Formatierung,
die manchmal in einem Dateiformat (z. B. der zuvor erwähnten Verarbeitungsanwendung
Word) zur Verfügung
steht, unter Umständen
nicht in NROFF zur Verfügung
steht.
-
Selbst
wenn es den Lernproduktingenieuren gelingt, irgendwie die Absicht
der Entwicklungsingenieure mit 100%iger Genauigkeit zu interpretieren, können sich
die sich ergebenden Man-Pages dennoch erheblich bezüglich Stil,
Format und Ordnung unterscheiden. Der Grund dafür ist, daß unterschiedliche Lernproduktingenieure
die Man-Pages unter Umständen
auf der Basis von individuellen, subjektiven NORFF-Codierpraktiken
und -Präferenzen
unterschiedlich codieren. Somit können unterschiedliche Man-Pages
in dem gleichen Produkt unterschiedlich aussehen und/oder unterschiedlich
organisiert sein, was dazu führt,
daß die
Man-Pages für Benutzer
schwieriger zu lesen und zu verstehen sind als notwendig.
-
Bei
Block 116 setzen die Entwicklungsingenieure die Codeentwicklung
fort, um die Befehle feinabzustimmen, Programmfehler zu beheben
und manchmal neue Funktionalitäten
hinzuzufügen.
Für jede Änderung,
die an einem Befehl ausgeführt
wird, hat ein Entwicklungsingenieur die Möglichkeit, den Lernproduktingenieuren
die Änderung
mitzuteilen, so daß die
Lernproduktingenieure die Änderung
auf der (den) entsprechenden Man-Page(s) berücksichtigen können. Einige
Entwicklungsingenieure teilen Lernproduktingenieuren eifrig alle Änderungen
mit. Andere Entwicklungsingenieure vergessen oder machen sich schlicht
nicht die Mühe,
die Lernproduktingenieure über
die Änderungen
in den Befehlen zu informieren, was dazu führt, daß die Man-Pages nicht mit den
geänderten
Befehlen synchronisiert werden. Andere Produktingenieure entscheiden
sich, durch Ausüben
ihres Ermessens bei Block 118, vielleicht dafür, daß einige Änderungen
es nicht wert sind, in den Man-Pages berücksichtigt zu werden. Zwangsläufig sind
einige dieser subjektiven Entscheidungen falsch und folglich würden einige
Man-Pages nicht mit den geänderten
Befehlen synchronisiert werden.
-
Bei
Block 114 finden die Prüfungs-/Editierzyklen
für die
Man-Pages statt. An einem bestimmten Punkt ist es notwendig, sich
in Richtung Publizierung (122) zu bewegen, was zu dem endgültigen Man-Page-Arbeitsprodukt
(124) führt.
In manchen Fällen werden Änderungen
an den Befehlen, die spät
während
des Entwicklungszyklus auftreten, unter Umständen nicht in den Man-Pages
aktualisiert, da der Veröffentlichungsprozeß (122)
schon begonnen hat. Für
diese Befehle blieben die Man-Pages somit bis zur nächsten Freigabe
der Man-Pages nicht synchronisiert.
-
Der
manuelle und zeitaufwendige Prozeß, der beim Erzeugen von Man-Pages
involviert ist, kann in manchen Fällen bewirken, daß Man-Pages mit
dem freigegebenen Code nicht synchronisiert sind. 2 stellt ein bekanntes Beispiel dar,
wie ein Widerspruch zwischen dem freigegebenen Code und der Man-Page
für ein
Produkt entstehen kann. Ein Produkt wird zu Anfang mit einem Code 202 der
Version 1.0 und einer Man-Page 204 der
Version 1.0 freigegeben. Später
werden der Code 206 der Version 2.0 und die Man-Page 208 der
Version 2.0 freigegeben. Bis jetzt weist jede Codefreigabe eine
entsprechende Man-Page-Freigabe auf. Wenn jedoch der Code 210 der
Version 3.0 freigegeben wird, gibt es keine entsprechende 3.0-Man-Page-Freigabe,
die die Codeänderungen
berücksichtigt,
da unter Umständen
nicht ausreichende Ressourcen wie z. B. Zeit oder Ingenieursressourcen
zur Verfügung
standen, um die Man-Pages zu überarbeiten.
Statt dessen wird die Man-Page 208 der Version 2.0 mit
der Codeversion 3.0 210 freigegeben. Folglich sind neue Befehle,
die in Version 3.0 erstellt und/oder modifiziert wurden, den Benutzern
unter Umständen
nicht bekannt, und/oder alte Befehle, die in Version 3.0 nicht mehr
unterstützt
werden, werden unter Umständen
immer noch in den Man-Pages erör tert,
was zu einer Frustration des Benutzers führt. Ein anderes potentielles
Problem besteht darin, daß Optionen
einem Befehl hinzugefügt
oder von einem Befehl entfernt und nicht dokumentiert werden, oder
die Werte, die bereitgestellt sind, um eine Optionsänderung
zu verwenden.
-
Neben
den Man-Pages müssen
auch ein Parsercode und ein Gebrauchstext für Befehlscodes erstellt werden.
Bei Verwendung hierin repräsentiert der
Begriff Parsercode ein Stück
Code, das den Befehl interpretiert, einschließlich der Optionen desselben,
um es dem Programm zu ermöglichen,
den Befehl entsprechend auszuführen.
Gebrauchstext ist ein von Menschen lesbarer Text, der durch den
Befehl bereitgestellt wird und erklärt, wie der Befehl verwendet
werden kann, z. B. was die einem Befehl zugeordneten Optionen und
Parameter sind.
-
Wie
es mit Man-Pages der Fall ist, so neigen auch die bekannten Prozesse
zum Erstellen und Aktualisieren eines Parsercodes und Gebrauchstextes dazu,
manuell und fehleranhängig
zu sein. 3 ist ein Flußdiagramm
des Stands der Technik, das den bekannten Prozeß zum Erstellen und Aktualisieren des
Parsercodes, Gebrauchstextes und der Man-Pages aus dem Befehlcode
darstellt. Das Flußdiagramm
beginnt mit dem Entwicklungsingenieur 300, der einen Befehlscode 302,
einen Parsercode 304 und einen Gebrauchstext 306 erstellt.
Nachdem der Befehlscode erstellt wurde (302), folgt das
Flußdiagramm
dem Pfeil 308 zu dem Lernproduktingenieur (310),
der die Man-Pages auf die oben erörterte Weise erstellt/editiert
(312).
-
In
der Regel muß an
dem Befehlscode ein Testen durchgeführt werden, um Leistung und
Genauigkeit zu gewährleisten.
Somit testet der Entwicklungsingenieur 300 bei Block 316 den
Befehlscode. Wenn der Befehlscode im wesentlichen fehlerfrei und die
Leistung akzeptabel ist, ist das Testen bei Entscheidungsblock 318 abgeschlossen
und der Befehlscode und die Man-Page werden bei Block 314 versandt.
-
Wenn
das Testen bei Block 316 anzeigt, daß der Befehlscode nicht zufriedenstellend
ist, modifiziert der Entwicklungsingenieur 300 den Befehlscode bei
Block 318. Wenn der Befehlscode modifiziert wird, kann
der Parser bei Block 320 ebenfalls modifiziert werden.
Der Entwicklungsingenieur 300 entscheidet, oft subjektiv,
bei Block 322, ob die Änderungen
an dem Befehlscode und/oder dem Parsercode eine Änderung an dem Dokument erfordern.
Wenn der Entwicklungsingenieur entscheidet, daß eine Änderung an dem Dokument nötig ist,
wird der Gebrauchstext bei Block 326 modifiziert. Andererseits, wenn
die Einschätzung
des Entwicklungsingenieurs inkorrekt ist und die Änderung
nicht in dem Gebrauchstext berücksichtigt
wird, wäre
der Gebrauchstext infolgedessen mit den geänderten Befehlscodes nicht
synchronisiert.
-
Selbst
wenn der Gebrauchstext geändert wurde
(wie bei Block 322 entschieden und bei Block 326 durchgeführt wurde),
verfügt
der Entwicklungsingenieur über
das Ermessen, bei Block 324 zu entscheiden, ob die Änderungen
den Lernproduktingenieuren übermittelt
werden müssen,
um die Änderungen
in den Man-Pages zu berücksichtigen.
Auch diese Entscheidung ist oft subjektiv. Wenn die Einschätzung des
Entwicklungsingenieurs inkorrekt ist oder er die Änderungen
dem Lernproduktingenieur nicht übermittelt,
wären die
Man-Pages mit dem
aktualisierten Befehlscode nicht synchronisiert.
-
Wie
aus 3 ersichtlich, werden
Parsercode und Gebrauchstext manuell aufgebaut und unabhängig voneinander
aufrechterhalten. Es ist daher, wie in 3 zu sehen ist, möglich, Änderungen an dem Parsercode
vorzunehmen, ohne den Gebrauchstext und/oder die Man-Pages zu ändern. Ferner
ist es möglich, Änderungen
an einem Gebrauchstext vorzunehmen, ohne den Parsercode und/oder die
Man-Pages zu ändern.
-
In
Anbetracht des Vorangegangenen sind neue Techniken zum Erstellen
und Aktualisieren von Man-Pages und/oder eines Gebrauchstextes und/oder
eines Parsercodes erwünscht.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein Verfahren, einen
Herstellungsartikel und ein computerimplementiertes Verfahren zum
Erzeugen von Unterstützungsdokumenten
mit verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch ein Verfahren gemäß Anspruch 1, einen Herstellungsartikel
gemäß Anspruch
11 sowie ein computerimplementiertes Verfahren gemäß Anspruch
18 gelöst.
-
Die
Erfindung bezieht sich bei einem Ausführungsbeispiel auf ein Verfahren
zum Erzeugen von Unterstützungsdokumenten
für einen
Befehlscode in einer befehlszeilenorientierten Betriebsumgebung. Das
Verfahren umfaßt
ein Erstellen einer XML-Quellendatei (XML = extensible markup language,
erweiterbare Markup-Sprache), wobei die XML-Quellendatei Informationen
umfaßt,
die für
ein Erzeugen eines Parsercodes erforderlich sind. Der Parsercode
ermöglicht
ein Kompilieren des Befehlscodes. Das Verfahren umfaßt ferner
ein Erzeugen von zumindest zweien einer Man-Page-Datei, einer Gebrauchsnachrichtendatei
und des Parsercodes aus der XML-Quellendatei.
-
Bei
einem anderen Ausführungsbeispiel
bezieht sich die Erfindung auf einen Herstellungsartikel, der ein
Programmspeicherungsmedium mit einem in demselben ausgeführten computerlesbaren
Code aufweist, wobei der computerlesbare Code für ein Erzeugen von Unterstützungsdokumenten
für einen Befehlscode
in einer befehlszeilenorientierten Betriebsumgebung konfiguriert
ist. Es ist ein computerlesbarer Code zum Zugreifen auf eine XML-Quellendatei
mit eingeschlossen. Die XML-Quellendatei umfaßt Informationen, die für ein Erzeugen
eines Parsercodes erforderlich sind. Der Parsercode ermöglicht ein
Kompilieren des Befehlscodes. Ferner ist ein computerlesbarer Code
zum Erzeugen von zumindest zweien aus einer Man-Page-Datei, einer
Gebrauchsnachrichtendatei und des Parsercodes aus der XML-Quellendatei mit
eingeschlossen.
-
Bei
noch einem weiteren Ausführungsbeispiel
bezieht sich die Erfindung auf ein computerimplementiertes Verfahren
zum Erzeugen von Unterstützungsdokumenten
für einen
Befehlscode in einer befehlszeilenorientierten Betriebsumgebung.
Das Verfahren umfaßt
ein Zugreifen auf eine XML-Quellendatei, wobei die XML-Quellendatei
Informationen umfaßt,
die für
ein Erzeugen eines Parsercodes erforderlich sind. Der Parsercode
ermöglicht
ein Kompilieren des Befehlscodes. Das Verfahren umfaßt ferner
ein Erzeugen einer Man-Page-Datei, einschließlich eines Neuordnens der
Reihenfolge, in der die Informationen in der XML-Quellendatei bereitgestellt sind,
und eines Durchführens
entweder einer XSLT-(eXtensible Stylesheet Language Transformation
= erweiterbare Formatsprache-Transformation)-Transformation an der
XML-Quellendatei
oder einer NROFF-Transformierung an der XML-Quellendatei.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert,
wobei gleiche Bezugszeichen verwendet werden, um die gleichen, ähnliche
oder entsprechende Teile in den mehreren Ansichten der Zeichnungen
zu beschreiben. Es zeigen:
-
1 ein Flußdiagramm
des Stands der Technik, das den Prozeß zum Erstellen von Befehlen und
zugeordneten Man-Pages darstellt;
-
2 ein bekanntes Beispiel,
wie ein Widerspruch zwischen dem freigegebenen Code und der Man-Page
für ein
Produkt entstehen kann;
-
3 ein Flußdiagramm
des Stands der Technik, das den bekannten Prozeß zum Erstellen und Aktualisieren des
Parsercodes, Gebrauchstextes und der Man-Pages aus dem Befehlscode darstellt;
-
4 gemäß einem Ausführungsbeispiel der
vorliegenden Erfindung ein Blockdiagramm, das die Verwendung einer
einzelnen XML-Man-Page-Quellendatei, um die Unterstützungsdateien
wie z. B. Man-Pages, Gebrauchsnachrichtendateien, Parsercodedateien
synchron zu erzeugen, darstellt;
-
5 ein beispielhaftes Diagramm,
das gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung die Transformierung und Neuordnung von Informationen
aus der XML-Man-Page-Quellendatei, um automatisch eine Man-Page
zu erstellen, darstellt;
-
6 gemäß einem Ausführungsbeispiel der
vorliegenden Erfindung eine Parsertransformation eines beispielhaften
Befehls aus einer XML-Man-Page-Quellendatei;
-
7A gemäß einem Ausführungsbeispiel der
vorliegenden Erfindung eine Ausführungszeiterzeugung
des Gebrauchstextes; und
-
7B gemäß einem Ausführungsbeispiel der
vorliegenden Erfindung eine Kompilierungszeiterzeugung des Gebrauchstextes.
-
Die
vorliegende Erfindung wird nun unter Bezugnahme auf einige bevorzugte
Ausführungsbeispiele
derselben detailliert beschrieben, wie sie in den beiliegenden Zeichnungen
dargestellt sind. Bei der folgenden Beschreibung werden zahlreiche
spezifische Details dargelegt, um ein gründliches Verständnis der
vorliegenden Erfindung zu ermöglichen. Fachleuten
auf dem Gebiet ist es jedoch klar, daß die vorliegende Erfindung
ohne einige oder aller dieser spezifischen Details praktiziert werden
kann. In anderen Fällen
wurden bekannte Prozeßschritte und/oder
Strukturen nicht detailliert beschrieben, um das Verständnis der
vorliegenden Erfindung nicht unnötig
zu erschweren.
-
Bei
einem Ausführungsbeispiel
setzt die vorliegende Erfindung eine einzelne XML-Quellendatei ein,
aus der Unterstützungsdateien
wie z. B. Man-Pages, Gebrauchsdatendateien, Parsercodedateien und
dergleichen automatisch erzeugt werden. Da die benötigten Unterstützungsdateien
(z. B. Man-Pages, Gebrauchsdatendateien
und Parsercodedateien) automatisch aus einer einzelnen Quelle erzeugt
werden, werden Inkonsistenzen, die auf ein menschliches Beurteilen
und Ermessen bei der Erstellung und Aktualisierung der Unterstützungsdateien
zurückzuführen sind,
wesentlich reduziert. Da die Unterstützungsdateien automatisch aus
einer einzelnen Quellendatei erzeugt werden, werden die individuellen Unterstützungsdateien
ferner automatisch bezüglich der
einzelnen XML-Quellendatei synchronisiert, was im wesentlichen die
Möglichkeit
ausschließt,
daß individuelle
Unterstützungsdateien
nicht miteinander synchronisiert sind. Hinzu kommt, daß die Aufgabe des
Aktualisierens der Unterstützungsdateien,
da alle Unterstützungsdateien
ihre Informationen von der einzelnen XML-Quellendatei ableiten,
vorzugsweise auf ein Aktualisieren der einzelnen XML-Quellendatei und
erneutes Erzeugen eines neuen Satzes Unterstützungsdateien herunterreduziert
ist.
-
Bei
einem Ausführungsbeispiel
beschreibt die XML-Quellendatei
die Syntax der Befehle, der Gebrauchsdaten und jeglicher anderer
Informationen, die normalerweise in den Man-Pages enthalten wären. Ferner,
da die XML-Quellendatei die Informationen enthält, die erforderlich sind,
um den Parsercode zu erzeugen, wird die XML-Quellendatei, somit erzeugt,
noch bevor der Befehlscode (d. h. der Code, den die Man-Pages beschreiben)
kompiliert wird. Diese Anforderung gewährleistet daher, daß die Informationen
in der XML-Quellendatei
immer in Synchronisation mit dem Befehlscode sind.
-
Die
Verwendung von XML bietet noch andere Vorteile. Durch die Verwendung
von XML sind Ingenieure z. B. in der Lage, moderne Dokumentenverifizierungstechnologien,
wie z. B. Dokumententypdefinition (DTD) und/oder XML-Schemata, einzusetzen,
um syntaxgesteuerte Editoren zu treiben, um die Aufgabe des Erstellens
der Unterstützungsdateien (über die
XML-Quellendatei) effizienter und genauer zu machen. Als Beispiel
seien die Man-Pages betrachtet. Im Gegensatz zu dem bekannten Ansatz, bei
dem Man-Pages unter Verwendung der schwierig zu handhabenden NROFF-Sprache
erstellt werden müssen,
ermöglicht
es die Erfindung, daß Man-Pages
automatisch aus einer XML-Quellendatei erzeugt werden. Mit XML kann
nicht nur einfacher gearbeitet werden, die Verwendung von XML ermöglicht auch ein
robustes Editieren und Fehlerüberprüfen während der
Dateneingabephase. Zum Beispiel kann der syntaxgesteuerte Editor,
der mit XML arbeitet, automatisch Elemente für eine Eingabe auflisten, so
daß der
Ersteller einer Man-Page sich nicht an die Elemente erinnern muß. Als ein
weiteres Beispiel ermöglicht
es die DTD-Technologie
dem Ersteller der Man-Pages, Fehler zu beseitigen und/oder zu erkennen,
während
die XML-Quellendatei erstellt wird. Im Gegensatz dazu macht es der
NROFF-Ansatz des Stands der Technik erforderlich, daß der Ingenieur die
NROFF-Datei ausführt
und das Ergebnis auf einer Anzeige betrachtet, um die NROFF-Datei
zu validieren.
-
Des
weiteren gewährleisten
die Verwendung der XML-Technologie
und geeignete Transformierungen auf derselben eine Konsistenz mit
der Präsentation
der Man-Pages. Anstatt sich auf den Ersteller der Man-Pages zu verlassen,
um die Man-Page-Informationen geeignet zu ordnen, so wie dies zuvor
gemacht wurde, analysiert eine Transformationsmaschine die in der
XML-Quellendatei bereitgestellten Informationen und gibt die Informationen
in der korrekten Reihenfolge zu den Man-Pages aus, ungeachtet der
Reihenfolge, in der die Informationen in der XML-Quellendatei bereitgestellt
sind.
-
Die
Merkmale und Vorteile der vorliegenden Erfindung werden vielleicht
unter Bezugnahme auf die folgenden Zeichnungen und Erörterungen
besser verständlich.
Gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zeigt 4 ein
Blockdiagramm, das die Verwendung einer einzelnen XML-Man-Page-Quellendatei
darstellt, um die Unterstützungsdateien
wie z. B. Man-Pages, Gebrauchsnachrichtendateien, Parsercodedateien
und dergleichen synchron zu erzeugen. Wie zuvor festgestellt wurde,
ist die XML-Man-Page-Quelle konform zu modernen Dokumentenverifizierungstechnologien
wie z. B. Dokumententypdefinition (DTD) oder XML-Schema. Die DTD
oder das XML-Schema wird bei Block 402 bereitgestellt.
Block 404 zeigt einen syntaxgesteuerten Editor, der durch
den Ingenieur eingesetzt werden kann, um eine XML-Man-Page-Quellendatei zu konstruieren.
Wie erwähnt,
ermöglicht
die Verwendung von XML die Verwendung eines syntaxgesteuerten Editors
(wie z. B. EMACS, ein Open-Source- bzw. Freie-Quellen-Editor auf HP-UXTM und
LINUX und XML Spy von Altova GmbH, Rudolfsplatz 13a/9, A-1010 Wien, Österreich/EU.
www.altova.com, auf Windows, oder eines anderen geeigneten syntaxgesteuerten
Editors), was den Genauigkeits- und Effizienzgrad, mit dem die XML-Quellendatei
erstellt wird, erheblich verbessert.
-
Die
XML-Man-Page-Quellendatei ist bei Block 406 gezeigt. Allgemein
wird die XML-Man-Page-Quellendatei immer dann aktualisiert, wenn
der Befehlscode aktualisiert wird. Dies ist gewährleistet, da, wie zuvor erwähnt, die
XML-Man-Page-Quellendatei
die Informationen enthält,
die erforderlich sind, um den Parser zu erzeugen, was für ein Kompilieren des
Quellencodes erforderlich ist. Aus dieser einzelnen XML-Man-Page-Quellendatei 406 kann
eine Mehrzahl von Unterstützungsdateien
automatisch erzeugt werden.
-
Um
eine Man-Page aus dem XML-Man-Page-Quellencode 406 zu erstellen,
wird eine NROFF-Transformation durchgeführt 408, um eine NROFF-Man-Page 410 zu
erstellen. Gegenwärtig wird
die NROFF-Man-Page 410 als die Eingabe zu dem man- oder Manualbefehl
verwendet, um kompatibel mit existierenden Systemen zu sein. Es
ist jedoch denkbar, daß Man-Pages
direkt aus der XML-Man-Page-Quellendatei 406 erzeugt werden können, ohne
auf die Zwischen-NROFF-Transformierung 408 und die NROFF-Man-Page 410 zurückzugreifen.
Es sei bemerkt, daß sogar
mit dem NROFF-Transformationsblock 408 und dem NROFF-Man-Page-Block 410 die
Ersteller von Man-Pages nicht in der NROFF-Domäne arbeiten müssen, um
Man-Pages zu erstellen. Es ist möglich, die
XSLT-Transformation direkt auf der XML-Man-Page-Quellendatei 406 auszuführen, um Man-Pages
zu erhalten. Der Prozeß zum
Erstellen von Man-Pages wird in Verbindung mit 5 hierin weiter erörtert.
-
Um
den Parsercode zu erzeugen, stellt der XML-Man-Page-Quellencode 406 der
Parsertransformation 412 eine Eingabe bereit. Die Parsertransformation 412 erstellt
eine Parserquelle 414 aus dem XML-Man-Page-Quellencode 406.
Die Parserquelle 414 wird in einen Parsergenerator 416 eingegeben, der
einen Parsercode 418 erzeugt. Weitere Details der Parsertransformationen
werden mit Bezug auf 6 hierin
erörtert.
-
Um
Gebrauchsnachrichten zu erzeugen, wird der XML-Man-Page-Quellencode 406 als
eine Eingabe in den ASCII-Transformationsblock 420 verwendet,
der die Gebrauchsnachrichten 422 erzeugt, wenn derselbe
durch ein Befehlsprogramm aufgerufen wird. Gebrauchsnachrichten
können
entweder bei der Ausführungszeit
oder bei der Kompilierungszeit erzeugt werden. Weitere Details der
Gebrauchsnachrichtenerzeugung werden mit Bezug auf die 7A und 7B erörtert.
-
Wie
aus dem Vorangegangen ersichtlich ist, hat der XML-Man-Page-Quellencode 406 den
Vorteil, aus einer einzelnen Quelle für die Erzeugung unterschiedlicher
Typen von Ausgaben zu arbeiten, wobei einige derselben darauf ausgelegt
sind, von Menschen gelesen zu werden (wie z. B. die Gebrauchsnachrichten 422),
und einige derselben darauf ausgelegt sind, nur maschinenlesbar
zu sein (wie z. B. der Parsercode 418). Über die
Transformierungsprozesse werden die Unterstützungsdateien automatisch aus
dieser einzelnen Quelle erzeugt, wodurch die Möglichkeit, daß die Unterstützungsdateien
eventuell nicht zueinander synchronisiert sind, praktisch eliminiert
wird. Die automatische Erzeugung spart außerdem manuelle Arbeit und
beseitigt menschliche Fehler als potentielles Problem in der Erzeugung
der Unterstützungsdateien
aus der XML-Man-Page-Quellendatei.
-
Ferner
kann der XML-Man-Page-Quellencode 406 auf andere Transformationen 432 angewendet
werden, um andere Ausgabeformate 434 zu produzieren. Zum
Beispiel können
gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung die anderen Transformationen 432 eine
Transformation der Informationen in dem XML-Man-Page-Quellencode
in SGML DocBook umfassen, um eine Ausgabe für eine Verwendung in Framemaker
zu produzieren. Framemaker, erhältlich
von Adobe Inc. aus San Jose, CA, ist ein beliebtes Editier- und
Desktop-Publishing-Softwareprodukt,
das Daten in einem DocBook-Format importieren kann. Wie bekannt,
ist DocBook ein Industriestandard zum Mark-up-Formatieren von Dokumenten.
Informationen über
DocBook sind von OASIS erhältlich – der Organization
for the Advancement of Structured Information Standards, unter http://www.oasis-open.org.
Die Framemaker-formatierten Man-Pages
können
dann in Framemaker gehandhabt und in andere gedruckte (oder PDF-)
Dokumente, die zusammen mit dem Code versandt werden, integriert
werden. Ein Importieren der SGML-DocBook-Transformation der XML-Man-Page-Quelle
in Framemaker macht es möglich,
den Inhalt der Man-Page in anderen Dokumenten zur Verfügung zu
haben, ohne daß derselbe
kopiert oder neu getippt werden muß. Dementsprechend ist es wahrscheinlicher,
daß Änderungen,
die gegen Ende des Code-Entwicklungszyklus vorgenommen werden, in
anderen veröffentlichten
Dokumenten berücksichtigt
sind.
-
Das
XML-Format ermöglicht
auch andere Operationstypen. Zum Beispiel kann unter Bezugnahme
auf einen Ergebnisprozessor 424, ein Abfrageergebnis 426,
einen Abfrageprozessor 428 und eine Abfrageschnittstelle 430 eine
Abfrageschnittstelle entworfen werden, die den strukturierten XML-Man-Page-Quellencode 406 ausnutzt.
Zum Beispiel kann eine Abfrage ausgegeben werden, um die Anzeige
aller Beispiele, die für
Befehle bereitgestellt sind, die Sicherheitsbefehle sind, anzufordern; das
Abfrageergebnis 426 würde
nur den Beispielabschnitt von Man-Pages, die Sicherheitsbefehle
sind, zurückgeben
und nicht die gesamte Man-Page für
jeden Sicherheitsbefehl präsentieren.
Das Abfragebeispiel ist nur ein Beispiel für die Flexibilität von XML und
soll nicht den Bereich möglicher
Anwendungen einschränken.
Als weiteres Beispiel macht es die Struktur von XML-Dateien möglich, die
Ausgabedokumente, falls erwünscht,
zu unterteilen.
-
5 ist ein beispielhaftes
Diagramm, das gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung die Transformierung und Neuordnung von Informationen
aus der XML-Man-Page-Quellendatei 502,
um automatisch eine Man-Page 506 zu erstellen, darstellt.
Ein beispielhafter Abschnitt eines XML-Man-Page-Quellencodes 502 ist
mit einer Mehrzahl von Quelleneinträgen, die von A bis Y gekennzeichnet
sind, gezeigt. In der Praxis können
sehr viel mehr Quelleneinträge
zum Beschreiben eines gegebenen Befehls vorhanden sein, als in der
beispielhaften 5 gezeigt
sind.
-
Gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung ist die Transformationsmaschine 504 eine
XSLT-(Extensible Stylesheet Language Transform = erweiterbare-Formatsprache-Transformation)-Transformation
des „Zieh"-Typs im Gegensatz
zu Transformationen des „Stoß"-Typs. XSLT ist eine
Standardprogrammiersprache, die zum Beschreiben einer Dokumententransformierung
vorgesehen ist und konform zu der W3C-World Wide Web Consortium)-Empfehlung
ist. Die W3C-Empfehlung selbst
ist unter http://www. w3.org/TR/1999/REC-xslt-19991116.html (Stand April 2003)
erhältlich.
Die „Zieh"-Typ-Transformation ordnet
automatisch alle Daten neu, die nicht in einer vorgeschriebenen
Reihenfolge sind. Die „Stoß"-Typ-Transformation
andererseits nimmt die Daten und plaziert sie in der gleichen Reihenfolge,
in der die Daten präsentiert
wurden. Durch die Verwendung einer „Zieh"-Typ-Transformation ist das Ordnen von
Elementen in der Ausgabedatei der Transformationsmaschine vorteilhafterweise
unabhängig
von dem Ordnen der Elemente in der Eingabedatei. Dementsprechend
beeinflussen Inkonsistenzen bezüglich des
Ordnens der Informationen, die in der XML-Man-Page-Quellendatei vorliegen können, nicht
die Reihenfolge, in der die Informationen in der ausgegebenen Man-Page 506 präsentiert
werden.
-
Unter
Bezugnahme auf 5 wird
der Quelleneintrag D <name>, Name, des XML-Man-Page-Quellencodes 502 direkt
zu NAME-Eintrag auf der sich ergebenden Man-Page 506 transformiert.
Der Quelleneintrag E und Quelleneintrag F transformieren zu „einbefehl – tut etwas" 510. Der
Quelleneintrag H <synopsis> (= Synopse) des XML-Quellencodes 502 transformiert
zu SYNOPSE 512 auf der sich ergebenden Man-Page 512.
Die Quelleneinträge
H bis 0 des XML-Man-Page-Quellencodes 502 transformieren
zu „einbefehl
[-o param]" auf
der sich ergebenden Man-Page 506. Der Quelleneintrag P <description> (= Beschreibung) des
XML-Man-Page-Quellencodes 502 transformiert zu BESCHREIBUNG 516 auf
der sich ergebenden Man-Page 506. Der
Quelleneintrag Q <summary> (= Zusammenfassung)
Dieser Befehl tut, was man von ihm erwartet. /summary> transformiert zu „Dieser
Befehl tut, was man von ihm erwartet" 518 auf der sich ergebenden Man-Page 506.
-
Die
Quelleneinträge
S – T <authors> (= Autoren) des XML-Man-Page-Quellencodes 502 transformieren
zu „AUTOREN
..." 520 auf
der sich ergebenden Man-Page 506. Die Quelleneinträge U – V <diagnostics> (= Diagnose) des XML-Man-Page-Quellencodes 502 transformieren
zu „DIAGNOSE ..." 522 auf
der sich ergebenden Man-Page 506. Die Quelleneinträge W – X <return Values> (= Werte zurückgeben)
des XML-Man-Page-Quellencodes 502 transformieren
zu „WERTE
ZURÜCKGEBEN
..." 524 auf
der sich ergebenden Man-Page 506.
-
Es
sei darauf hingewiesen, daß die
Quelleneinträge
S – T <AUTHORS> in dem XML-Man-Page-Quellencode
502 zwar
vor den Quelleneinträgen W – X <RETURN VALUES> auftreten, die „Zieh"-Typ-XLST-Transformation
504 die
in den Quelleneinträgen
erhaltenen Informationen jedoch einfach neu ordnet, so daß die sich
ergebende Man-Page
506 in einer vorgeschriebenen Reihenfolge
ist, d. h. <RETURN
VALUES> (= Werte zurückgeben)
tritt vor <AUTHORS> (= Autoren) in der
ausgegebenen sich ergebenden Man-Page
506 auf.
-
Wie
aus dem Vorangegangenen ersichtlich, ermöglicht es die Erfindung, daß die Informationen
in einer konsistenten Reihenfolge in der ausgegebenen sich ergebenden
Man-Page präsentiert
werden, ungeachtet der Reihenfolge, in der die Informationen in der
XML-Quellendatei angeordnet sind. Dementsprechend werden dem Benutzer
Informationen in einer konsistenten Reihenfolge und einem konsistenten Format
präsentiert,
was die sich ergebende Man-Page erheblich benutzerfreundlicher macht.
-
Wie
zuvor festgestellt wurde, ist es möglich, wie in 5 gezeigt ist, die Transformierung auszuführen, ohne
auf den Vermittler des NROFF-Formats zurückzugreifen. Eine NROFF-Transformierung kann jedoch
auch aus Gründen
der Rückwärtskompatibilität durchgeführt werden,
wenn dies erwünscht
ist. Bei 5 kann eine
Transformierungsmaschine 504 eine NROFF-Datei ausgeben,
die dann aus geführt werden
kann, um die sich ergebende Man-Page 506 zu erzeugen.
-
Wie
erörtert,
wird der gleiche XML-Man-Page-Code auch verwendet, um den Parsercode
zu erzeugen. 6 stellt
eine Parsertransformation 604 eines beispielhaften Befehls
aus einer XML-Man-Page-Quellendatei cmd.1.xml 602 dar.
Bei einem Ausführungsbeispiel
wird eine Xalan-Transformationsmaschine 604 verwendet,
um eine Datei cmd symbols.java 606 und eine Datei cmd.g 608 aus
der XML-Man-Page-Quellendatei
zu erstellen. Diese Dateien werden dann in einen Parsergenerator
eingegeben, wie z. B. ANTLR, um den erwünschten Parsercode zu erzeugen.
Xalan ist eine Open-Source-XSLT-Transformationsmaschine, die von http://xml.apache.org
(Stand April 2003) erhältlich
ist. ANTLR ist ein Public-Domain-Parsergenerator, der von www.antlr.org
(Stand April 2003) erhältlich
ist.
-
Eine
Teilauflistung der XML-Quellendatei cmd.1.xml (602) ist
auf der linken Seite von 6 gezeigt,
unter dem Block, der cmd.1.xml (602) darstellt. Auf ähnliche
Weise ist eine Teilauflistung der Datei cmd_symbols.java (606)
in dem oberen rechten Abschnitt von 6 gezeigt,
unter dem Block, der cmd_symbols.java (606) darstellt.
Die Datei cmd_symbols.java (606) kann man sich als die Schnittstelle
zwischen dem Parser und dem Rest des Codes vorstellen. 6 zeigt auch eine Teilauflistung
der Datei cmd.g (608) in dem unteren rechten Abschnitt
von 6, unter dem Block,
der cmd.g (608) darstellt. Die Datei cmd.g (608)
kann man sich als die Parsereingabecodedatei vorstellen, die in
einen Parsergenerator eingegeben wird, um den Parsercode zu erzeugen.
-
Die
Auflistung für
die XML-Quellendatei cmd.1.xml (602) umfaßt zwei
Hauptabschnitte: einen Befehlsnamenabschnitt 610 und einen
Synopsenabschnitt 612. Allgemein definiert der Befehlsnamenabschnitt 610 den
Namen des Befehls und definiert der Synopsenabschnitt 612 unter
anderem die verfügbaren
Optionen und Parameter für
den Befehl des Abschnitts 610.
-
Auf
der Basis des Befehlsnamenabschnitts 610 extrahiert die
Transformationsmaschine 604 den Befehlsnamen aus der XML-Quellendatei cmd.1.xml (602).
Zum Beispiel wird der Name cmd (614) aus dem Befehlsnamenabschnitt 610 der
XML-Quellendatei
cmd.1.xml (602) extrahiert und in die Variable cmd (616)
der Datei cmd_symbols.java 606 plaziert. Auf ähnliche
Weise wird der Name cmd (614) aus dem Befehlsnamenabschnitt 610 der
XML-Quellendatei cmd.1.xml (602) extrahiert und in die
Variable cmd (618) der Datei cmd.g (608) plaziert.
Somit kann der Name des Befehls, der in der XML-Man-Page-Quellendatei
enthalten ist, extrahiert werden, um die Dateien cmd_symbols.java 606 und
cmd.g 608 aufzubauen.
-
Der
Synopsenabschnitt 612 umfaßt ausreichend Informationen,
um die Schnittstellendatei cmd_symbols.java (606) und die
Parsereingabecodedatei cmd.g (608) zu erzeugen. Die folgenden
Beispiele erläutern
diese Tatsache. Unter Bezugnahme auf den Synopsenabschnitt 612 wird
der Ausdruck „synopsis
flag="-"" (620)(= Synopsenflag) der XML-Quellendatei
cmd.1.xml (602) zu „Flag:,-'" (622) der Datei cmd.g 608 transformiert.
Der Ausdruck „<option>v/option>" (624) der XML-Quellendatei cmd.1.xml
(602) wird extrahiert und in dem Ausdruck „public
static Boolean option_v = false;" (626)
(public static Boolean option_v = false = öffentliche statische Boolesche
Option_v = falsch) innerhalb der Datei cmd_symbols.java 606 eingesetzt.
Der gleiche Ausdruck „<option>v/option>" (624) der XML-Quellendatei
cmd.1.xml (602) wird ebenfalls extrahier und in dem Ausdruck „Opt_v:
,v'" (628) der
Parsereingabecodedatei cmd.g (608) eingesetzt.
-
In
Anbetracht unterschiedlicher Optionsgruppierungstypen, transformiert
beispielsweise der Ausdruck „<group choice = „opt">" (630)
(group choice = Gruppenwahl) der XML-Quellendatei cmd.1.xml (602)
zu dem Ausdruck „OPT2: (OPT2_1|OPT2_2|OPT2_3)*" (632) der
Parsereingabecodedatei cmd.g (608). Eines der Elemente
unter dem Ausdruck „<group choice = „opt">" (630),
Gruppenwahl, der XML-Quellendatei cmd.1.xml (602) ist in 6 als Ausdruck „<option>T</option" (634) gezeigt. Der Wert T
des Ausdrucks „<option>T</option" (634) wird extrahiert und
in dem Ausdruck „public static
Boolean option_T = false;" (636)
(public static Boolean option_T = false = öffentliche statische Boolsche
Option_T = falsch) der Datei cmd_symbols.java (606) und
auch in dem Ausdruck „Opt_T: ,T'" (638) der Parsereingabecodedatei
cmd.g (608) eingesetzt.
-
Es
sei bemerkt, daß die
obigen Beispiele nur einige der Transformationen sind, die stattfinden,
um die Parserschnittstellendatei (606) und die Parsereingabecodedatei
(608) abzuleiten. Zwar wird in diesem Fall Xalan als Transformationsmaschine
eingesetzt, doch ist die Erfindung nicht auf eine bestimmte Transformationsmaschine
beschränkt.
Desgleichen ist die Erfindung, obwohl erwägt wird, daß unter Umständen der
ANTLR-Parsergenerator eingesetzt wird, um den Parsercode aus der
Parsercodeeingabedatei (608) zu erzeugen, nicht auf einen
bestimmten Parsergenerator beschränkt. Angesichts dieser Offenbarung
ist es Fachleuten auf dem Gebiet ohne weiteres klar, daß andere
Transformationsmaschinen und/oder Parsergeneratoren angepaßt werden
können,
um den Parsercode aus der XML-Eingabe-Quellendatei zu erzeugen.
-
Wie
erwähnt
kann der Gebrauchstext auch aus den Informationen erhalten werden,
die in dem XML-Man-Page-Quellencode enthalten sind. Die 7A und 7B sind Diagramme, die zwei beispielhafte
Ansätze
zum Erzeugen eines Gebrauchstextes gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung darstellen. 7A zeigt die Erzeugung des Gebrauchstextes
während
der Ausführungszeit und 7B zeigt eine Erzeugung
des Gebrauchstextes während
der Kompilierungszeit.
-
Unter
Bezugnahme auf 7A führt ein
Befehlsprogramm 702 ein optionales Anzeigeprogramm 704 aus,
um eine Transformationsmaschine 708 aufzurufen. Das Anzeigeprogramm 704,
das optional ist, stellt eine zusätzliche Flexibilität bereit,
um die Menge an Informationen, die der Anzeige des Gebrauchstextes 712 bereitgestellt
werden, zu steuern. Das Befehlsprogramm 702 beschreibt
der Transformationsmaschine 708 die durchzuführende(n)
Transformation(en). Die Transformationsmaschine 708 nimmt
als Eingaben auch die Gebrauchstransformation 710 und die
XML-Quellencodedatei cmd.1.xml (706). Die Gebrauchstransformation 710 enthält z. B. eine
Beschreibung der Gebrauchsinformationen, die aus cmd.1.xml 706 extrahiert
werden sollen. Die Gebrauchstransformation 710 kann z.
B. unter Verwendung der XSLT-Technologie
implementiert sein.
-
Unterschiedliche
Elemente der XML-Quellencodedatei cmd.1.xml 706 können ansprechend auf
das Anzeigeprogramm 704 angezeigt werden. Zum Beispiel
kann das Anzeigeprogramm 704 programmiert sein, um die
Synopse, Beispiele für
einen Befehlsgebrauch oder den Gebrauchstext anzuzeigen.
-
Unter
Bezugnahme auf 7B wird
die Erzeugung des Gebrauchstextes hauptsächlich während der Kompilierungszeit
durchgeführt.
Dies kann z. B. in Fällen
nützlich
sein, in denen die XML-Quellendatei zur Ausführungszeit nicht zur Verfügung steht.
Die XML-Quellendatei cmd.1.xml 750 kann über eine
Transformationsmaschine 754 transformiert werden, um ansprechend
auf die XSLT-Gebrauchstransformationsdatei 756 und die
Inhaltssteuerdatei 758 eine Gebrauchstext-Verfahren-Quellendatei 752 zu
produzieren. Die Inhaltssteuerdatei 758 führt eine ähnliche
Funktion wie das Anzeigeprogramm 704 aus 7A aus.
-
Ein
Java- oder C-Compiler 762 kombiniert die Gebrauchstext-Verfahren-Quellendatei 752 und die
Befehlsprogrammquellendateien 760, um ein Befehlsprogramm 764 zu
erstellen. Das Befehlsprogramm 764 kann dann während der
Ausführungszeit ausgeführt werden,
um eine Anzeige des Gebrauchstextes 766 zu produzieren.
Die Ausführung kann
z. B. dann stattfinden, wenn eine Hilfsfunktion aufgerufen wird.
Zum Beispiel kann ein Befehl, auf den eine „-h"-Option folgt, die Anzeige des Gebrauchstextes 766 aufrufen,
der auf einem Bildschirm angezeigt werden soll.
-
Wie
aus dem Vorangegangenen ersichtlich ist, spricht die vorliegende
Erfindung viele Punkte an, die die Entwicklung von Man-Pages und
anderen Unterstützungsdateien
erschwert haben. Für
eine beliebige gegebene Iteration des Befehlcodes können die Unterstützungsdateien
nun automatisch und aus der gleichen XML-Quellendatei erzeugt werden.
Da die Unterstützungsdateien
wie z. B. Man-Pages, Parsercode und Gebrauchstext alle automatisch
aus der XML-Quellendatei erstellt werden, ist das Problem mit einem
Mangel an Synchronität
zwischen diesen Unterstützungsdateien
im wesentlichen beseitigt. Da die Unterstützungsdateien automatisch aus
einer einzigen Quellendatei erzeugt werden können, können ferner erhebliche Einsparungen
bezüglich
Arbeit und Zeit sowie eine wesentliche Reduzierung der Häufigkeit
von Fehlern, die von Menschen hervorgerufen werden, realisiert werden.
-
Ferner,
da die XML-Quellendatei die Informationen enthält, die notwendig sind, um
den Parsercode zu erzeugen, wird die XML-Quellendatei jetzt erstellt,
noch bevor der Befehlscode kompiliert werden kann. Diese Anforderung
gewährleistet,
daß die XML-Quellendatei
für eine
beliebige gegebene Iteration des Befehlscodes rechtzeitig aktualisiert
wird. Dementsprechend ist das Problem im Zusammenhang mit dem Mangel
an Synchronizität
zwischen den Unterstützungsdateien
(die nun aus der XML-Quellendatei automatisch abgeleitet werden) und
dem Programmcode ebenfalls im wesentlichen beseitigt.
-
Die
Verwendung von XML und seiner strukturierten Datenbeschreibungseinrichtungen
bietet auch viele Vorteile. Während
NROFF eine begrenzte und starre Sprache ist, hat XML viele unterschiedliche
Anwendungen und ist eine weit verbreitete Technologie, was die Aufgabe
des Dokumentierens in XML für
Ingenieure weniger aufwendig macht. Wie erwähnt ermöglicht XML (oder ähnliche
Technologien) dem Ingenieur, durch Einsetzen von Technologien wie
z. B. DTD eine Datenüberprüfung und
Fehlerüberprüfung auf
eine hocheffiziente und äußerst genaue
Weise durchzuführen.