MEDOC
Processing Guide für die MSR SW DTD
[ MSRSW-PG]
Version: 5


I. Einleitung

MEDOC
I. Einleitung

Dieses Dokument bildet den Processing Guide für die MSR SW DTD V1.1.0c.
Es bildet die Entwicklungsgrundlage zur Implementierung eines Formatierers zur Erstellung der Dokumentaion eines "Programmstandes" bzw. einer einzelnen Funktion für Papier- und On/Offline-Ausgabe.
Das Zielformat für die Online-Ausgabe ist PDF. Dabei müssen folgende Dinge berücksichtigt werden:
  • Vollständiges [image] Inhaltsverzeichnis als Bookmarks erzeugen.
  • Alle Verzeichnisse werden als Hyperlinknavigatoren ausgeführt.
  • Im Dokumentenbody werden alle Seitenverweise bzw. symbolische Verweise zu Hyperlinks.
  • Innerhalb des Datadictionary erfolgen Hyperlinks von den Übersichtstabellen in die Detailtabellen
  • Alle Stellen, die einen Hyperlink bilden, sind farbig (rot) darzustellen.
  • Zur Optimierung der Volltextsuche muß ein extra Werkzeug von Adobe (Acrobat Catalog) verwendet werden. Der Formatierer muß dafür jedoch Postscript Type 1 Fonts verwenden! Dies hat zur Konsequenz das für die Fonts keine Truetype Fonts verwendet werden können.

Makrostruktur inkl. des Verzeichnis der Funktionen


II. Dokumentenverwaltung

MEDOC
II. Dokumentenverwaltung

Beteiligte Personen
Name | Firma |
Bless, Uwe | DaimlerChrysler AG | Telefon: 0711/17-41723 Abteilung: FT2/EE
Schreblowsky, Jens | XI-Works | Telefon: 0711/248398-0
Fenchel, Klaus | Ovidius GmbH | Telefon: 030/283089-0
Versionsübersicht
Datum | Herausgeber
24.02.99 | Bless, Uwe
30.7.98 | Fenchel, Klaus
17.07.98 | Bless, Uwe
20.6.98 | Fenchel, Klaus
11.05.98 | Bless, Uwe
Änderungen
Änderung | Bezug
Der Wert "1" bei [FIT] einer Abbildung wurde präzisiert. Grund: ATM2000 Anforderung. | Dokument
Dokument
Dokument
Dokument
Dokument
Dokument
Korrektur verschiedener Inkonsistenzen, Einarbeitung von NCOI Grund: - | Dokument
Komplette Dokumentüberarbeitung Grund: - | Dokument
Überarbeitung der semantischen Spezifikationen. Festlegung der Kapitelstrukturen. Definition von Styles für Kapitelstrukturen Grund: - | Dokument
Ersterstellung Grund: - | Dokument
Enthaltene Änderungen
Datum | Kapitel | Änderung | Bezug
24.02.99 | Gesamt | Der Wert "1" bei [FIT] einer Abbildung wurde präzisiert. Grund: ATM2000 Anforderung. | Dokument
 |  | Kapitel Seitenumbrüche eingefügt. Grund: ATM2000 Anforderung. | Dokument
 |  | Kapitel "Variablen- und Kenngrößentabellen" geändert. Grund: ATM2000 Anforderung. | Dokument
 |  | Im Kapitel "Beschreibung einer Funktion" wurde das Präsentationsobjekt "section-body" überarbeitet! So ist z.B. ein Formatiererparameter "erweiteres Funktionsverzeichnis" eingeführt worden. Grund: ATM2000 Anforderung. | Dokument
 |  | Kapitel "Funktionsverzeichnis" überarbeitet. Grund: ATM2000 Anforderung. | Dokument
 |  | Kapitel "Processing Varianten" überarbeitet Grund: ATM2000 Anforderung. | Dokument
30.7.98 | Gesamt | Korrektur verschiedener Inkonsistenzen, Einarbeitung von NCOI Grund: - | Dokument
17.07.98 | Gesamt | Komplette Dokumentüberarbeitung Grund: - | Dokument
20.6.98 | Gesamt | Überarbeitung der semantischen Spezifikationen. Festlegung der Kapitelstrukturen. Definition von Styles für Kapitelstrukturen Grund: - | Dokument
11.05.98 | Gesamt | Ersterstellung Grund: - | Dokument


1. Allgemeine Bemerkungen

MEDOC
1. Allgemeine Bemerkungen

Inhalt dieses Kapitels:
  • 1.1. Protokollierung des Formatiererlaufes
  • 1.2. Konventionen bei der Beschreibung des Processing
  • 1.3. Verwendete Präsentationsstrukturen
  • 1.4. Sprachvarianten
  • 1.5. Prozessierende Firma
  • 1.6. Processing Varianten


1.1. Protokollierung des Formatiererlaufes

Während der Transformation können verschiedene Probleme oder Fehler auftreten, ferner gibt es Fälle, wo Inkonsistenzen in den Dokumenten entdeckt werden.
Diese sollen alle so explizit wie möglich protokolliert werden. Der Anwender soll in der Lage sein, mit Hilfe des Protokolls Fehler im Dokument zu beheben.


1.2. Konventionen bei der Beschreibung des Processing

Bei der Beschreibung des Processing wurde folgende tabellarische Darstellung gewählt:
Projektbeteiligten Processing
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | ... | <comany> |  | Kopfzeile und for each <team-member> Bodyzeile |  |
2 | Kopfzeile |  |  | Zelle1: "Mitarbeiter" Zelle2: "Abteilung" Zelle3: "Adresse" Zelle4: "Telefon / Fax" Zelle5: "Email" |  | Alle Strings in Fixtextlibary
3 | Bodyzeilen | <team-member> | <company>/<team-members> | Zelle1 bis Zelle5 |  |
4 | Zelle1 | <long-name> | <team-member> | ein Absatz: I(<long-name>) ", " I(<roles>/<role>) |  | einzelne <role> durch Komma getrennt.
5 | Zelle2 | <department> | <team-member> | I() |  |
Die Formatierung erfolgt über Präsentationsobjekte wie Tabellen, Listen, etc.
Für bestimmte Elemente in der DTD (Spalte Hook) wird angegeben, auf welches Präsentationsobjekt (Spalte Präsentationsobjekt) sie abgebildet werden, wenn sie in einem bestimmten Kontext (Spalte Kontext) vorkommen. Ferner wird angegeben was der Inhalt des Präsentationsobjektes ist (Spalte Inhalt/Query). Der Inhalt kann
  • entweder generierter Text
  • oder Elementinhalte
  • bzw. weitere Präsentationsobjekte sein.
Die Schreibkonvention I() wird verwendet, wenn der Inhalts des Hooks direkt eingefügt wird.
Die Schreibkonvention pageref() wird verwendet, wenn ein Seitenverweis direkt auf den Hook gemacht wird.
Begriffsdefinitionen
Sourcedokument (Quelldokument)
MSR SW Dokument das formatiert werden soll.
Targetdokument (Zieldokument)
In eine Präsentations-DTD konvertiertes Quelldokument

duch I(<elementname>) gekennzeichnet
durch Hochkomma gekennzeichnet


1.3. Verwendete Präsentationsstrukturen

Dieser Abschnitt enthält eine Liste der verwendeten Präsentationsstrukturen. Ein Dokument hat sowohl Makro- als auch Mikrostrukturen. Zu den Makrostrukturen gehören:
  • Kapitelstrukturen
Zu den Mikrostrukturen gehören:
  • Tabellen
  • Listen
  • Absätze
  • Inline Elemente


1.3.1. Kapitelstrukturen mit Titel

Für die Kapitelebene werden Präsentationsstrukturen verwendet, z.B.:
Section[@level,@style,@target]
    SecTitle[@style,@target]
       SecTitlePrefix
       SecTitleBody
    SecBody
Detailliertere Angaben über die verwendeten Präsentationsstrukturen finden sich in der Entwicklung befindlichen Präsentations-DTD [Präsentations DTD;pres.dtd;txt;editor;no version;]
Die im folgenden angegebenen Styles beziehen sich in der Regel auf die Kapitelüberschrift. Es ist dem Implementierer überlassen, bestimmte Layoutcharacteristika anderen Objekten (z.B. der Section selber) zuzuweisen.


1.3.2. Tabellen

Es stehen mehrere Tabellenmodelle zur Verfügung. Der Implementierer verwendet je nach Tabellenkomplexität ein geeignetes Modell.


1.3.3. Listen

Eine Liste ist ein hierarchisches Objekt mit der folgenden Struktur Details sind mit dem TeXperten zu klären):
List[@item-skip,
     @break-type,
     @label-vskip,
     @label-hskip,
     @label-style,
     @left-indent,
     @body-indent,
     @right-indent]
    IndentMarker
    ListItem
       ItemLabel
       ItemBody
Durch die Attribute kann die Liste wie folgt kontrolliert werden:
item-skip | Abstand zwischen den Listenitems
break-type | Werte: none, cond, break. "none" führt zu einem run-in-label; "break" bricht immer zwischen Label und Itembody um; "cond" bricht nur dann um, wenn das Label in den Body hineinragen würde.
label-vskip | Vertikaler Abstand zwischen Label und Body; greift nur, wenn der Body umbrochen wurde.
label-hskip | Horizontaler Abstand zwischen Label und Body; greift nur, wenn der Body nicht umbrochen wurde.
label-style | Hier sind Characteristics auf Zeichenebene möglich, um die Formatierung des Labels zu kontrollieren
left-indent | Linke Einrückung der gesamten Liste, dies wirkt auf die Einrückung des Labels
body-indent | Linke Einrückung des Itembodys
right-indent | Rechte Einrückung der gesamten Liste
Detailliertere Angaben über die verwendeten Präsentationsstrukturen finden sich in der Entwicklung befindlichen Präsentations-DTD (siehe Präsentations DTD).


1.4. Sprachvarianten

Die SGML Instanzen sind nur einsprachig.
Prinzipiell sollen jedoch verschiedenen Sprachvarianten unterstützt werden. Dies betrifft insbesondere:
  • Wasserzeichen
  • Fixtexte


1.5. Prozessierende Firma

Die prozessierende Firma wird wie folgt festgelegt:
  1. Übergabeparameter
  2. Umgebungsvariable
Der Übergabeparameter überschreibt die Umgebungsvariable.
Für alle referenzierten Firmen muß ein geeignetes Logo zur Verfügung stehen. Ist dies nicht vorhanden, so wird ein Standard-Logo verwendet.


1.6. Processing Varianten

Grundsätzlich muß sowohl ein kompletter Programmstand als auch eine einzelne Funktion formatiert werden können. Befindet sich in der zu formatierenden Instanz mehr wie eine <sw-function> so muß automatisch ein Programmstand erzeugt werden!
Zusätzlich soll zur Standardversion eines Programmstandes auch ein "Applikations-Programmstand" erzeugt werden können. Dies soll über einen Formatiererparameter "Programmstand" = "Standard" oder "Applikation" konfigurierbar sein. "Standard" ist der Defaultwert.


2. Dokumentgrobstruktur

MEDOC
2. Dokumentgrobstruktur

Inhalt dieses Kapitels:
  • 2.1. Dokumentgrobstruktur für einen Programmstand
  • 2.2. Dokumentgrobstruktur für eine SW-Funktion


2.1. Dokumentgrobstruktur für einen Programmstand

  1. Titelseite
  2. Projektbeteiligte geordnet nach Firma
  3. Inhaltsverzeichnis
  4. Verzeichnis der Funktionen (alphabetisch sortiert nach Funktionsnamen)
  5. Querverweisliste
  6. Einleitung incl. der aufgelösten Verweise aus<sw-function-refs>
  7. Funktionsbeschreibungen evtl. mit Funktionsgruppen
    • Gruppe 1
    • Gruppe 2
  8. Weitere Spezifikationen
  9. Anhänge:
    • Glossar
    • Index (<ie>)
    • Technische Begriffe (<tt>)
    • Applikationshinweise (<tt>)
    • Literaturverzeichnis (<xdoc> ,<xfile>, <std>)
Top level processing
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
book
<msrsw>
  • titlepage
  • section (project-members)
  • navigator (toc)
  • navigator (list of functions)
  • navigator (list of cross references)
  • section (introduction, sw-function-refs)
  • section (Funktionsbeschreibungen)
  • section (Weitere Spezifikationen)
  • section (Anhänge)
2
titlepage
-
siehe Titelseitenlayout für den für den Programmstand und die Funktion
Präsentation evtl. mit Boxenmodell, siehe Präsentations DTD
3
section (project members)
<companies>
<project-data>/<project>
siehe Projektbeteiligten Processing
4
navigator (toc)
-
siehe Inhaltsverzeichnis Processing
5
navigator (list of functions)
-
siehe Funktionsverzeichnis Processing (Formatiererpara. "erweiteres Funktionsverzeichnis" = NO)
6
nav (list of cross references)
-
siehe Processing des Kapitels
7
section(introduction, sw-function-refs)
<introduction>
siehe Prozessierung der Einleitung
8
section(Funktions- beschreibungen)
<sw-function-spec>
siehe Prozessierung der Funktionsbeschreibungen
9
section(Weitere Spezifikationen)
<add-spec>
siehe 4.9. Weitere Spezifikationen
10
section (Anhänge)
-
siehe 4.10. Anhänge
Folgende Top-level Elemente werden nicht direkt formatiert:
  • <sw-data-dictionary-spec> ("Datenbank Funktionalität")
  • <sw-param-contents-spec>entfällt
  • <admin-data>("Datenbank Funktionalität")


