Anhang F Dokumenttypdefinitionen für CRNP

Dieser Anhang führt die DTDs (Document Type Definitions, Dokumenttypdefinitionen) für CRNP (Cluster Reconfiguration Notification Protocol) auf.

SC_CALLBACK_REG XML DTD

Die NVPAIR-Datenstruktur, die sowohl von SC_CALLBACK_REG als auch von SC_EVENT verwendet wird, wird nur einmal definiert.

<!— SC_CALLBACK_REG-XML-Formatspezifikation
        Copyright 2001-2003 Sun Microsystems, Inc. Alle Rechte vorbehalten.
        Die Nutzung unterliegt den Lizenzvereinbarungen.

        Vorgesehener Verwendungszweck:

Ein Client des Cluster Reconfiguration Notification Protocol muss dieses XML-Format
verwenden, um sich zu Beginn beim Dienst zu registrieren. Daneben dient es zur anschließenden
Registrierung für weitere Ereignisse, zur Deregistrierung für einige Ereignisse oder zur
vollständigen Entfernung aus dem Dienst.

Ein Client wird eindeutig durch sein Rückmelde-IP und den Port identifiziert. Der Port ist
im Element SC_CALLBACK_REG definiert, und das IP wird als Quell-IP für die
Registrierungsverbindung verwendet.
Das letzte Attribut für das Root-Element SC_CALLBACK_REG ist entweder
ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT oder REMOVE_EVENTS, je nach der vom Client
verwendeten Meldungsform.

SC_CALLBACK_REG enthält 0 oder mehr SC_EVENT_REG-Unterelemente.

Ein SC_EVENT_REG ist die Spezifikation für einen Ereignistyp. Ein Client kann entweder nur die
CLASS (ein Attribut des Elements SC_EVENT_REG) oder zusätzlich eine SUBCLASS (ein optionales
Attribut) definieren, um weiter zu verfeinern. Außerdem hat SC_EVENT_REG als Unterelemente
0 oder mehr NVPAIRs, mit denen die Spezifikation des Ereignisses noch detaillierter angegeben
werden kann.

Der Client kann also die Angaben für die Ereignisse beliebig stark verfeinern. Beachten Sie,
dass sich ein Client nicht in derselben Meldung für Ereignisse registrieren und deregistrieren
kann. Er kann jedoch in einer einzigen Meldung den Dienst und Ereignisse abonnieren.

Hinweis zu Versionen: Das VERSION-Attribut für jedes Root-Element ist als "fixed" markiert. Das
bedeutet, dass für jede Meldung, die auf diesen DTDs basiert, der Versionswert angegeben sein
muss. Wenn eine neue Version des Protokolls erstellt wird, enthalten die überarbeiteten DTDs einen
neuen Wert für dieses "fixed" VERSION-Attribut. Daher müssen alle Meldungen, die auf der neuen
Version basieren, die neue Versionsnummer enthalten.
—>

<!— SC_CALLBACK_REG - Definition

Das Root-Element des XML-Dokuments ist eine Registrierungsmeldung. Eine Registrierungsmeldung
besteht aus dem Rückmelde-Port und der Protokollversion als Attributen, sowie aus einem
der Attribute ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT oder REMOVE_EVENTS, die den
Registrierungstyp angeben. Die Typen ADD_CLIENT, ADD_EVENTS und REMOVE_EVENTS müssen
ein oder mehrere SC_EVENT_REG-Unterelemente enthalten. REMOVE_CLIENT darf kein
SC_EVENT_REG-Unterelement angeben.
        ATTRIBUTES:
               VERSION        Die CRNP-Protokollversion der Meldung.
               PORT           Der Rückmelde-Port.
               REG_TYPE       Der Registrierungstyp. Folgende sind möglich:
                       ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT, REMOVE_EVENTS

        CONTENTS:
