DTD de XML SC_CALLBACK_REG

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.

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. Asimismo, 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 NVPAIR.
—>

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