2.2. Dokumentgrobstruktur für eine SW-Funktion

  1. Titelseite
  2. Einleitung incl. der aufgelösten Verweise aus<sw-function-refs>
  3. Funktionsbeschreibung
  4. Weitere Spezifikationen
  5. Anhänge:
    • Glossar
    • Index (<ie>)
    • Technische Begriffe (<tt>)
    • Applikationshinweise (<tt>)
    • Literaturverzeichnis (<xdoc> ,<xfile>, <std>)
Top level processing
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
book
<msrsw>
  • titlepage
  • section(introduction, sw-function-refs)
  • section (Funktionsbeschreibung)
  • section (Weitere Spezifikationen)
  • section (Anhänge)
2
titlepage
-
siehe Titelseitenlayout für den für den Programmstand und die Funktion
Präsentation evtl. mit Boxenmodell
7
section (introduction, sw-function-refs)
<introduction>
siehe Prozessierung der Einleitung
8
section(Funktionsbeschreibung)
<sw-function-spec>
siehe Funktion Processing
9
section(Weitere Spezifikationen)
<add-spec>
siehe 4.9. Weitere Spezifikationen
10
section (Anhänge)
-
siehe 4.10. Anhänge
Folgende Top-level Elemente werden nicht direkt formatiert:
  • <sw-data-dictionary-spec> ("Datenbank Funktionalität")
  • <sw-param-contents-spec>entfällt
  • <admin-data>("Datenbank Funktionalität")
  • <project-data>entfällt.


3. Generelles Seitenlayout

MEDOC
3. Generelles Seitenlayout

Der Ausdruck des Dokumentes ist nur einseitig und symmetrisch im Aufbau. Dadurch ist ein doppelseitiges Kopieren möglich. Somit ergibt sich ein Seitelayout, wie in folgender Grafik dargestellt:
Abbildung 1: Seitenlayout
In den folgenden Kapiteln werden die einzelnen Bestandteile nochmals im Detail erläutert.


3.1. Dokumenthintergrund

Inhalt dieses Kapitels:
  • 3.1.1. Kopfzeile
  • 3.1.2. Fußzeile
  • 3.1.3. Wasserzeichen


3.1.1. Kopfzeile

Die Kopfzeile besteht aus drei Bereichen, die wie folgt prozessiert werden:
Logo Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | Für jede Funktion <sw-function> muß das Logo der Firma auf die durch <admin-data> /<company-doc-infos> / <company-doc-info>:1 / <company-ref> referenziert wird, eingezogen werden. Existiert kein <admin-data>, so wird dasselbe Logo wie ausserhalb der Funktionsbeschreibung verwendet.
ausserhalb der Funktionsbeschreibung | Logo der prozessierenden Firma.
Feld 1 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | FT("SW-Funktion: "), I(<short-name>) der aktuellen <sw-function>, I(<sw-function>/<admin-data>/<doc-revisions>/<doc-revision>:1/<company-revision-infos>/<company-revision-info>:1/<revsion-label>)
ausserhalb der Funktionsbeschreibung | FT("Kapitel: "), Überschrift des aktuellen Kapitels erster Stufe.
Feld 2 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | FT("Verantwortlicher: "), <long-name> des< team-member> der mit <sw-function>/<admin-data>/<doc-revisions>/<doc-revision>:1/<team-member-ref> referenziert wird.
ausserhalb der Funktionsbeschreibung | entfällt.
Feld 3 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | FT("Telefon: "), <phone> des <team-member> der mit <sw-function>/<admin-data>/<doc-revisions>/<doc-revision>:1/<team-member-ref> referenziert wird.
ausserhalb der Funktionsbeschreibung | entfällt
Feld 4 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | Daimler-Benz spezifisches processing: FT("Geltungsbereich: "), I(<private-code>) mit [Type] = "VAR1" (konfigurierbar) der aktuellen <sw-function>/<admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>
ausserhalb der Funktionsbeschreibung | entfällt.
Feld 5 FT("Seite: "), page, "/", lastpage

Feld 6 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | Daimler-Benz spezifisches processing: FT("Geändert: "), I(<private-code>) mit [Type] = "VAR2" (konfigurierbar) der aktuellen <sw-function>/<admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>
ausserhalb der Funktionsbeschreibung | entfällt.
Feld 7 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | Daimler-Benz spezifisches processing: FT("Erstellt: "), I(<private-code>) mit [Type] = "VAR3" (konfigurierbar) der aktuellen <sw-function>/<admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>
ausserhalb der Funktionsbeschreibung | entfällt.
Feld 8 Es müssen folgende Fälle unterschieden werden:

innerhalb der Funktionsbeschreibung | FT("Status: "), I(<state>) der aktuellen <sw-function>/<admin-data>/<doc-revisions>/<doc-revision>:1/<company-revision-infos>/<company-revision-info>:1
ausserhalb der Funktionsbeschreibung | entfällt.
Auf der Titelseite entällt die Kopfzeile komplett.
Abbildung 2: Beispiel der zu prozessierenden Kopfzeile
Layoutbeispiel siehe zusätzlich auch Abbildung Seitenlayout.


3.1.2. Fußzeile

In der Fußzeile ist das Copyright zu plazieren. Für alle referenzierten Firmen muß ein Copyright-Vermerk vorhanden sein. Ist dies nicht der Fall, so wird ein Standard-Copyright verwendet.
Es müssen folgende Fälle unterschieden werden:
innerhalb der Funktionsbeschreibung | Für jede Funktion <sw-function> muß der Copyright-Vermerk der Firma auf die durch <admin-data>/<company-doc-infos>/<company-doc-info>:1/<company-ref> referenziert wird, erzeugt werden. Existiert kein <admin-data>, so wird der Copyright-Vermerk wie ausserhalb der Funktionsbeschreibung verwendet.
ausserhalb der Funktionsbeschreibung | Copyright-Vermerk der prozessierenden Firma.
Layoutbeispiel siehe Abbildung Seitenlayout.


3.1.3. Wasserzeichen

Das Wasserzeichen ist im Winkel von 45° in hellgrauer Schrift in einer konfigurierbaren Größe mit einem benutzerdefinierbaren Inhalt zu prozessieren.


3.2. Seitengeometrie

Das Seitenlayout ist DIN A4 Hochformat.
Minimalwerte: Seitenrand rundrum 1 cm
Der eigentliche Text befindet sich im Rahmen mit einem Abstand von 0,5 cm zu diesem.


3.3. Seitenumbrüche

Die Seiteumbrüche sind so zu gestalten daß
  • Kapitelüberschriften (<long-name> in Element <chapter>) nicht alleine (ohne nachfogende Graphik oder Tetxt) auf einer Seite stehen bleiben sondern die Überschriften in diesen Fällen ebenfalls mit auf die nächste Seite geschrieben werden.
  • keine Trennung zwischen Tabellenüberschrift und Tabelle erfolgt
  • bei größeren Tabellen (<table> mindestens fünf Zeilen am Seitenende sichtbar sind. Bei weniger als fünf Zeilen soll die Tabelle ganz auf die nächste Seite übernommen werden.
  • bei größeren Listen mindestens fünf Zeilen am Seitenende sichtbar sind. Bei weniger als fünf Zeilen soll die Liste ganz auf die nächste Seite übernommen werden.
  • wenn ein Seitenumbruch innerhalb einer Tabelle (<table>) erfolgt, soll der Tabellenkopf ebenfalls zu Beginn der Tabelle auf der nächsten Seite hinzugefügt werden.


4. Module

MEDOC
4. Module

Inhalt dieses Kapitels:
  • 4.1. Titelseite
  • 4.2. Projektbeteiligte
  • 4.3. Inhaltsverzeichnis
  • 4.4. Funktionsverzeichnis
  • 4.5. Verwendung der Kenngrößen und Softwarevariablen
  • 4.6. Einleitung
  • 4.7. Funktionsbeschreibungen
  • 4.8. Beschreibung einer Funktion
  • 4.9. Weitere Spezifikationen
  • 4.10. Anhänge


4.1. Titelseite

Im folgenden wird ein generisches Titelseitenlayout vorgeschlagen. Auf der Titelseite stehen vordefinierte Felder zur Verfügung. Diese können unternehmensspezifisch durch Inhalte gefüllt werden. Der Formatierer ist so zu gestalten, daß die Konfiguration, wie diese Felder jeweils zu befüllen sind, mit relativ geringem Aufwand änderbar ist. MetaMorphosis Programmierkenntnisse sind hierfür allerdings erfrorderlich, da die jeweiligen Inhalte der Felder durch MetaMorphosis Queries erzeugt werden.
Sollte eine Firma ein komplett anderes Layout als das vorgeschlagene wünschen, wird der hierfür erforderliche Aufwand natürlich höher.
Das Titelseitenlayout für die Erzeugung eines Programmstandes und einer einzelnen SW-Funktion ist identisch. Die Bestückung der einzelnen Felder auf der Titelseite ist zwischen diesen beiden Prozessiervarianten unterschiedlich.
Abbildung 3: Titelseitenlayout für den für den Programmstand und die Funktion
Daimler-Benz spezifische Belegung für den Programmstand:
Feld1 | Projektgrafik
Feld2 | FT("Programmstand"), " ", I(<private-code>) mit [Type] = "Titelfeld2" (konfigurierbar) von <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>
Feld3 | I(<private-code>) mit [Type] = "Titelfeld3" (konfigurierbar) der aktuellen <sw-function>/<admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>
Feld4 | FT("Gesamtprojekt"), " ", I(<project-data>/<overall-project>/<label>)
Feld5 | FT("Projekt"), " ", I(<project-data>/<project>/<label>)
Feld6 | FT("Datum"), " ", I(<private-code>) mit [Type] = "Titelfeld6" (konfigurierbar) von <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld7 | I(<private-code>) mit [Type] = "Titelfeld7" (konfigurierbar) von <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld8 | I(<private-code>) mit [Type] = "Titelfeld8" (konfigurierbar) von <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld9 | I(<private-code>) mit [Type] = "Titelfeld9" (konfigurierbar) von <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Daimler-Benz spezifische Belegung für eine Funktion:
Feld1 | Projektgrafik
Feld2 | FT("SW-Funktion"), " ", I(<short-name>) der prozessierten <function>, Blank(4), I(<admin-data>/ <doc-revisions>/<doc-revision>:1/<company-revision-infos>/<company-revision-info>:1/<revision-label> der prozessierten <function>.
Feld3 | I(<long-name>) der prozessierten <function>
Feld4 | I(<private-code>) mit [Type] = "Titelfeld4" (konfigurierbar) von <sw-function-spec>/<sw-functions>/<sw-function>/ <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld5 | I(<private-code>) mit [Type] = "Titelfeld5" (konfigurierbar) von <sw-function-spec>/<sw-functions>/<sw-function>/ <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld6 | I(<private-code>) mit [Type] = "Titelfeld6" (konfigurierbar) von <sw-function-spec>/<sw-functions>/<sw-function>/ <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld7 | I(<private-code>) mit [Type] = "Titelfeld7" (konfigurierbar) von <sw-function-spec>/<sw-functions>/<sw-function>/ <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld8 | I(<private-code>) mit [Type] = "Titelfeld8" (konfigurierbar) von <sw-function-spec>/<sw-functions>/<sw-function>/ <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Feld9 | I(<private-code>) mit [Type] = "Titelfeld9" (konfigurierbar) von <sw-function-spec>/<sw-functions>/<sw-function>/ <admin-data>/<company-doc-infos>/<company-doc-info>:1/<private-codes>)
Allgemein gilt:
Wenn die Query für ein bestimmtes Feld kein Resultat liefert, ist auch der entsprechende Fixtext nicht auszugeben.
Wenn Felder entfallen, rücken die nachfolgenden Felder nach oben (keine Lücken)! (Dies legt nahe, die Boxen, die die Felder enthalten nicht fest zu positionieren, sondern stattdessen eine Tabelle ohne Ränder zu generieren)
Abbildung 4: Beispiel eines Programmstandes


4.2. Projektbeteiligte

Eine Prozessierung der Firma mit ihren Projektbeteiligten ist wie folgt vorzunehmen:
Projektbeteiligten Processing
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section Ebene 2
<companies>
  • Überschrift: (Ebene 2): "Am Projekt beteiligte Firmen"
  • for each <company>: Section Ebene 3)
Überschrift: section2
Alle Strings als Fixtexte
newright page
no number
keep with next
TOC=NO
2
Section Ebene 3
<company>
<project-data>/<project>/<companies>
  • Überschrift Ebene (3)
  • Tabelle
