Dieser Anhang führt die DTDs (Document Type Definitions, Dokumenttypdefinitionen) für CRNP (Cluster Reconfiguration Notification Protocol) auf.
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-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-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)>
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 >