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
>