no number
keep with next
TOC=NO
3
Überschrift Ebene (3)
<long-name>
<company>
I()
topic
4
Tabelle
<company>
Kopfzeile und for each <team-member> Bodyzeile
5
Kopfzeile
Zelle 1: "Mitarbeiter"
Zelle 2: "Abteilung"
Zelle3: "Adresse"
Zelle4: "Telefon / Fax"
Zelle5: "Email"
Alle Strings als Fixtexte
6
Bodyzeile
<team-member>
<company>/<team-members>
Zelle1 bis Zelle5
7
Zelle1
<long-name>
<team-member>
Absatz: I(<long-name>) ", " I(<roles>/<role>)
einzelne <role> durch Komma getrennt.
8
Zelle2
<department>
<team-member>
I()
9
Zelle3
<adress>oder<city> oder<zip>
<team-member>
Absatz: I(<address>)
Absatz: I(<zip>), " ", I(<City>)
10
Zelle4
<phone> oder<fax>
<team-member>
Absatz: "T: ", I(<phone>)
Absatz: "F: ", I(<fax>)
Alle Strings in Fixtextlibary
11
Zelle5
<email> oder<homepage>
<team-member>
Absatz: I(<email>)
Absatz: I(<homepage>)
Abbildung 5: Beispiel des Processing von Projektbeteiligten


4.3. Inhaltsverzeichnis

Das Inhaltsverzeichnis gibt einen groben Überblick über das Dokument. Es enthält nicht die einzelnen Funktionen, diese sind in einem separaten Funktionenverzeichnis (siehe 4.4. Funktionsverzeichnis) enthalten.
Das Inhaltsverzeichnis ist ein Navigator, der erst aufgrund des in die Präsentationsstruktur überführten Dokumentes erstellt wird. Aus diesem Grunde sind die Hooks alle im Zieldokument und nicht im Quelldokument zu finden.
Die Prozessierung des Inhaltsverzeichnisses ist wie folgt vorzunehmen:
Inhaltsverzeichnis Processing
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section Ebene 2
  • Überschrift: "Inhaltsverzeichnis"
  • Tabelle
section2
new right page
no number
keep with next
TOC=NO
2
Tabelle
for each section im Targetdokument mit TOC=YES Bodyzeile
Ohne Tabellen und Zellenränder
3
Bodyzeile1
section
TOC = YES
Zelle1: Nummer wie im Dokumentbody
Zelle1: Überschrift wie im Dokumentbody
Zelle 2: pageref()
Alle Strings als Fixtexte
Unterüberschriften (Gruppierungen im Funktionenverzeichnis, Anhänge) eingerückt; es sind maximal 3 Einrückungsstufen vorzusehen.
Abbildung 6: Beispiel des Processing des Inhaltsverzeichnisses


4.4. Funktionsverzeichnis

Das Funktionsverzeichnis wird hier der Einfachkeit halber mit Bezug auf das Quelldokument spezifiziert, da dort die notwendigen semantischen Strukturen für die Queries vorliegen. Die Seitenverweise im Verzeichnis beziehen sich natürlich auf das Zieldokument. Die Details der Realisierung werden dem Implementierer überlassen.
Die Prozessierung des Funktionsverzeichnisses ist wie folgt vorzunehmen:
Funktionsverzeichnis Processing (Formatiererpara. "erweiteres Funktionsverzeichnis" = NO)
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section 1
  • Überschrift: "Verzeichnis der Funktionen"
  • Tabelle
Überschrift: section1
Alle Strings in Fixtextlibary
new right page
number
keep with next
TOC=YES
2
Tabelle
Kopfzeile und for each <sw-function> Bodyzeile
Ohne Tabellen und Zellenränder
Die Bodyzeilen sind nach dem short name der sw-function zu sortieren.
3
Kopfzeile
Zelle 1: "Seite"
Zelle2: "Funktion"
Zelle 3: "Version"
Zelle 4: "Funktionsbezeichnung"
Alle Strings in Fixtextlibary
Darstellung in Fettdruck
4
Bodyzeile
<sw-function>
<msr-sw>/<sw-function-spec>/<sw-functions>
Zelle1 bis Zelle4
Die Zellen sind nach dem <short-name>des Hooks alphabetisch zu sortieren.
5
Zelle1
Pageref( <sw-function>)
6
Zelle 2
<sw-function>
I(<short-name>)
7
Zelle 3
<revision-label>
<admin-data>/<doc-revisions>/<doc-revision>:1/<company-revision-infos>/<company-revision-info>:1
I()
8
Zelle4
<sw-function>
I(<long-name>)
Abbildung 7: Beispiel Funktionsverzeichnis beim Formatiererparameter "erweiteres Funktionsverzeichnis" = NO
Funktionsverzeichnis Processing (Formatiererpara. "erweiteres Funktionsverzeichnis" = YES)
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section 1
  • Überschrift: "Verzeichnis der Funktionen"
  • Tabelle
Überschrift: section1
Alle Strings in Fixtextlibary
new right page
number
keep with next
TOC=YES
2
Tabelle
Kopfzeile und for each <sw-function> Bodyzeile
Ohne Tabellen und Zellenränder
Die Bodyzeilen sind nach dem short name der sw-function zu sortieren.
3
Kopfzeile
Zelle 1: "Seite"
Zelle2: "Funktion"
Zelle 3: ""
Zelle4: "Funktionsbezeichnung"
Alle Strings in Fixtextlibary
Darstellung in Fettdruck
4
Bodyzeile
<sw-function>
<msr-sw>/<sw-function-spec>/<sw-functions>
Zelle1 bis Zelle4
Die Zellen sind nach dem <short-name>des Hooks alphabetisch zu sortieren.
5
Zelle1
Pageref( <sw-function>) oder Pageref(<sw-function-def>) oder Pageref(<sw-function-desc>) oder Pageref(<sw-fulfils>) oder Pageref(<sw-function-variables>) oder Pageref(<sw-param-refs>) oder Pageref(<sw-function-def>) oder Pageref(<sw-data-dictionary-spec>) oder Pageref(<sw-param-content-spec>) oder Pageref(<sw-test-spec>) oder Pageref(<sw-application-notes>) oder Pageref(<sw-function-def>) oder Pageref(<sw-maintenance-notes>) oder Pageref(<sw-carb-doc>) oder Pageref(<sw-decomposition>) oder Pageref(<annotations>) oder Pageref(<add-info>) oder Pageref(<chapter>)
Die Ausgabe der Seitenzahl ist abhänig vom auftreten des jeweiligen Elementes.
6
Zelle 2
<sw-function>
I(<short-name>)
Zellenverschmelzung nach unten
7
Zelle3
<revision-label> oder <sw-function-def> oder <sw-function-desc> oder <sw-fulfils> oder <sw-function-variables> oder <sw-param-refs> oder <sw-function-def> oder <sw-data-dictionary-spec> oder ...
<admin-data>/<doc-revisions>/<doc-revision>:1/<company-revision-infos>/<company-revision-info>:1
"Version:" , I() oder Kapitelnummer, " Modellbasierte Funktionsspezifikation" oder Kapitelnummer, "SW-Funktionsbeschreibung" oder Kapitelnummer, "SW-Funktion deckt folgende Funktionen ab" oder Kapitelnummer, "Datenlexikon Spezifikation" oder ...
Alle chapter innerhalb der Elemente in der links definierten Spalte "Hook" bekommen in der Kapitelnummer die Hierarchie vererbt.
7
Zelle 3
... oder <sw-test-spec> oder <sw-application-notes> oder <sw-function-def> oder <sw-maintenance-notes> oder <sw-carb-doc> oder <sw-decomposition> oder <annotations> oder <add-info>oder <long-name> von <chapter>
<admin-data>/<doc-revisions>/<doc-revision>:1/<company-revision-infos>/<company-revision-info>:1
... oder Kapitelnummer, "Testhinweise" oder Kapitelnummer, "Applikationshinweise" oder Kapitelnummer, "Kundendiensthinweise" oder Kapitelnummer, "CARB" oder Kapitelnummer, "SW-Funktionsdekomposition" oder Kapitelnummer, "Anmerkungen" oder Kapitelnummer, "Ergänzende Angaben" oder Kapitelnummer, I()
Alle chapter innerhalb der Elemente in der links definierten Spalte "Hook" bekommen in der Kapitelnummer die Hierarchie vererbt.
8
Zelle4
<sw-function>
I(<long-name>)
Zellenverschmelzung nach unten
Abbildung 8: Beispiel Funktionsverzeichnis beim Formatiererparameter "erweiteres Funktionsverzeichnis" = YES


4.5. Verwendung der Kenngrößen und Softwarevariablen

Das Verzeichnis der Verwendung der Kenngrößen und Softwarevariablen wird hier der Einfachkeit halber mit Bezug auf das Quelldokument spezifiziert, da dort die notwendigen semantischen Strukturen für die Queries vorliegen. Die Seitenverweise im Verzeichnis beziehen sich natürlich auf das Zieldokument. Die Details der Realisierung werden dem Implementierer überlassen
Die Prozessierung ist wie folgt vorzunehmen:
Processing des Kapitels
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section 1
  • Überschrift: "Verwendung der Kenngrößen und Softwarevariablen"
  • Section(Kenngrößen)
  • Section(Softwarevariablen)
Überschrift: section2
Alle Strings in Fixtextlibary
new right page
number
keep with next
TOC=YES
2
Section(Kenngrößen)
  • Überschrift: "Kenngrößen"
  • Tabelle(Kenngrößen), siehe Processing der Tabelle Kenngrößen
Überschrift: topic
no new page
no number
keep with next
TOC=NO
3
Section (Softwarevariablen)
  • Überschrift: "Softwarevariablen"
  • Topic(Legende)
  • Tabelle(Softwarevariablen) sieheProcessing der Tabelle Softwarevariablen
Überschrift: topic
no new page
no number
keep with next
TOC=NO
4
Topic (Legende)
FT(als komplettes SGML Fragment; sieheBeispiel Softwarevariablen)
Processing der Tabelle Kenngrößen
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Tabelle |  |  | Kopfzeile und for each <sw-param> Bodyzeile |  | Ohne Tabellen und Zellenränder
2 | Kopfzeile |  |  | Zelle 1: "Symbol" Zelle 2: "Deklariert in" Zelle 3: "Referenziert von" |  | Alle Strings in Fixtextlibary Darstellung in Fettdruck
3 | Bodyzeile | <sw-param> | <sw-datadictionary> | Zelle1 bisZelle 3 |  | Die Zeilen sind nach dem <short-name>des Hooks alphabetisch zu sortieren.
4 | Zelle1 | <short-name> | <sw-param> | I( ) |  |
5 | Zelle2 | <sw-param> |  | I(<sw-function>/<short-name>) für die gilt:<sw-param-refs>/<sw-param-ref >exitiert mit [owns]ungleich "noown" und[sw-param] = Hook[id], " (" Pageref(<sw-function>), ")" |  | hier muß genau ein Ergebnis geliefert werden.
6 | Zelle3 | <sw-param> |  | I(<sw-function>/<short-name>) für die gilt:<sw-param-refs>/<sw-param-ref >exitiert mit [owns]gleich "noown" und[sw-param] = Hook[id], " (" Pageref(<sw-function>), ")" |  | hier können 0 .. n Werte zurückgegeben werden, die durch ", " getrennt werden.
Abbildung 9: Beispiel Kenngrößen
Processing der Tabelle Softwarevariablen
Nr.
Präsent.- Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Tabelle
Kopfzeile und for each <sw-variable> Bodyzeile
Ohne Tabellen und Zellenränder
2
Kopfzeile
Zelle 1: "Symbol"
Zelle 2: "Typ"
Zelle 3: "Erzeugt in"
Zelle 4: "Verwendet von"
Alle Strings in Fixtextlibary
Darstellung in Fettdruck
3
Bodyzeile
<sw-variable>
<sw-datadictionary>
Zelle1 bisZelle 4
Die Zeilen sind nach dem <short-name>des Hooks alphabetisch zu sortieren.
4
Zelle1
<short-name>
<sw-variable>
I( )
5
Zelle2
<sw-variable>

"AUS" wenn: | <sw-function-export-variables> existiert für das gilt: Enthält <sw-variables-ref> mit<sw-variable> = Hook([id])
"EIN" wenn: | nicht die Bedingung für "AUS" gilt und<sw-function-import-variables> existiert für das gilt: Enthält <sw-variables-ref> mit<sw-variable> = Hook([id])
Als Ergebnis darf nur ein Typ zurückgeliefert werden, sonst Fehler!
5
Zelle2
<sw-variable>

"DOK" wenn: | <sw-function-modelonly-variables> existiert für das gilt: Enthält <sw-variables-ref> mit<sw-variable> = Hook([id])
"LOK" wenn: | <sw-function-local-variables> existiert für das gilt: Enthält <sw-variables-ref> mit<sw-variable> = Hook([id])
Als Ergebnis darf nur ein Typ zurückgeliefert werden, sonst Fehler!
6
Zelle3
<sw-variable>
I(<sw-function>/<short-name>) für die gilt: <sw-function-variables>/Not(<sw-function-import-variables>)/*/<sw-variable-ref>exitiert mit [sw-variable]= Hook[id], " (" Pageref(<sw-function>), ")"
hier darf höchstens ein Ergebnis geliefert werden.
7
Zelle4
<sw-param>
I(<sw-function>/<short-name>) für die gilt: <sw-function-variables>/<sw-function-import-variables>/*/<sw-variable-ref>exitiert mit [sw-variable]= Hook[id], " (" Pageref(<sw-function>), ")"
hier können 0 .. n Werte zurückgegeben werden, die durch ", " getrennt werden.
Abbildung 10: Beispiel Softwarevariablen


4.6. Einleitung