SUBELEMENTS: SC_EVENT_REG (0 oder mehr)
—>
<!ELEMENT SC_CALLBACK_REG (SC_EVENT_REG*)>
<!ATTLIST SC_CALLBACK_REG
       VERSION        NMTOKEN                                                #FIXED
       PORT           NMTOKEN                                                #REQUIRED
       REG_TYPE       (ADD_CLIENT|ADD_EVENTS|REMOVE_CLIENT|REMOVE_EVENTS)    #REQUIRED

>
<!— SC_EVENT_REG - Definition

SC_EVENT_REG definiert ein Ereignis, für das der Client Interesse am Erhalt von
Ereignisbenachrichtigungen registriert bzw. deregistriert. Die Registrierung kann auf
einer beliebigen Verfeinerungsebene erfolgen, angefangen bei lediglich der Ereignisklasse
bis zur Angabe von spezifischen Namens-/Wertepaaren, die vorhanden sein müssen. Das
einzige erforderliche Attribut ist also CLASS. Das  SUBCLASS-Attribut sowie die NVPAIRS-
Unterelemente sind optional für eine stärkere Verfeinerung.

Registrierungen, die Namens-/Wertepaare angeben, registrieren Interesse an
Benachrichtigungen über Meldungen von der angegebenen Klasse/Unterklasse,
bei der ALLE Namens-/Wertepaare vorhanden sind. Deregistrierungen, die Namens-
/Wertepaare angeben, deregistrieren das Interesse an Benachrichtigungen, die zuvor
GENAU diese Namens-/Wertepaare auf der Verfeinerungsebene angegeben haben.
Deregistrierungen, die keine Namens-/Wertepaare angeben, deregistrieren das Interesse an
Benachrichtigungen über ALLE Ereignisse der angegebenen Klasse/Unterklasse.

        ATTRIBUTES:
               CLASS:        Die Ereignisklasse, für die dieses Element
                             Interesse registriert bzw. deregistriert.
               SUBCLASS:     Die Unterklasse des Ereignisses (optional).

        CONTENTS:
               SUBELEMENTS: 0 oder mehr NVPAIRs.
—>

<!ELEMENT SC_EVENT_REG (NVPAIR*)>
<!ATTLIST SC_EVENT_REG
       CLASS          CDATA                #REQUIRED
       SUBCLASS       CDATA                #IMPLIED
>

NVPAIR-XML-DTD

<!— NVPAIR-XML-Formatspezifikation

        Copyright 2001-2003 Sun Microsystems, Inc. Alle Rechte vorbehalten.
        Die Nutzung unterliegt den Lizenzbedingungen.

        Vorgesehener Verwendungszweck:
              Ein nvpair-Element dient der Verwendung in einem SC_EVENT- oder SC_CALLBACK_REG-
              Element.
—>

<!— NVPAIR - Definition

       NVPAIR ist ein Namens-/Wertepaar, das beliebige Namens-/Wertekombinationen darstellt.
       Es soll eine direkte, generische Übertragung der Solaris-nvpair_t-Struktur sein, die im
       Rahmen von sysevent verwendet wird. Es ist jedoch in diesem XML-Element keine
       Typinformation mit dem Namen bzw. dem Wert verhanden; beide bestehen aus beliebigem Text.

       NVPAIR besteht einfach aus einem NAME-Element und einem oder mehreren
       VALUE-Elementen. Ein VALUE-Element stellt einen Skalarwert dar, während
       mehrere einen Array-Wert darstellen.

       ATTRIBUTES:

       CONTENTS:
               SUBELEMENTS: NAME(1), VALUE(1 oder mehr)
—>

<!ELEMENT NVPAIR (NAME,VALUE+)>
<!— NAME - Definition

        NAME ist lediglich eine beliebig lange Zeichenkette.

        ATTRIBUTES:

        CONTENTS:
                Beliebige Textdaten. Sie müssen in <![CDATA[...]]> stehen, um
                XML-Analyse darin zu vermeiden.
