Apéndice F Definiciones del tipo de documento para CRNP
Este apéndice enumera las DTD (definiciones de tipo de documento) para el Protocolo de notificación de reconfiguración de clúster (CRNP).
DTD de XML SC_CALLBACK_REG
Nota –
La estructura de datos NVPAIR que utilizan SC_CALLBACK_REG y SC_EVENT se define sólo una vez.
<!— especificación del formato XML de SC_CALLBACK_REG
Copyright 2001-2004 Sun Microsystems, Inc. Reservados todos los derechos.
Uso sujeto a los términos de la licencia.
Uso esperado:
Un cliente de CRNP debería utilizar este formato XML para registrarse inicialmente
en el servicio, para registrarse o eliminar su registro de algunos eventos más
adelante o para borrarse por completo del servicio.
Un cliente se identifica de forma exclusiva por su puerto e IP de rellamada. El puerto
se define en el elemento SC_CALLBACK_REG y el IP se toma como el IP de origen de la
conexión de registro. El atributo final del elemento SC_CALLBACK_REG raíz es ADD_CLIENT,
ADD_EVENTS, REMOVE_CLIENT o REMOVE_EVENTS, según la forma del mensaje que esté utilizando
el cliente.
The SC_CALLBACK_REG contiene 0 o varios subelementos SC_EVENT_REG.
Un SC_EVENT_REG es la especificación de un tipo de evento. Un cliente puede
especificar sólo CLASS (un atributo del elemento SC_EVENT_REG) o SUBCLASS (un
atributo opcional) para una mayor granularidad. AAsimismo, SC_EVENT_REG
tiene como subelementos 0 o más NVPAIRs, que se pueden utilizar para
especificar aún más el evento.
Así, el cliente puede especificar eventos en la granularidad que desee. Observe que un
cliente no se puede registrar y no registrar para eventos del mismo mensaje. Sin
embargo, un cliente puede suscribirse al servicio y suscribirse para recibir eventos
del mismo mensaje.
Nota sobre la versión: el atributo VERSION de cada elemento raíz se marca como "fijo",
lo que significa que todos los mensajes que cumplan estas DTD deben tener el valor
de versión especificado. Si se crea una nueva versión del protocolo, las DTD revisadas
tendrán un valor nuevo para este atributo de VERSION fijo, de forma que todos los mensajes
de la nueva versión deben tener el número de la nueva versión.
—>
<!— Definición de SC_CALLBACK_REG
El elemento raíz del documento XML es un mensaje de registro. Estos mensajes incluyen
el puerto de rellamada y la versión del protocolo como atributos y un atributo
ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT o REMOVE_EVENTS que especifica el tipo de registro.
Los tipos ADD_CLIENT, ADD_EVENTS y REMOVE_EVENTS deben tener uno o varios subelementos
SC_EVENT_REG. REMOVE_CLIENT no debe especificar un subelemento SC_EVENT_REG.
ATRIBUTOS:
VERSION La versión del protocolo de CRNP del mensaje.
PORT El puerto de rellamada.
REG_TYPE El tipo de registro. Uno de los siguientes:
ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT, REMOVE_EVENTS
CONTENIDO:
SUBELEMENTS: SC_EVENT_REG (0 o más)
—>
<!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
>
<!— Definición de SC_EVENT_REG
SC_EVENT_REG define un evento para el cual el cliente se está registrando o cancelando
el registro para recibir notificaciones de eventos. El registro puede ser para cualquier
nivel de granularidad, desde sólo una clase de evento hasta pares de nombre-valor
específicos que deben estar presentes. Así, el único atributo necesario es CLASS.
El atributo SUBCLASS y los subelementos NVPAIRS son opcionales, para una mayor
granularidad.
Los registros que especifican los pares de nombre-valor registran un interés en la
notificación de mensajes de la clase/subclase especificada con TODOS los pares de
nombre-valor presentes. Las cancelaciones de registro que especifican los pares de
nombre-valor anulan el registro para notificaciones que tienen PRECISAMENTE esos pares
de nombre-valor en una granularidad especificada anteriormente. Las cancelaciones de
registro que no especifican los pares nombre-valor anulan el registro de TODAS las
notificaciones de eventos de la clase y subclase especificada.
ATRIBUTOS:
CLASS: La clase de evento en la que el elemento registra
o anula el registro.
SUBCLASS: La subclase del evento (opcional).
CONTENTS:
SUBELEMENTS: 0 o más NVPAIRs.
—>
<!ELEMENT SC_EVENT_REG (NVPAIR*)>
<!ATTLIST SC_EVENT_REG
CLASS CDATA #REQUIRED
SUBCLASS CDATA #IMPLIED
>
DTD de XML de NVPAIR
<!— Especificación de formato XML de NVPAIR
Copyright 2001-2004 Sun Microsystems, Inc. Reservados todos los derechos.
El uso está sujeto a los términos de la licencia.
Uso esperado:
Un elemento nvpair se debe usar en un elemento SC_EVENT o SC_CALLBACK_REG.
—>
<!— Definición de NVPAIR
NVPAIR es un par de nombre-valor que representa combinaciones arbitrarias
de nombre y valor. Se pretende que sea una traducción directa y genérica de
la estructura nvpair_t de Solaris, empleada por la estructura sysevent.
Sin embargo, en el caso de este elemento de xml no hay información de tipo
asociada al nombre o valor (ambos son textos arbitrarios).
NVPAIR consta sólo de un elemento NAME y uno o varios elementos VALUE.
Un elemento VALUE representa un valor escalar; varios, representan un VALUE
de matriz.
ATRIBUTOS:
CONTENIDO:
SUBELEMENTS: NAME(1), VALUE(1 o varios)
—>
<!ELEMENT NVPAIR (NAME,VALUE+)>
<!— Definición de NAME
NAME es simplemente una cadena de longitud arbitraria.
ATRIBUTOS:
CONTENIDO:
Datos de texto arbitrarios. Debería estar envuelto con <![CDATA[...]]>
para evitar análisis de XML internos.
—>
<!ELEMENT NAME (#PCDATA)>
<!— Definición de VALUE
VALUE sólo es una cadena de longitud cualquiera.
ATRIBUTOS:
CONTENIDO:
Datos de texto arbitrario. Debería estar envuelto con <![CDATA[...]]>
para evitar análisis de XML internos.
—>
<!ELEMENT VALUE (#PCDATA)>
DTD de XML de SC_REPLY
<!— Especificación de formato XML de SC_REPLY
Copyright 2001-2004 Sun Microsystems, Inc. Reservados todos los derechos.
Uso sujeto a los términos de la licencia.
—>
<!— Definición de SC_REPLY
El elemento raíz del documento XML representa una respuesta a un mensaje.
La respuesta contiene un código y un mensaje de estado.
ATRIBUTOS:
VERSION: La versión de protocolo de CRNP del mensaje.
STATUS_CODE: TEl código de retorno del mensaje. Uno de los
siguientes: OK, RETRY, LOW_RESOURCES, SYSTEM_ERROR, FAIL,
MALFORMED, INVALID_XML, VERSION_TOO_HIGH, o
VERSION_TOO_LOW.
CONTENIDO:
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
>
<!— Definición de SC_STATUS_MSG
SC_STATUS_MSG es simplemente una cadena de texto arbitrario que informa sobre
el código de estado. Debería estar envuelta con <![CDATA[...]]> para evitar
un análisis de XML interno.
ATRIBUTOS:
CONTENIDO:
Cadena arbitraria.
—>
<!ELEMENT SC_STATUS_MSG (#PCDATA)>
DTD de XML de SC_EVENT
Nota –
La estructura de datos NVPAIR que utilizan SC_CALLBACK_REG y SC_EVENT se define sólo una vez.
<!— Especificación de formato XML de SC_EVENT XML
Copyright 2001-2004 Sun Microsystems, Inc. Reservados todos los derechos.
Uso sujeto a los términos de la licencia.
El elemento raíz del documento XML debe ser una traducción directa y genérica
del formato de mensaje syseventd de Solaris. Tiene atributos que representan
la clase, subclase, fabricante y editor y contiene una cantidad variable
de elementos NVPAIR.
ATRIBUTOS:
VERSION: La versión del protocolo CRNP del mensaje.
CLASS: La clase sysevent del evento
SUBCLASS: La subclase del evento
VENDOR: El fabricante asociado al evento
PUBLISHER: El editor del evento
CONTENTS:
SUBELEMENTS: NVPAIR (0 o más)
—>
<!ELEMENT SC_EVENT (NVPAIR*)>
<!ATTLIST SC_EVENT
VERSION NMTOKEN #FIXED "1.0"
CLASS CDATA #REQUIRED
SUBCLASS CDATA #REQUIRED
VENDOR CDATA #REQUIRED
PUBLISHER CDATA #REQUIRED
>
- © 2010, Oracle Corporation and/or its affiliates