Das Kapitel Einleitung kombiniert die Knoten <introduction>und <sw-function-ref>. Letzterer ist enthalten in einem nicht numerierten Topic am Ende der Einleitung.
Die Prozessierung ist wie folgt vorzunehmen:
Prozessierung der Einleitung
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Section 1 | <introduction> |  | Überschrift: "Einleitung", I() (NCOI processing siehe5. NCOI Elemente),Topic | Überschrift: section1 | new right page number keep with next TOC=YES
3 | Topic | <sw-function-refs> | <msrsw> | Überschrift: "Weitere Softwarefunktionen", Liste | Überschrift: topic | Alle Strings in Fixtextlibary Darstellung in Fettdruck no new page no number keep with next TOC=NO
4 | Liste | <sw-function-refs> | <msr-sw> | for each <sw-function-ref> Item |  | Die Zellen sind nach dem <short-name>des Hooks alphabetisch zu sortieren.
5 | Item | <sw-function-ref> |  | siehe 5.3.1.1. Prozessierung von dokumentübergreifenden Referenzen |  |


4.7. Funktionsbeschreibungen

Der größte Teil des Dokumentes besteht aus Funktionsbeschreibungen (<sw-function-spec>/<sw-functions>/<sw-function>/<sw-function-variants>/<sw-function-variant>). De facto kommt immer nur eine Variante vor. Ein Prozessieren mehrerer Varianten ist nicht vorzusehen.
Einzelne Funktionsbeschreibungen können zu Gruppen zusammengefaßt werden. Allerdings handelt es sich dabei nicht um eine echte hierarchische Gliederung. Vielmehr werden einzelne <sw-function>Elemente als "Trenner" verwendet.
Es gibt zwei Variablen: msr-doc-only-1 und msr-doc-only-2. Wenn im Inhalt des Elements<sw-function>/<sw-function-class>der Wert von msr-doc-only-1 auftritt, beginnt diese<sw-function> eine Gruppierung. Wenn im Inhalt des Elements <sw-function>/<sw-function-class>der Wert von msr-doc-only-2 auftritt, beginnt diese<sw-function> eine Untergruppierung.
Es ist Aufgabe der erzeugenden Applikation sicherzustellen, daß diese mit rein linearen Mitteln erzeugte Hierarchie sinnvoll ist.
Prozessierung der Funktionsbeschreibungen
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section 1
<sw-function-spec>
  • Überschrift: "Funktionsbeschreibungen"
  • I(<introduction>)
  • for each <sw-function>:Section2; Reihenfolge ist gleich der Reihenfolge des Auftretens in der Instan z
Überschrift: section1
Die Nummerierung ist synchon zur Ebenenhierarchie!
Die <sw-functio>s sind alle auf der selben Ebene, es wird jedoch eine implizite Hierrachie mit Hilfe des Elementes<sw-function-class>erzeugt.
new right page
number
keep with next
if <sw-function-class>= VAR(msr-doc-only-1) or VAR(msr-doc-only-2): TOC=YES, else TOC=NO
2
Section2
<sw-function>
<sw-function-class>= VAR(msr-doc-only-1)
Überschrift(msr-doc-only-1), Section-body (siehe Funktion Processing)
if not first: new page
number
keep with next
TOC=YES
3
Section3
<sw-function>
<sw-function-class>= VAR(msr-doc-only-2)
Überschrift(msr-doc-only-2), Section-body (siehe Funktion Processing)
if not first: right page
number
keep with next
TOC=YES
4
Section4
<sw-function>
<sw-function-class>not = [VAR(msr-doc-only1) oder VAR(msr-doc-only2)]
Überschrift (function), Section-body (siehe Funktion Processing)
Dies ist eine echte Funktion. Alle echten Funktionen werden mit dem Style functionformatiert, d.h. ihre Überschriften-formatierung ist immer fest. Ändern kann sich nur die durch die Numerierung ausgedrückte Einbettungstiefe
no new page
number
keep with next
TOC=YES
5
Überschrift (msr-doc-only-1)
NUMBER(), I(<short-name>), BLANK(4), I(<long-name>)
section2
6
Überschrift (msr-doc-only-2)
NUMBER(), I(<short-name>), BLANK(4), I(<long-name>)
section3
7
Überschrift (function)
NUMBER(), I(<short-name>), BLANK(4), " (", I(<admin-data> / <doc-revisions> /<doc-revision>:1 /<company-revision-infos> /<company-revision-info>:1 /<revision-label>), ")", BLANK(4), I(<long-name>)
function
Abbildung 11: Beispiel für Funktionsbeschreibungen

Wenn die Hierarchie des zu prozessierenden Dokumentes nicht sinnvoll ist, so ist dies im Protokoll zu vermerken
Sind mehrere Varianten vorhanden, so ist dies im Protokoll zu vermerken


4.8. Beschreibung einer Funktion

Die Funktionsbeschreibung (eine stellvertretend für alle) besteht aus den folgenden Kapitel:
Funktion Processing
Nr.
Präsent.- Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section-body
<sw-function-variant>
  • Section(sw-function-def)
  • Section (sw-function-desc)
  • Section (sw-fulfils)
  • Section(sw-data-dictionary)
  • Section(sw-test-spec)
  • Section(sw-application-notes)
  • Section(sw-maintanance-note)
  • Section(sw-carb-doc)
  • Section(sw-decomposition)
  • Section (anotations)
  • Section(add-info)
Es gibt nur eine Variante!
Section-bodyist nur ein Platzhalter und keinPräsentationsobjekt!
alle Sections mit Style chapter
no new page
number (inherit from top), d.h. Numerierung wird innerhalb der Funktionen fortgeführt; die übergeordnete Hierarchie wird übernommen.
keep with next
TOC=NO oder YES über Parameter "erweiteres Inhaltsverzeichnis" beim Formatieren konfigurierbar!
2
Section(sw-function-def)
<sw-function-def>
  • Überschrift: "Modellbasierte Funktionsspezifikation")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
3
Section(sw-function-desc)
<sw-function-desc>
  • Überschrift: "SW-Funktionsbeschreibung")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
4
Section(sw-fulfils)
<sw-fulfils>
  • Überschrift: "SW-Funktion deckt folgende Funktionen ab")
  • Liste(refs)
Übrschrift: chapter
5
Section(sw-data-dictionary)
<sw-data-dictionary>
  • Übrschrift: chapter
    Überschrift: "Datenlexikon Spezifikation")
  • Section(sw-data-dictionary), siehe4.8.1. Variablen- und Kenngrößentabelle
Übrschrift: chapter
6
SeSection (sw-test-spec)
<sw-test-spec>
  • Überschrift: "Testhinweise")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
7
Section(sw-application-notes)
<sw-application-notes>
  • Überschrift: "Applikationshinweise")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
8
Section(sw-maintanance-note)
<sw-maintanance-note>
  • Überschrift: "Kundendienstinformationen")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
9
Section(sw-carb-doc)
<sw-carb-doc>
  • Überschrift: "Carb")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
10
Section (sw-decomposition)
<sw-decomposition>
  • Überschrift: "SW-Funktionskomposition")
  • Absatz: FT("Diese Funktion enthält folgende Unterfunktionen:")
  • Liste(sw-decomposition)
Übrschrift: chapter
11
Section(annotations)
<annotations>
  • Überschrift: FT("Anmerkungen")
  • Tabelle(annotations), sieheProzessierung der Anmerkungen
Übrschrift: chapter
12
Section(add-info)
<add-info>
  • Überschrift: FT("Ergänzende Angaben")
  • I(); siehe5. NCOI Elemente
Übrschrift: chapter
13
Liste (refs)
<sw-fulfils>
Item(function-ref)
14
Item (function-ref)
for each <function-ref>
siehe Kapitel 5.3.1.1. Prozessierung von dokumentübergreifenden Referenzen
Dokumentübergreifende Referenzen
15
Liste (sw-decomposition)
<sw-decomposition>
Item(sw-function-ref)
16
Item(sw-function-ref)
<sw-function-ref>
siehe Kapitel 5.3.1.1. Prozessierung von dokumentübergreifenden Referenzen und Kapitel 5.3.1.2. Prozessierung von dokumentinternen Referenzen
Interne oder dokumentübergreifende Referenzen
Abbildung 12: Beispiel Funktion Processing
Prozessierung der Anmerkungen
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Tabelle(anotations) | <anotations> |  | Kopfzeile und for each <anotation>:Bodyzeile |  | Ohne Tabellen und Zellenränder
4 | Kopfzeile |  |  | Zelle 1: "Bezeichnung" Zelle 2: "Ursprung der Anmerkung" Zelle 3: "Anmerkungstext" | Breiten: Zelle1: 1* Zelle2: 1* Zelle3: 3* | Alle Strings in Fixtextlibary Darstellung in Fettdruck
5 | Bodyzeilen | <anotation> |  | Zelle 1 bisZelle3 |  |
5 | Zelle1 | <label> |  | I() |  |
6 | Zelle2 | <anotation-origin> |  | I() |  |
7 | Zelle3 | <anotation-text> |  | I() |  |
Abbildung 13: Beispiel Anmerkungen Processing

Sollten doch mehrere Varianten vorkommen, ist die erste zu prozessieren. Die Tatsache, daß mehrere vorkommen ist im Protokoll festzuhalten.


4.8.1. Variablen- und Kenngrößentabelle

Die Informationen des Datenlexikons werden tabellenartig dargestellt. Eine detaillierte Beschreibung zum Aufbau ist MSR-Software DTD - Erzeugung von Funktions/Datenrahmen zu entnehmen.
Im Bezug zum bisher erzeugtem Papierdokument (Bosch Formatierer) ist in den Tabellen
  • Exportierte Ramgrößen: Details
  • Importierte Ramgrößen: Details
  • Lokale Ramgrößen: Details
die Spaltenbreite der Spalte "Wertebereich" zu vergrößern und um die mögliche enthaltene Zeichenanzahl zu erhöhen. Die Spaltenbreite der Spalte "Zeitraster" kann verkleinert werden, da sie größer ist als für die enthaltene Zeichenanzahl benötigt.
Abhänig von der Formatierunsgvariante muß bei der Erzeugung eines "Applikations-Programmstandes" folgende Abweichungen gegenüber der im Dokument MSR-Software DTD - Erzeugung von Funktions/Datenrahmen spezifizierten Inhalte:
  1. Folgende Übersichtstabellen können entfallen:
    • Exportierte Ramgrößen: Übersicht
    • Importierte Ramgrößen: Übersicht
    • Lokale Ramgrößen: Übersicht
    • Exportierte Kenngrößen: Übersicht
    • Importierte Kenngrößen: Übersicht
  2. In den Detailtabellen
    • Exportierte Ramgrößen: Details
    • Importierte Ramgrößen: Details
    • Lokale Ramgrößen: Details
    können folgende Spalten entfallen:
    • Zeitraster
    • Datentyp
    • Ele"Anz
    • Zugriff
    Der so gewonnene Platz soll für die seither in der Übersichtstabelle enthaltenen Spalte "Langbezeichner" verwendet werden.
  3. In den Detailtabellen
    • Exportierte Kenngrößen: Details
    • Importierte Kenngrößen: Details
    können folgende Spalten entfallen:
    • Quantisierung
    • Maßeinheit
    • MaxStst
    Der so gewonnene Platz soll für die seither in der Übersichtstabelle enthaltenen Spalte "Langbezeichner" verwendet werden.
  4. Die Tabellen
    • Umrechnungsformel: Übersicht
    • Umrechnungsformel: Details
    entfallen in den einzelnen Funktionsbeschreibungen. Statt dessen soll eine komplette Liste aller verwendeten Umrechnungsformeln als
    • Umrechnungsformeln: Details
    mit zusätzlicher Spalte "Langbezeichner" im Anhang hinzugefügt werden.
  5. Das Kapitel "Testhinweise" (<sw-test-spec>) kann in der Funktionsbeschreibung entfallen.


4.8.2. Behandlung von Applikationshinweisen

Dieses Kapitel ist Daimler-Benz spezifisch.
Wenn innerhalb von <sw-application-notes> ein <chapter> mit I(<short-name>) = "PrmNotes" existiert, so ist dieses <chapter> wie folgt zu prozessieren:
  1. Für jedes <topic> innerhalb dieses <chapters>gilt:
    • Enthält es neben dem <long-name> nur einen <p>mit folgendem Inhalt: "*** Bitte Beschreibung für Kenndatum eingeben ***" , so ist das <topic>zu entfernen.
    • Enthält das <topic> neben dem <long-name> mehr als einen <p> so ist der <p>mit folgendem Inhalt: "*** Bitte Beschreibung für Kenndatum eingeben ***" , zu entfernen.
  2. Für das chapter insgesamt gilt:
    • Enthält das <chapter> nach Anwendung von 1. keinen <topic> mehr wird das <chapter>entfernt.
    • Anderenfalls wird <p> mit dem Inhalt "*** Kurzbezeichnung nicht ändern !!! ***" entfernt.
Wenn innerhalb von <sw-application-notes> ein <chapter> mit I(<short-name>) = "DelPrmNotes" existiert, so ist dieses <chapter> zu löschen!
Zur Erkennung der Strings soll ein konfigurierbares Präfix z.B. "*** " verwendet werden.


4.9. Weitere Spezifikationen

Nur zu erzeugen, wenn mindestens ein Anhang erzeugt wird.
Hierbei handelt es sich um ein Kapitel oberster Stufe, dessen Inhalt im wesentlichen über <NCOI> abgedeckt wird.
Prozessierung der "Weiteren Spezifikationen"
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Section 1 | <add-spec> |  | Überschrift: "Weitere Spezfikationen", I() (NCOI processing siehe5. NCOI Elemente),Topic | Überschrift: section1 | new right page number keep with next TOC=YES