—>
<!ELEMENT NAME (#PCDATA)>

<!— VALUE - Definition
        VALUE ist einfach eine beliebig lange Zeichenkette.

        ATTRIBUTES:

        CONTENTS:
                Beliebige Textdaten. Sie müssen in <![CDATA[...]]> stehen,
                um XML-Analyse darin zu vermeiden.
—>

<!ELEMENT VALUE (#PCDATA)>

SC_REPLY-XML-DTD

<!— SC_REPLY-XML-Formatspezifikation

        Copyright 2001-2003 Sun Microsystems, Inc. Alle Rechte vorbehalten.
        Die Nutzung unterliegt den Lizenzvereinbarungen.
—>

<!— SC_REPLY-Definition

        Das Root-Element des XML-Dokuments stellt eine Antwort auf eine
        Meldung dar. Die Antwort enthält einen Statuscode und eine Statusmeldung.

        ATTRIBUTES:
                VERSION:        Die CRNP-Protokollversion der Meldung.
                STATUS_CODE:    Der Rückgabecode für die Meldung. Folgende sind möglich:
                             OK, RETRY, LOW_RESOURCES, SYSTEM_ERROR, FAIL,
                                MALFORMED, INVALID_XML, VERSION_TOO_HIGH oder
                                VERSION_TOO_LOW.

                CONTENTS:
                        SUBELEMENTS: SC_STATUS_MSG(1)
—>

<!ELEMENT SC_REPLY (SC_STATUS_MSG)>
<!ATTLIST SC_REPLY
        VERSION        NMTOKEN                                        #FIXED   "1.0"
        STATUS_CODE    OK|RETRY|LOW_RESOURCE|SYSTEM_ERROR|FAIL|MALFORMED|INVALID,\
                       VERSION_TOO_HIGH, VERSION_TOO_LOW) #REQUIRED
>

<!— SC_STATUS_MSG - Definition
        SC_STATUS_MSG ist einfach eine beliebige Textzeichenkette zum Erläutern des
        Statuscodes. Sie muss in <![CDATA[...]]> stehen, um XML-Analyse darin zu
        vermeiden.

        ATTRIBUTES:

        CONTENTS:
                Beliebige Zeichenkette.
—>

<!ELEMENT SC_STATUS_MSG (#PCDATA)>

SC_EVENT-XML-DTD

Die NVPAIR-Datenstruktur, die sowohl von SC_CALLBACK_REG als auch von SC_EVENT verwendet wird, wird nur einmal definiert.

<!— SC_EVENT-XML-Formatspezifikation

        Copyright 2001-2003 Sun Microsystems, Inc. Alle Rechte vorbehalten.
        Die Nutzung unterliegt den Lizenzvereinbarungen.

        Das Root-Element des XML-Dokuments ist als direkte, generische
        Übertragung des syseventd-Meldungsformats von Solaris vorgesehen.
        Es verfügt über Attribute für die Klasse, Unterklasse, Hersteller und
        Herausgeber und enthält eine beliebige Anzahl NVPAIR-Elemente.

        ATTRIBUTES:
                VERSION:        Die CRNP-Protokollversion der Meldung
                CLASS:          Die sysevent-Klasse des Ereignisses
                SUBCLASS:       Die Unterklasse des Ereignisses
                VENDOR:         Der dem Ereignis zugeordnete Hersteller
                PUBLISHER:      Der Herausgeber des Ereignisses
        CONTENTS:
                SUBELEMENTS: NVPAIR (0 oder mehr)
—>

<!ELEMENT SC_EVENT (NVPAIR*)>
<!ATTLIST SC_EVENT
        VERSION        NMTOKEN        #FIXED "1.0"
        CLASS          CDATA          #REQUIRED
        SUBCLASS       CDATA          #REQUIRED
        VENDOR         CDATA          #REQUIRED
        PUBLISHER      CDATA          #REQUIRED
>