4.10. Anhänge

Prozessierung der Funktionsbeschreibungen
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Section
-
Überschrift: Anhänge
  • section(glossar)
  • section(index) siehe 4.10.2. Index
  • section(techterms) siehe 4.10.3. Technische Begriffe
  • section(apphinw) siehe 4.10.4. Applikationshinweise
  • section(litlist) siehe 4.10.5. Literaturverweise
Überschrift: level1
new right page
number
keep with next
TOC=YES
Die einzelnen Anhänge sind nur zu erstellen, wenn sie Inhalt haben, also z.B. mindesten ein <ie> Element im Quelldokument vorhanden ist. Ist kein einziger Anhang vorhanden, ist auch das übergordnete Kapitel "Anhänge" nicht zu erzeugen.
2
section (glossar)
<sw-glossary>
Überschrift: "Glossar", Glossarbody siehe 5. NCOI Elemente
Überschrift: level2


4.10.1. Glossar

Prozessierung siehe 5. NCOI Elemente


4.10.2. Index

Nur zu erzeugen, wenn mindestens ein <ie> im Quelldokument enthalten ist.
Indexeinträge werden mit <ie>definiert. Da <ie> einstufig ist, wird auch der Index nur einstufig. Über [type] kann ein Indexeintrag einer Klasse zugewiesen werden. Jede Klasse bildet einen eigenen Index mit einer Überschrift (String der Klasse).
Der Index ist mindestens zwei-, besser sogar drei-spaltig zu setzten. Mit Begin einer neuen Indexklasse sind die Spalten des darüberliegenden Indexes zu balancieren. Ist dies nicht möglich muß ein anderes Verfahren gewählt werden z.B. die neue Klasse fängt oben in einer neuen Spalte an.
Prozessierung des Indexes
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Section | - |  | Überschrift: "Index", Indexbody | Überschrift: level2 |
2 | Indexbody | - |  | mehrere Indexeinträge oder Indexklassen |  | Als Index mit Indexletter (mit Style indexletter) zu prozessieren; als indexletters sind nur A-Z sowie ein Stringt "Symbole" (als fixtext) vorzusehen. Alle Buchstaben mit Diakritika sind unter dem jew. Indexletter ohne Diakritikum darzustellen (z.B. "Änderung" unter "A". Indexeinträge, die mit Sonderzeichen beginnen sind unter "Symbole" darzustellen.
3 | Indexeintrag | - |  | I(<ie>), " ", eine oder mehrer pagerefs. | ie | pagerefs sind durch Komma zu trennen und durch 3 Leerzeichen vom Eintrag abzusetzen.
4 | Indexklasse | - |  | Überschrift: I([type]), mehrere Indexeinträge | classtitle |
Die folgenden Stylea sollen verwendet werden:
ie
Style für einen Indexeintrag im Index
Features (wenn nicht lokal anders definiert):
page-break | no new page
keep | no
space above | 3pt
space-below | 0pt
font-family | Arial
font-size | 7pt
font-slant | roman
font-weight | normal
left indent | 1cm
first indent | -1cm
alignment | left
indexletter
Style für einen Indexletter
Features (wenn nicht lokal anders definiert):
page-break | no new page
keep | with next
space above | 10pt
space-below | 0pt
font-family | Arial
font-size | 7pt
font-slant | roman
font-weight | bold
classtitle
Style für einen den Titel der Klasse des Index.
Features (wenn nicht lokal anders definiert):
break | new colum
keep | with next
space above | 10pt
space-below | 0pt
font-family | Arial
font-size | 10pt
font-slant | roman
font-weight | bold
Abbildung 14: Beispiel1 eines Indexes
Abbildung 15: Beispiel2 eines Indexes


4.10.3. Technische Begriffe

Nur zu erzeugen, wenn mindestens ein <tt> im Quelldokument enthalten ist.
Das Element <tt> hat die folgenden Attributewerte für das Attribut [type]:
  • sgml-tag
  • sgml-attribute
  • tool
  • product
  • variable
  • state
  • prm
  • material
  • control-element
  • code
  • organisation
  • other
Für jeden dieser Attributwerte ist ein eigener Index zu erzeugen. Wenn der Wert other ist, so ist zusätzlich das Attribut[user-defined-type]auszuwerten und für jeden dieser benutzerdefinierbaren Typen ein Index zu erzeugen.
Der gesamte Index ist mindestens zwei-, besser sogar drei-spaltig zu setzten. Mit Begin eines neuen <tt> [type]s sind die Spalten des darüberliegenden Indexes zu balancieren. Ist dies nicht möglich muß ein anderes Verfahren gewählt werden z.B. die neue Klasse fängt oben in einer neuen Spalte an.
Prozessierung der Technischen Begriffe
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Section (techterms) | - |  | Überschrift: "Technische Begriffe", für jeden <tt> [type] eine TTklasse | Überschrift: level2 |
4 | TTklasse | - |  | Überschrift: I([type]), mehrere TTeinträge | classtitle | Als Index ohne Indexletter zu prozessieren.
3 | Indexeintrag | - |  | I(<tt>), " ", eine oder mehrer pagerefs. | ie | pagerefs sind durch Komma zu trennen und durch 3 Leerzeichen vom Eintrag abzusetzen.


4.10.4. Applikationshinweise

Das Verzeichnis der Applikationshinweise wird ähnlich wie ein Index prozessiert. Es dient dazu, für jede Kenngröße herauszufinden, in welcher Funktion ein Applikationshinweis existiert und auf welcher Seite er vorkommt.
Daimler-Benz besitzt hier folgende Konvention:
Das Verzeichnis ist nur zu erstellen, wenn innerhalb der MSR SW Instanz mindestens eine <sw-funktion> existiert, deren <sw-application-notes> ein chapter enthält, das den folgenden <long-name>(I = "Applikationshinweise für Kenngrößen") und einen <short-name> (I = "PrmNotes") besitzt. Diese Strings müssen im Formatierer jedoch konfigurierbar sein.
Prozessierung des Applikationshinweis-Verzeichnisses
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Section | - |  | Überschrift: "Applikationshinweise", Apptable | Überschrift: level2 |
2 | Apptable | - |  | Bodyzeilen |  |
3 | Bodyzeile | <long-name> | <sw-application-notes> /<chapter> /<topic-1> | Zelle1, Zelle2 |  |
4 | Zelle1 | - |  | I(<long-name>) |  | Existieren mehrerer <sw-application-notes> /<chapter> /<topic-1> mit demselben< long-name> so ist diese Zelle vertikal nach unten zu verschmelzen.
5 | Zelle2 | <long-name> | <sw-application-notes> /<chapter> /<topic-1> | I(ancestor(<sw-function>) child(<short-name>)), pageref |  |
Abbildung 16: Beispiel des Processing des Verzeichnis Applikationshinweise


4.10.5. Literaturverweise

In dem MSR SW Dokument sollen alle im Dokument definierten Objekte vom Typ
  • Norm (<std>)
  • Externe Dokument (<xdoc>)
  • Externe Datei (<xfile>)
aufgeführt werden. Jeweils nach ihrem Typ gruppiert. Innerhalb der Gruppe sind Sie nach dem Auftreten im Dokument sortiert, wobei gleichartige Objekte zusammengefaßt werden müssen.
Bei einer Norm und einem ext. Dokument müssen dafür alle Elementinhalte bis auf <position> gleich sein. Bei einer externen Datei müssen alle Elementinhalte gleich sein.
Prozessierung der Literaturverweise
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Section | - |  | Überschrift: "Literaturverzeichnis", section (Normen), section (externe Dokumente), section (externe Dateien) | Überschrift: level2 | Diese Section wird nur erzeugt wenn mindestens eine der drei Untersectionen vorhanden ist.
2 | section (Normen) | - |  | Überschrift: "Normen", Tabelle(Norm) | Überschrift: litblock | Diese Section wird nur erzeugt wenn mindestens eine Norm vorhanden ist. Weiteres Processing siehe Tabelle Prozessierung der Norm
2 | section (externe Dokumente) | - |  | Überschrift: "Externe Dokumente", Tabelle(externe Dokumente) | Überschrift: litblock | Diese Section wird nur erzeugt wenn mindestens eine ext. Dokument vorhanden ist. Weiteres Processing siehe Tabelle Prozessierung des ext. Dokumentes
2 | section (externe Dateien) | - |  | Überschrift: "Externe Dateien", Tabelle(Externe Dateien) | Überschrift: litblock | Diese Section wird nur erzeugt wenn mindestens eine externe Datei vorhanden ist. Weiteres Processing siehe Tabelle Prozessierung der externen Datei
Prozessierung der Norm
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Tabelle (Normen)
<std>
Zeile1 bis Zeile5
Breiten:
Spalte1: 2*
Spalte2: 8*
Spalte3: 1*
Keine Ränder und erste Spalte mit grauem Hintergrund
2
Zeile1
<long-name-1>
Zelle1: "Bezeichnung"
Zelle 2: I(<long-name>), "[", I(<short-name>), "], ", I(<subtitle>)
Zelle 3: "Seite"
Alle Strings in Fixtextlibary
Der <long-name>, <short-name>, und der <subtitle> werden unterschiedlich formatiert.
3
Zeile2
<state-1>
Zelle1: "Status"
Zelle 2: I()
Zelle 3:
Alle Strings in Fixtextlibary
4
Zeile3
<date-1>
Zelle1: "Datum"
Zelle2: I()
Zelle 3:
Alle Strings in Fixtextlibary
5
Zeile4
<file>
Zelle1: "Datei"
Zelle 2: I()
Zelle 3:
Alle Strings in Fixtextlibary
6
Zeile5
for each <position>
Zelle1: "Relevante Stellen"
Zelle 2: I(<position>)
Zelle 3: pagerefs
Alle Strings in Fixtextlibary
Wird dieselbe Norm mehrmals definiert mit unterschiedlichen <position>s dann wird die erste Zelle vertikal nach unter verschmelzt.
Bei einer Norm die in identischer Form mehrmals definiert wird, sollen die Seitenzahlen hintereinander durch Kommas getrennt aufgelistet werden.
Prozessierung des ext. Dokumentes
Nr.
Präsent. - Objekt
Hook
Context
Inhalt / Query
Layout / Style
Besonderheiten
1
Tabelle (externes Dokumente)
<xdoc>
Zeile1 bis Zeile6
Breiten:
Spalte1: 2*
Spalte2: 8*
Spalte3: 1*
Keine Ränder und erste Spalte mit grauem Hintergrund
2
Zeile1
<long-name-1>
Zelle1: "Bezeichnung"
Zelle 2: I(<long-name>), "[", I(<short-name>), "], ", I(<number>)
Zelle 3: "Seite"
Alle Strings in Fixtextlibary
Der <long-name>, <short-name>, und der <number> werden unterschiedlich formatiert.
3
Zeile2
<state-1>
Zelle1: "Status"
Zelle 2: I()
Zelle 3:
Alle Strings in Fixtextlibary
4
Zeile3
<date-1>
Zelle1: "Datum"
Zelle2: I()
Zelle 3:
Alle Strings in Fixtextlibary
5
Zeile4
<file>
Zelle1: "Datei"
Zelle 2: I()
Zelle 3:
Alle Strings in Fixtextlibary
6
Zeile5
<publisher>
Zelle1: "Herausgeber"
Zelle 2: I()
Zelle 3:
Alle Strings in Fixtextlibary
7
Zeile6
for each <position>
Zelle1: "Relevante Stellen"
Zelle 2: I(<position>)
Zelle 3: pagerefs
Alle Strings in Fixtextlibary
Wird dieselbe Norm mehrmals definiert mit unterschiedlichen <position>s dann wird die erste Zelle vertikal nach unter verschmelzt.
Bei einem ext. Dokument das in identischer Form mehrmals definiert wird, sollen die Seitenzahlen hintereinander durch Kommas getrennt aufgelistet werden.
Prozessierung der externen Datei
Nr. | Präsent. - Objekt | Hook | Context | Inhalt / Query | Layout / Style | Besonderheiten
1 | Tabelle (externe Dateien) | <xfile> |  | Zeile1 bis Zeile4 | Breiten: Spalte1: 2* Spalte2: 8* Spalte3: 1* | Keine Ränder und erste Spalte mit grauem Hintergrund
2 | Zeile1 | <long-name-1> |  | Zelle1: "Bezeichnung" Zelle 2: I(<long-name>), "[", I(<short-name>), "], " Zelle 3: "Seite" |  | Alle Strings in Fixtextlibary Der <long-name>, <short-name> werden unterschiedlich formatiert.
3 | Zeile2 | <file> |  | Zelle1: "Datei" Zelle2: I([filename]) Zelle 3: pagerefs |  | Alle Strings in Fixtextlibary Bei einer ext. Datei die in identischer Form mehrmals deiniert wird, sollen die Seitenzahlen hintereinander durch Kommas getrennt aufgelistet werden.
4 | Zeile3 | <file> |  | Zelle1: "Format" Zelle 2: I([notation]) Zelle 3: |  | Alle Strings in Fixtextlibary
6 | Zeile4 | <file> |  | Zelle1: "Tool / Version" Zelle 2: I([tool]), " / ", I([tool-version]) Zelle 3: |  | Alle Strings in Fixtextlibary
Abbildung 17: Beispiel des Processing eines Literaturverzeichnises


5. NCOI Elemente

MEDOC
5. NCOI Elemente

In diesem Abschnitt wird die Prozessierung der nicht-semantischen Strukturen beschrieben. Es handelt sich hier insbesondere um die folgenden
  • kapitelartigen Strukturen
    • <introduction>
    • <ncoi-1>, eine Hüllenstruktur
    • <topic-1>, ein nicht schachtelbare Kapitelstruktur
    • <chapter>, eine rekursiv schachtelbare Kapitelstruktur
  • blockartigen Strukturen:
    • <long-name> und<short-name>(aka Titel)
    • <p>, Absatz
    • <verbatim>
    • <figure>
    • <formula>
    • <list>
    • <def-list>
    • <labeled-list>
    • <note>
    • <table>, CALS-Tabelle
    • <prms>, Parameter Tabelle
  • Inline Elemente
    • <tt>, technische Begriffe unterschiedlichen Typs
    • <e>, Hervorhebungen unterschiedlichen Typs
    • <ft>, Fußnote
    • <sup>, Hochstellung
    • <sub>, Tiefstellung
    • <ie>, Indexeintrag
    • <std>, Norm
    • <xref>, Querverweis
    • <xdoc>, externes Dokument
    • <xfile>, externe Datei


5.1. Kapitelartige Strukturen

Inhalt dieses Kapitels:
  • 5.1.1. NCOI-1
  • 5.1.2. Introduction
  • 5.1.3. Chapter Kapitel Chapter
  • 5.1.4. Topic-1 Topic TOPIC


5.1.1. NCOI-1

<NCOI-1> ist ein reines Gruppierungselement, das selber keinen Einfluß auf die Präsentationsstruktur hat.


5.1.2. Introduction

<Introduction> kommt in verschiedenen Kontexten vor, die wichtigsten sind (<msr-sw>/<sw-param-contents-spec>nicht berücksichtigt):
  • <msr-sw>
  • <msr-sw>/<sw-function-spec>
  • <msr-sw>/<add-spec>
  • <msr-sw>/<sw-glossary>
Das Element <introduction> ist strukturell problematisch: In den beiden letzgenannten Kontexten können beliebige Blockelemente (<p> usw.) auf <introduction>folgen. D.h., in einer visuellen Präsentation ist es nicht entscheidbar, wo die Einleitung aufhört und der eigentliche Inhalt anfängt.


5.1.3. Chapter

<Chapter>ist rekursiv schachtelbar und kommt in verschiedenen Kontexten vor, die wichtigsten sind (ohne Vorkommen in<sw-data-dictionary>):
  • <msr-sw> /<sw-function-spec> / <sw-functions>/ <sw-function> /<sw-function-variants> / <sw-function-variant>mit den Kindern
    • <sw-function-desc>
    • <sw-test-spec>
    • <sw-application-notes>
    • <sw-maintenance-notes>
    • <sw-carb-doc>
    • <add-info>
  • <msr-sw>/<add-spec>
  • <msr-sw>/<glossary>
  • <chapter>
Die Numerierung erbt als Präfix die Numerierung des übergeordneten Kapitels. Die Formatierung der Überschriften erfolgt generell durch den Style chapter


5.1.4. Topic-1

<topic-1> ist nicht schachtelbar und kommt in verschiedenen Kontexten vor, die wichtigsten sind (ohne Vorkommen in<sw-data-dictionary>):
  • <msr-sw> /<sw-function-spec> / <sw-functions>/ <sw-function> /<sw-function-variants> / <sw-function-variant>mit den Kindern
    • <sw-function-desc>
    • <sw-test-spec>
    • <sw-application-notes>
    • <sw-maintenance-notes>
    • <sw-carb-doc>
    • <add-info>
  • <msr-sw>/<add-spec>
  • <msr-sw>/<glossary>
  • <chapter>
Topic wird nicht numeriert. Die Formatierung der Überschriften erfolgt generell durch den Style topic


5.2. Blockartige Strukturen

Inhalt dieses Kapitels:
  • 5.2.1. Tabelle
  • 5.2.2. Abbildung
  • 5.2.3. Absatz
  • 5.2.4. Verbatim
  • 5.2.5. Formeln
  • 5.2.6. Liste
  • 5.2.7. Definitionsliste
  • 5.2.8. Bezeichnungsliste
  • 5.2.9. Anmerkung


5.2.1. Tabelle

Prozessierung als CALS Tabelle.
Der Tabellentitel soll oberhalb der Tabelle mit einem eigenen Style dargestellt werden. Der Titel besteht nur aus dem String des <long-name>s (ohne Nummerierung und ohne Fixtext "Tabelle"). Der Tabellentitel ist immer mit der Tabelle zusammenzuhalten.
Das Attribut [float] steuert die Plazierung der Tabelle auf der Seite. Das Attribut ist IMPLIED. Wenn kein Wert gesetzt ist, interpretiert die prozessierende Applikation dies als "nofloat". Wenn [float]="float" kann die Tabelle von ihrem Verankerungspunkt wegbewegt werden. Es ist Aufgabe der prozessierenden Applikation hierfür einen vernünftigen Algorithmus zur Verfügung zu stellen. Unterstützt die prozessierende Applikation diese Funktionalität nicht, ist das Attribut zu ignorieren
Das Attribut [orient] steuert die Orientierung (90° drehen oder nicht) der Tabelle. Unterstützt das prozessierende System die Rotation von Tabellen nicht, ist dieses Attribut zu ignorieren.
Nach einer Tabelle ist ausreichend (ca. 2 cm) Abstand zu den nachfolgenden Objekten zu setzen!


5.2.2. Abbildung

Der Grafiktitel soll unterhalb der Abbildung mit einem eigenen Style dargestellt werden. Der Titel besteht nur aus dem String des <long-name>s (ohne Nummerierung und ohne Fixtext "Abbildung"). Der Grafiktitel ist immer mit der Abbildung zusammenzuhalten.
Das Attribut [float] steuert die Plazierung der Abbildung auf der Seite. Das Attribut ist IMPLIED. Wenn kein Wert gesetzt ist, interpretiert die prozessierende Applikation dies als "nofloat". Wenn [float]="float" kann die Abbildung von ihrem Verankerungspunkt wegbewegt werden. Es ist Aufgabe der prozessierenden Applikation hierfür einen vernünftigen Algorithmus zur Verfügung zu stellen. Unterstützt die prozessierende Applikation diese Funktionalität nicht, ist das Attribut zu ignorieren
Das Element <figure> wird verwendet, um Abbildungen in Dokumente einzufügen. Eine Abbildung kann auf drei verschieden Arten eingefügt werden.
  1. als eine echte <graphic>
  2. als eine ASCII Grafik (<verbatim>)
  3. als eine textuelle Beschreibung (<desc>) der Grafik
Wenn mehrere Repräsentationen angegeben sind, verwendet das prozessierende System die qualitativ hochwertigste, die es darstellen kann.
Die Formatierung von Graphiken wird durch die Attribute von<graphic> festgelegt:
[category]
Legt die Kategorie der Grafik fest. Diese Information kann verwendet werden, um spezifische Abbildungslisten zu erzeugen.
[filename]
Enthält den Dateinamen, unter dem die Grafik gefunden wird. Für den Formatierer wird vorausgesetzt, diese Attribut einen relativen Pfad enthält; dieser ist relativ zur zu formatierenden Instanz zu interpretieren. Alle Grafiken müssen im Format EPS vorliegen.
Der Attributtyp kann von SDATAzuENTITY in der DTD geändert werden. Dadurch kann der entity manager der prozessierenden Applikation verwendet werden, um die Grafiken aufzufinden.
[fit]

0 | Grafik in Originalgröße. Wenn sie nicht paßt, wird sie proportional verkleinert, bis sie auf die Seite paßt.
1 | Die Grafik wird skaliert (kleiner oder größer) , um bestmöglich auf die Seite zu passen. Dieser Wert wird ignoriert, wenn[width] oder [height]zusätzlich spezifziert sind.
2 | Die Grafik wird um 90° gegen den Uhzreigersinn rotiert, wenn sie Querformat ist und breiter als die Textbreite. Ansonsten wird sie verkleinert bis sie in den Textbereich paßt. Dieser Wert wird ignoriert, wenn[width] oder [height] zusätzlich spezifziert sind.
3 | Die Grafik wird immer im Gegenuhrzeigersinn um 90° rotiert. Wenn sie nicht in den Textbereich paßt, wird sie verkleinert. Wenn [width] oder [height] zusätzlich spezifiziert sind, wird die Grafik rotiert und zusätzlich skaliert wie vorgegeben.
4 | tDie Grafik wird immer im Gegenuhrzeigersinn um 90° rotiert und vergrößert oder verkleinert, um optimal auf die Seite zu passen. Dieser Wert wird ignoriert, wenn[width] oder [height]zusätzlich spezifziert sind.
ha
[height]
Wenn dieses Attribut einen Wert erhält, wird die Grafik auf den entsprechenden Wert skaliert. Der Wert ist eine reelle Zahl mit einer Dimensionsangabe (e.g. "10cm", "150mm", "12.5in"). Wenn gleichtzeitig [width] spezifiziert ist, wird die Grafik verzerrt. Durch diesen Wert wird immer die Größe der Grafikbox auf der Seite festgelegt, nachdem die Grafik möglicherweise skaliert oder rotiert wurde.
[notation]
Legt das Grafikformat fest, kann von Applikationen verwendet werden, die Notationen unterstützen.
[scale]
Wenn dieses Attribut einen Wert erhält, wird die Grafik entsprechend dem angegebenen Faktor (reelle Zahl) skaliert. Zahlen größer 1 vergrößern die Grafik, Zahlen kleiner 1 verkleinern sie
[width]
Wenn dieses Attribut einen Wert erhält, wird die Grafik auf den entsprechenden Wert skaliert. Der Wert ist eine reelle Zahl mit einer Dimensionsangabe (e.g. "10cm", "150mm", "12.5in"). Wenn gleichtzeitig [height] spezifiziert ist, wird die Grafik verzerrt. Durch diesen Wert wird immer die Größe der Grafikbox auf der Seite festgelegt, nachdem die Grafik möglicherweise skaliert oder rotiert wurde.
Die Präzedenz der Attribute ist:
  • [scale] hat Vorrang vor allen anderen Attributen
  • [fit]hat Vorrang vor [width] und/oder[height]
Nach einer Grafik ist ausreichend (ca. 2 cm) Abstand zu den nachfolgenden Objekten zu setzen!

Z.B. für Systeme, die keine Grafiken darstellen können.


5.2.3. Absatz

Der folgende Styles soll verwendet werden:
Absatz
Style für Absätze
Features (wenn nicht lokal anders definiert):
page-break | no new page
keep | no
space above | 0pt
space-below | 3pt
font-family | Arial
font-size | 7pt
font-slant | roman
font-weight | normal
widow | 2
orphan | 2
alignment | block


5.2.4. Verbatim

<verbatim> erlaubt die Eingabe von Text mit einem monospaced Font. Tabs und Zeilenumbrüche bleiben erhalten.
Das Attribut [float] steuert die Plazierung des Verbatim-Objekts auf der Seite. Das Attribut ist IMPLIED. Wenn kein Wert gesetzt ist, interpretiert die prozessierende Applikation dies als "nofloat". Wenn [float]="float" kann das Objekt von seinme Verankerungspunkt wegbewegt werden. Es ist Aufgabe der prozessierenden Applikation hierfür einen vernünftigen Algorithmus zur Verfügung zu stellen. Unterstützt die prozessierende Applikation diese Funktionalität nicht, ist das Attribut zu ignorieren
Verbatim ist wie folgt zu formatieren:
  • Font: Courier
  • Fontgröße so, daß mind. 80 Zeichen auf die Seite passen; wenn die Zeile länger ist, darf sie nicht umbrechen sondern schreibt über den Rand oder wird abgeschnitten
  • Wenn [allow-break] nicht gleich 1, dann darf innerhalb von <verbatim> kein Seitenumbruch vorkommen.


5.2.5. Formeln

Das Element <formula> enthält einen Formeltitel (<long-name>), gefolgt von mehreren optionalen Formelrepräsentationen: <graphic>, <verbatim>, <tech-math> <c-code>, <generic-math>. Diese Repräsentationen sind nicht exklusiv, obwohl sich einige der Repräsentationsweisen aus semantischen Gründen ausschließen.
Der Formeltitel soll unterhalb der Abbildung mit einem eigenen Style dargestellt werden. Der Titel besteht nur aus dem String des <long-name>s (ohne Nummerierung und ohne Fixtext "Formel"). Der Formelltitel ist immer mit der Formel zusammenzuhalten.
Die Elemente <verbatim>, <generic-math>und<c-code>sind beide zu behandeln wie <verbatim> in 5.2.4. Verbatim, wobei allerdings das Attribut [float] von <verbatim>zu ignorieren ist.
Wenn der Formatierer in der Lage ist, <tech-math> zu formatieren, so ist diese Darstellung zu wählen, ansonsten ist <graphic> bzw. <verbatim> zu verwenden.


5.2.6. Liste

<list> ist rekursiv geschachtelt. Es gibt zwei Listentypen, festgelegt über das Attribut [type]: unnumber und number.
Wenn [type] = unnumber ist eine Bulletliste zu erzeugen.
Wenn [type] = number ist eine mit arabischen Ziffern numerierte Liste zu erzeugen. Bei rekursiv geschachtelten Listen ist die übergeordnete Numerierung nicht aufzunehmen.
Die Schachtelung ist durch Einrückung auszudrücken.


5.2.7. Definitionsliste

Definitions- und Präfixliste (<def-list> und ) können layouttechnisch ähnlich behandelt werden.
<long-name> und <short-name> innerhalb der Definitionsliste werden im Präfix abgelegt, der <short-name> in runden Klammern. Die Einrückung der Definitionsliste ist fix. Das Präfix wird fett ausgegeben.


5.2.8. Bezeichnungsliste

Die Bezeichnungslist <labeled-list> ist eine allgemeine Präfixliste. Die Einrückung und Umbruch von Präfix <item-label> und Inhalt kann präzise gesteuert werden.
Einrückung
Durch Angabe eines <indent-sample> kann angegeben werden, bis zu welchem Punkt der Listeninhalt links eingerückt wird. Wird kein <indent-sample>verwendet, wird auf die Länge des längsten <item-label>eingerückt. Es ist Aufgabe der prozessierenden Applikation, hier pathologische Situationen zu vermeiden. Wenn eine Applikation diese variablen Einrückungen nicht unterstützt, so ist eine feste Einrückung (durch Styles modifizierbar) vorzunehmen.
Umbruch
Das Element <indent-sample> kann über das Attribut [item-label-pos] das Umbruchverhalten zwischen Präfix und Inhalt steuern. Die drei Werte sind wie folgt zu interpretieren:
no-newline | nach dem Präfix wird nicht umgebrochen
newline | nach dem Präfix wird auf jeden Fall umgebrochen
newline-if-necessary | nach dem Präfix wird nur dann umgebrochen, wenn das Präfix länger als die vorgesehene Einrückung ist.


5.2.9. Anmerkung

Das Element <note> enthält einen Titel und Inhalt. Der Titel <long-name> wird abhängig vom <note> Attribut [note-type] als Fixtext vor der Note generiert:
caution | Achtung
hint | Hinweis
tip | Tip
instruction | Anweisung
exercise | Übung
other | hier ist das Attribut [user-defined-type] auszuwerten und dessen Inhalt direkt als Titel auszugeben.
Der Titel ist vor der Anmerkung auszugeben und mit dieser zusammenzuhalten. Er ist fett und mit derselben Fontgröße zu setzen wie der Anmerkungstext


5.3. Inline Elemente

Inhalt dieses Kapitels:
  • 5.3.1. Querverweise
  • 5.3.2. Technische Begriffe
  • 5.3.3. Hervorhebungen
  • 5.3.4. Fußnote
  • 5.3.5. Hoch- und Tiefstellung
  • 5.3.6. Indexeintrag
  • 5.3.7. Norm
  • 5.3.8. Externe Datei
  • 5.3.9. Externes Dokument


5.3.1. Querverweise

Inhalt dieses Kapitels:
  • 5.3.1.1. Prozessierung von dokumentübergreifenden Referenzen
  • 5.3.1.2. Prozessierung von dokumentinternen Referenzen


5.3.1.1. Prozessierung von dokumentübergreifenden Referenzen

In den MSR SW Dokumenten können Verweise auf externe Dokumente vorkommen. Zur Definition der Ziele in diesen externen Dokumenten existiert in der DTD eine Struktur <locs> mit den Unterelement <nameloc>.
Funktionsweise:
Für eine dokumentübergreifende Referenz wird mit Hilfe von ID/IDREF auf ein <nameloc> verwiesen. Der <long-name> dieses Elementes ist auszugeben. Falls in einer späteren Variante des Formatierers der long-name in seine Bestandteile zu zerlegen ist, muß der Einbau dieser Zusatzfunktionalität jetzt schon vorgesehen werden.
Es muß möglich sein den dargestellten String hervorzuheben (eigener Style).


5.3.1.2. Prozessierung von dokumentinternen Referenzen

Es gibt zwei Typen von internen Referenzen:
  • Allgemeine Referenzen (<xref>)
  • Vordefinierte Referenzen (<...-ref>)
Beide Refernztypen arbeiten mit ID/IDREF. Die allgemeinen Referenzen besitzen ein [id-class] daß die möglichen Ziele klassifiziert. Der Fixtext dieser Klassen soll konfigurierbar (Formatierparameter Referenzklassendarstellung ein oder aus) dargestellt werden.
Referenzklassen und ihre deutschen Fixtexte
Referenzklasse | Fixtext
chapter | Kapitel
company | Unternehmen
def-item | Definition
figure | Abbildung
formular | Formel
prm | Parameter
sample | Muster
std | Norm
sw-funktion | Softwarefunktion
sw-unit | Einheit
sw-physic-type | phys. Datentyp
sw-variable | Softwarevariable
sw.param | Kenngröße
sw-compu-method | Umrechnungsformel
sw-addressing-method | Adressierschema
sw-param-record-layout | Ablageschema
sw-code-syntax | Code Syntax
table | Tabelle
team-member | Mitarbeiter
topic | Thema
variant-char | Variantenmerkmal
variant-def | Variante
xdoc | ext. Dokument
xfile | ext. Datei
Die Referenzklasse "external" hat eine spezielle Bedeutung. Sie definiert, daß es sich hierbei um eine externe Referenz (siehe Kapitel 5.3.1.1. Prozessierung von dokumentübergreifenden Referenzen) handelt.
Allgemeine Referenzen sind wie folgt aufzulösen:
  • Wenn der Formatiererparameter Siehe auf "ja" gesetzt ist, wird der Fixtext: "siehe " erzeugt. Ansonsten entfällt er.
  • Wenn der Formatiererparameter Referenzklassendarstellung auf "ja" gesetzt ist, wird der Fixtext der entsprechenden Refernzklasse erzeugt. Ansonsten entfällt er.
  • <long-name> des Verweisziels
  • <short-name> des Verweisziels in "[" und "]"
  • Seitenangabe wir folgt: "S. " Seitenzahl
Die einzelnen Objekte sollen unabhänig voneinander formatierbar sein (z.B. <long-name> fett und <short-name>kursiv).
Vordefinierte Referenzen besitzen keine allgemeine Prozessierung. Sie werden je nach Kontext spezifisch behandelt und im entsprechenden Kapitel dieses Dokumentes spezifiziert.


5.3.2. Technische Begriffe

Das Element ist <tt> ist monospaced (Courier) in Fontgröße und Stil des umgebenden Textes zu setzen. Abhängig von einzelnen Werten seines Attributes [type] kann es mit spezifischen Präfixen und/oder Suffixen versehen werden. Für den aktuellen Formatierer führen nur die beiden folgenden Werten zu Prä- und Suffixen:
sgmltag | Präfix: "<", Suffix: ">"
sgml-attribute | Präfix: "[", Suffix: "]"


5.3.3. Hervorhebungen

Das Element ist <e> in Fonttyp, Fontgröße und Stil des umgebenden Textes zu setzen. Abhängig von den Werten seines Attributes [type] wird sein Inhalt fett oder kursiv gesetzt. Ist es z.B. aufgrund seiner Umgebung schon kursiv und [type]=bold, so wird sein Inhalt fett und kursiv. Ist es aufgrund seiner Umgebung kursiv und [type]=italic, so ergibt sich keine Änderung.
bold | fett
italic | kursiv


5.3.4. Fußnote

Fußnoten (<ft>) sind unten auf der Seite zu setzen. Sie sind durch eine Linie abzutrennen und dokumentweise durchzunumerieren.


5.3.5. Hoch- und Tiefstellung

Hoch- und Tiefstellungen (<sup> und <sub>) sind entsprechend zu formatieren. Sie sind proportional zu verkleinern.


5.3.6. Indexeintrag

Indexeinträge <ie>sind aus dem gesetzten Text zu entfernen.


5.3.7. Norm

Normen <std>sind wie folgt zu prozessieren:
Die gesamte Norm ist kursiv zu setzen, die einzelnen Komponenten durch " / " (Leerzeichen, Slash, Leerzeichen) abzutrennen. <std> selbst und einige der Kinder erzeugen Präfixe:
<std> | "Norm: "
<state-1> | "Status: "
<date-1> | "Datum: "
<file> | "Datei: "
<position> | "relevante Stelle: "
Jedes Kindelement sollte mit einem Style versehen werden (genauso wie das Mutterelement, damit Anpassungen einfach vorgenommen werden können.


5.3.8. Externe Datei

Externe Dateien <xfile> sind wie folgt zu prozessieren:
Das gesamte Element ist kursiv zu setzen, die einzelnen Komponenten durch " / " (Leerzeichen, Slash, Leerzeichen) abzutrennen. <xfile> selbst und einige der Kinder erzeugen Präfixe:
<xfile> | "Externe Datei: "
<file> | "Datei: "
Jedes Kindelement sollte mit einem Style versehen werden (genauso wie das Mutterelement, damit Anpassungen einfach vorgenommen werden können.


5.3.9. Externes Dokument

Externe Dokumente <xdoc> sind wie folgt zu prozessieren:
Das gesamte Element ist kursiv zu setzen, die einzelnen Komponenten durch " / " (Leerzeichen, Slash, Leerzeichen) abzutrennen. <xdoc> selbst und einige der Kinder erzeugen Präfixe:
<xdoc> | "Externes Dokument: "
<number> | "Nummer: "
<state-1> | "Status: "
<date-1> | "Datum: "
<publisher> | "Herausgeber: "
<file> | "Datei: "
<position> | "relevante Stelle: "
Jedes Kindelement sollte mit einem Style versehen werden (genauso wie das Mutterelement, damit Anpassungen einfach vorgenommen werden können.


6. Layout

MEDOC
6. Layout

Inhalt dieses Kapitels:
  • 6.1. Allgemeines
  • 6.2. Styles für die Kapitelstruktur


6.1. Allgemeines

Inhalt dieses Kapitels:
  • 6.1.1. Verrechnung von vertikalen Abständen


6.1.1. Verrechnung von vertikalen Abständen

Wenn zwei Blöcke aufeinander treffen von denen der erste einen Space after und der zweite einen Space before hat, so soll als der Gesamtabstand beider Blöcke der jeweils größere Abstand verwendet werden. Die Abstände werden nicht addiert!
In Bestimmten Ausnahmefällen wird der kleinerer Abstand beider Blöcke verwendet. Zum Beispiel bei der Direktfolge von zwei Kapitelüberschriften.


6.2. Styles für die Kapitelstruktur

Verschiedene Styles kodieren teilweise dieselben Formateigenschaften. Die Differenzierung über die Stylenamen erfolgt, um auf einfache Weise die Dokumenthierarchie stärker zum Ausdruck bringen zu können, falls dies gewünscht wird.
Für das vorliegende Dokument wurde eine visuell flache Hierarchie definiert: Die Ebenen 1 bis 3 sind vom Layout identisch, die Hierarchiestufe wird durch die Numerierung ausgedrückt. Die Ebenen innerhalb der Funktion sind ebenfalls alle vom Layout identisch, die Hierarchiestufe wird ebenfalls durch die Numerierung ausgedrückt.
Die folgenden Styles werden verwendet:
level1
Style für Überschriften erster Ebene.
Features (wenn nicht lokal anders definiert):
page-break | new right page
keep | keep with next
space above | 0pt
space-below | 3pt
font-family | Arial
font-size | 12pt
font-slant | roman
font-weight | bold
level2
Style für Überschriften zweiter Ebene (z.B. Hauptgruppen innerhalb der Funktion)
Features (wenn nicht lokal anders definiert):
page-break | new page (außer wenn first child in übergeordnetem Kapitel)
keep | keep with next
space above | 0pt
space-below | 3pt
font-family | Arial
font-size | 12 pt
font-slant | roman
font-weight | bold
level3
Style für Überschriften dritter Ebene (z.B. Untergruppen innerhalb der Funktion)
Features (wenn nicht lokal anders definiert):
page-break | new page (außer wenn first child in übergeordnetem Kapitel)
keep | keep with next
space above | 0pt
space-below | 3pt
font-family | Arial
font-size | 12 pt
font-slant | roman
font-weight | bold
function
Style für die Überschrift einer Funktion
Features (wenn nicht lokal anders definiert):
page-break | new page (außer erste Funktion innerhalb von übergeordnetem Kapitel)
keep | keep with next
space above | 10pt
space-below | 3pt
font-family | Arial
font-size | 10 pt
font-slant | roman
font-weight | bold
litblock
Style für einen Block im Literaturverzeichnis
Features (wenn nicht lokal anders definiert):
break | none
keep | keep with next
space above | 10pt
space-below | 3pt
font-family | Arial
font-size | 10 pt
font-slant | roman
font-weight | bold
chapter
Style für Überschriften von Kapiteln (semantische Kapitel in Funktionen oder strukturelle Kapitel<chapter>
Features (wenn nicht lokal anders definiert):
page-break | none
keep | keep with next
space above | 8pt
space-below | 3pt
font-family | Arial
font-size | 8 pt
font-slant | roman
font-weight | bold
topic
Style für Überschriften von Topics
Features (wenn nicht lokal anders definiert):
page-break | none
keep | keep with next
space above | 8pt
space-below | 3pt
font-family | Arial
font-size | 8 pt
font-slant | roman
font-weight | bold
Ein MSRSW Dokument hat die folgende prototypische Kapitelstruktur (die zur Formatierung der Überschriften verwendeten styles sind in Klammern angegeben):
  • 1. Verzeichnis der Funktionen (Style level1)
  • 2. Verwendung der Kenngrößen und Softwarevariablen (Style level1)
  • 3. Verzeichnis der Funktionen (Style level1)
  • 4. Einleitung (Style level1)
  • 5. Funktionsbeschreibungen (Style level1)
  • 5.1 Funktion auf oberster Ebene (Style function)
  • 5.2 Hauptgruppe erste Ebene (Style level2)
  • 5.2.1 Funktion innerhalb der ersten Hauptgruppe (Stylefunction)
  • 1 Semantisches oder strukturelles Kapitel in Funktion (z.B. für<sw-function-def>, <sw-function-desc>,<sw-function-fulfils>, etc. (Style chapter)
  • 1.1 Unterkapitel in Funktion (Style chapter)
  • Topic (Style topic)
  • 1.1.1 Unterkapitel in Unterkapitel in Funktion (Style chapter)
  • 1.1.1.1 Unterkapitel in Unterkapitel in Unterkapitel in Funktion (Style chapter)
  • usw.
  • 5.2.2 Hauptgruppe zweite Ebene (Style level3)
  • 5.2.2.1 Funktion innerhalb der zweiten Hauptgruppe (Style function)
  • 6. Weitere Spezifikationen (Style level1)
  • Einleitung (Style topic)
  • Topic (Style topic)
  • 6.1 Kapitel (Style chapter)
  • 6.2 Kapiteltitel (Style chapter)
  • Anhänge (Style level1)
  • A Glossar (Style level2)
  • B Index (Style level2)
  • C Technische Begriffe (Style level2)
  • C.1 SGML-Elemente (Style chapter)
  • C.2 SGML-Attribute (Style chapter)
  • C.... usw. (Style chapter)
  • D Applikationshinweise (Style level2)
  • E Literaturverzeichnis (Style level2)
  • E.1 Externe Dokumente (Style chapter)
  • E.2 Normen (Style chapter)
  • E.3 Externe Dateien (Style chapter)


Technische Begriffe

MEDOC
Technische Begriffe


Organisationen

Daimler-Benz


Parameter

msr-doc-only-1 | 4.7.
msr-doc-only-2 | 4.7.


Programmcode

ENTITY | 5.2.2.
other | 4.10.3.
SDATA | 5.2.2.


SGML Attribute

allow-break | 5.2.4.
category | 5.2.2.
filename | 4.10.5. 5.2.2.
fit | 5.2.2.
float | 5.2.1. 5.2.2. 5.2.4. 5.2.5.
height | 5.2.2.
id | 4.5.
id-class | 5.3.1.2.
item-label-pos | 5.2.8.
notation | 4.10.5. 5.2.2.
note-type | 5.2.9.
orient | 5.2.1.
owns | 4.5.
scale | 5.2.2.
sw-param | 4.5.
sw-variable | 4.5.
tool | 4.10.5.
tool-version | 4.10.5.
Type | 3.1.1. 4.1.
user-defined-type | 4.10.3. 5.2.9.
width | 5.2.2.


SGML Elemente

long-name | 4.10.4.
team-member | 3.1.1.
...-ref | 5.3.1.2.
add-info | 4.4. 4.8. 5.1.3. 5.1.4.
add-spec | 2.1. 2.2. 4.9. 5.1.2. 5.1.3. 5.1.4.
address | 4.2.
admin-data | 2.1. 2.2. 3.1.1. 3.1.2. 4.1. 4.4. 4.7.
adress | 4.2.
annotations | 4.4. 4.8.
anotation | 4.8.
anotation-origin | 4.8.
anotation-text | 4.8.
anotations | 4.8.
c-code | 5.2.5.
chapter | 3.3. 4.4. 4.8.2. 4.10.4. 5. 5.1.3. 5.1.4. 6.2.
chapters | 4.8.2.
city | 4.2.
comany | 1.2.
companies | 2.1. 4.2.
company | 1.2. 4.2.
company-doc-info | 3.1.1. 3.1.2. 4.1.
company-doc-infos | 3.1.1. 3.1.2. 4.1.
company-ref | 3.1.1. 3.1.2.
company-revision-info | 3.1.1. 4.1. 4.4. 4.7.
company-revision-infos | 3.1.1. 4.1. 4.4. 4.7.
date-1 | 4.10.5. 5.3.7. 5.3.9.
def-list | 5. 5.2.7.
department | 1.2. 4.2.
desc | 5.2.2.
doc-revision | 3.1.1. 4.1. 4.4. 4.7.
doc-revisions | 3.1.1. 4.1. 4.4. 4.7.
e | 5. 5.3.3.
email | 4.2.
fax | 4.2.
figure | 5. 5.2.2.
file | 4.10.5. 5.3.7. 5.3.8. 5.3.9.
formula | 5. 5.2.5.
ft | 5. 5.3.4.
function | 4.1.
function-ref | 4.8.
generic-math | 5.2.5.
glossary | 5.1.3. 5.1.4.
graphic | 5.2.2. 5.2.5.
homepage | 4.2.
ie | 2.1. 2.2. 4.10. 4.10.2. 5. 5.3.6.
indent-sample | 5.2.8.
introduction | 2.1. 2.2. 4.6. 4.7. 5. 5.1.2.
item-label | 5.2.8.
label | 4.1. 4.8.
labeled-list | 5. 5.2.8.
list | 5. 5.2.6.
locs | 5.3.1.1.
long-name | 1.2. 3.1.1. 3.3. 4.1. 4.2. 4.4. 4.7. 4.8.2. 4.10.4. 4.10.5. 5. 5.2.1. 5.2.2. 5.2.5. 5.2.7. 5.2.9. 5.3.1.1. 5.3.1.2.
long-name-1 | 4.10.5.
msr-sw | 4.4. 4.6. 5.1.2. 5.1.3. 5.1.4.
msrsw | 2.1. 2.2. 4.6.
nameloc | 5.3.1.1.
NCOI | 4.9.
ncoi-1 | 5.
note | 5. 5.2.9.
number | 4.10.5. 5.3.9.
overall-project | 4.1.
p | 4.8.2. 5. 5.1.2.
phone | 3.1.1. 4.2.
position | 4.10.5. 5.3.7. 5.3.9.
private-code | 3.1.1. 4.1.
private-codes | 3.1.1. 4.1.
prms | 5.
project | 2.1. 4.1. 4.2.
project-data | 2.1. 2.2. 4.1. 4.2.
publisher | 4.10.5. 5.3.9.
revision-label | 4.1. 4.4. 4.7.
revsion-label | 3.1.1.
role | 1.2. 4.2.
roles | 1.2. 4.2.
short-name | 3.1.1. 4.1. 4.4. 4.5. 4.6. 4.7. 4.8.2. 4.10.4. 4.10.5. 5. 5.2.7. 5.3.1.2.
state | 3.1.1.
state-1 | 4.10.5. 5.3.7. 5.3.9.
std | 2.1. 2.2. 4.10.5. 5. 5.3.7.
sub | 5. 5.3.5.
subtitle | 4.10.5.
sup | 5. 5.3.5.
sw-application-notes | 4.4. 4.8. 4.8.2. 4.10.4. 5.1.3. 5.1.4.
sw-carb-doc | 4.4. 4.8. 5.1.3. 5.1.4.
sw-data-dictionary | 4.8. 5.1.3. 5.1.4.
sw-data-dictionary-spec | 2.1. 2.2. 4.4.
sw-datadictionary | 4.5.
sw-decomposition | 4.4. 4.8.
sw-fulfils | 4.4. 4.8.
sw-functio | 4.7.
sw-function | 1.6. 3.1.1. 3.1.2. 4.1. 4.4. 4.5. 4.7. 4.10.4. 5.1.3. 5.1.4.
sw-function-class | 4.7.
sw-function-def | 4.4. 4.8. 6.2.
sw-function-desc | 4.4. 4.8. 5.1.3. 5.1.4. 6.2.
sw-function-export-variables | 4.5.
sw-function-fulfils | 6.2.
sw-function-import-variables | 4.5.
sw-function-local-variables | 4.5.
sw-function-modelonly-variables | 4.5.
sw-function-ref | 4.6. 4.8.
sw-function-refs | 2.1. 2.2. 4.6.
sw-function-spec | 2.1. 2.2. 4.1. 4.4. 4.7. 5.1.2. 5.1.3. 5.1.4.
sw-function-variables | 4.4. 4.5.
sw-function-variant | 4.7. 4.8. 5.1.3. 5.1.4.
sw-function-variants | 4.7. 5.1.3. 5.1.4.
sw-functions | 4.1. 4.4. 4.7. 5.1.3. 5.1.4.
sw-funktion | 4.10.4.
sw-glossary | 4.10. 5.1.2.
sw-maintanance-note | 4.8.
sw-maintenance-notes | 4.4. 5.1.3. 5.1.4.
sw-param | 4.5.
sw-param-content-spec | 4.4.
sw-param-contents-spec | 2.1. 2.2. 5.1.2.
sw-param-ref | 4.5.
sw-param-refs | 4.4. 4.5.
sw-test-spec | 4.4. 4.8. 4.8.1. 5.1.3. 5.1.4.
sw-variable | 4.5.
sw-variable-ref | 4.5.
sw-variables-ref | 4.5.
table | 3.3. 5.
team-member | 1.2. 3.1.1. 4.2.
team-member-ref | 3.1.1.
team-members | 1.2. 4.2.
tech-math | 5.2.5.
topic | 4.8.2.
topic-1 | 4.10.4. 5. 5.1.4.
tt | 2.1. 2.2. 4.10.3. 5. 5.3.2.
verbatim | 5. 5.2.2. 5.2.4. 5.2.5.
xdoc | 2.1. 2.2. 4.10.5. 5. 5.3.9.
xfile | 2.1. 2.2. 4.10.5. 5. 5.3.8.
xref | 5. 5.3.1.2.
zip | 4.2.


Sonstige

 | 4.10.4.
chapter | 4.8. 5.1.3. 6.2.
classtitle | 4.10.2. 4.10.3.
function | 4.7. 6.2.
ie | 4.10.2. 4.10.3.
indexletter | 4.10.2.
level1 | 4.10. 6.2.
level2 | 4.10. 4.10.2. 4.10.3. 4.10.4. 4.10.5. 6.2.
level3 | 6.2.
litblock | 4.10.5.
section1 | 4.4. 4.6. 4.7. 4.9.
section2 | 4.2. 4.3. 4.5. 4.7.
section3 | 4.7.
topic |


Variablen

Section-body | 4.7.
Absatz | 4.2. 4.8.
Apptable | 4.10.4.
berschrift | 4.3.
Bodyzeile | 1.2. 4.2. 4.3. 4.4. 4.5. 4.8. 4.10.4.
Bodyzeilen | 4.8. 4.10.4.
book | 2.1. 2.2.
Item | 4.6. 4.8.
Kopfzeile | 1.2. 4.2. 4.4. 4.5. 4.8.
Liste | 4.6. 4.8.
Liste | 4.8.
Liste | 4.8.
nav | 2.1.
navigator | 2.1.
navigator | 2.1.
navigator (list of functions) | 2.1.
navigator (list of cross references) | 2.1.
navigator (toc) | 2.1.
Referenzklassendarstellung | 5.3.1.2.
section | 2.1. 2.2.
section (Funktionsbeschreibung) | 2.2.
section (Funktionsbeschreibungen) | 2.1.
Section | 4.8.
section (Anhänge) | 2.1. 2.2.
section (externe Dateien) | 4.10.5.
section (externe Dokumente) | 4.10.5.
section (externe Dateien) | 4.10.5.
section (externe Dokumente) | 4.10.5.
section (introduction, sw-function-refs) | 2.1.
section (Normen) | 4.10.5.
section (project-members) | 2.1.
section (Weitere Spezifikationen) | 2.1. 2.2.
section(introduction, sw-function-refs) | 2.2.
Section-body | 4.7. 4.8.
Siehe | 5.3.1.2.
Tabelle | 4.2. 4.3. 4.4. 4.5. 4.8.
Tabelle (Normen) | 4.10.5.
titlepage | 2.1. 2.2.
Topic | 4.5. 4.6. 4.9.
Überschrift | 4.2. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.10.2. 4.10.3. 4.10.4. 4.10.5.
Zeile1 | 4.10.5.
Zeile2 | 4.10.5.
Zeile3 | 4.10.5.
Zeile4 | 4.10.5.
Zeile5 | 4.10.5.
Zeile6 | 4.10.5.
Zelle | 4.2. 4.3. 4.4. 4.5. 4.8. 4.10.5.
Zelle1 | 4.2. 4.10.4.
Zelle2 | 4.2. 4.10.4.
Zelle3 | 4.2.
Zelle4 | 4.2. 4.4.
Zelle5 | 4.2.


Untitled

Sind mehrere Varianten vorhanden, so ist dies im Protokoll zu vermerken


Untitled

Makrostruktur inkl. des Verzeichnis der Funktionen


Untitled

Wenn die Hierarchie des zu prozessierenden Dokumentes nicht sinnvoll ist, so ist dies im Protokoll zu vermerken


Untitled

Z.B. für Systeme, die keine Grafiken darstellen können.


Untitled

Sollten doch mehrere Varianten vorkommen, ist die erste zu prozessieren. Die Tatsache, daß mehrere vorkommen ist im Protokoll festzuhalten.