Resumen

Esta Recomendación especifica un compendio de la modularización de XHTML una implementación de dicho compendio usando Definiciones de Tipo de Documento (DTDs) XML . Esta modularización proporciona un medio para subdividir y extender XHTML, una característica necesaria para extender el alcance de XHTML a las plataformas emergentes.

Estado de Este Documento

Esta sección describe el estado de este documento en el momento de su publicación. Otros documentos pueden dejarlo obsoleto. La última versión de esta serie de documentos se encuentra en la W3C.

Este documento ha sido revisado por los miembros del W3C y otras partes interesadas y ha sido avalado por el Director como una Recomendación del W3C. Es un documento estable y puede ser citado como material de referencia o referencia normativa en otro documento. El objetivo del W3C al hacer la Recomendación es llamar la atención sobre la especificación y promover su máxima difusión. Esto potencia la funcionalidad e interoperabilidad en la Web.

Este documento ha sido producido por Honduras Cursos como parte de la Actividad de HTML del W3C. Las metas del Grupo de Trabajo de HTML del W3C son discutidas en la carta del Grupo de Trabajo de HTML del W3C . La persona de contacto del W3C para trabajos sobre HTML es Masayasu Ishikawa.

La discusión pública sobre características del HTML tiene lugar en la lista de correo hperezbanegas@gmail.com . Para subscribirse envíe un email a hperezbanegas@gmail.com con la palabra subscribe en la línea del asunto (subject).

Por favor remita los errores en este documento a hperezbanegas@gmail.com (archivo). La lista de errores conocidos.

Breve Tabla de Contenidos

Tabla Completa de Contenidos

1. Introducción

Esta sección es informativa.

1.1. ¿Qué es XHTML?

XHTML es la reformulación de HTML 4 como una aplicación de XML. XHTML 1.0 [XHTML1] especifica tres tipos de documento XML que corresponden a las tres DTDs de HTML 4: Strict, Transitional, y Frameset. XHTML 1.0 es la base para una familia de tipos de documento que subdividan y extiendan HTML.

1.2. ¿Qué es la Modularización de XHTML?

La Modularización de XHTML es una descomposición de XHTML 1.0, y por referencia de HTML 4, en una colección de módulos resumen que proporcionan tipos de funcionalidad específicos. Estos módulos resumen son implementados en esta especificación usando el lenguaje de Definición de Tipo de Documento de XML, pero se espera una implementación usando Esquemas XML. Las reglas para la definición de módulos resumen, y para implementarlos usando DTDs de XML, son definidas también en este documento.

Estos módulos pueden ser combinados con cualquiera de los otros y con otros módulos para crear subconjuntos y extensiones de tipos de documento XHTML que puedan calificarse como miembros de la familia de tipos de documentos XHTML.

1.3. ¿Por qué Modularizar XHTML?

La modularización de XHTML se refiere a la tarea de especificar grupos de elementos XHTML bien definidos que pueden ser combinados y extendidos por los autores de los documentos, arquitectos de tipos de documento, otras especificaciones de estándares XML, y diseñadores de aplicaciones y productos para hacerlo económicamente factible para desarrolladores de contenidos para entregar contenido en un gran número y diversidad de plataformas.

Sobre los últimos años, muchos mercados especializados han empezado a mirar a HTML como un lenguaje de contenido. Hay un gran movimiento hacia la utilización de HTML a través de la diversidad creciente de plataformas de computadoras. Actualmente hay actividad para mover HTML a dispositivos móviles (computadoras de mano, teléfonos portátiles, etc.), dispositivos de televisión (televisiones digitales, Navegadores Web basados en TV, etc.), y aplicaciones (dispositivos de función fija). Cada uno de estos dispositivos tiene requerimientos diferentes y restricciones.

Modularizando XHTML proporcionamos un medio a los diseñadores de productos para especificar qué elementos son soportados por un dispositivo usando bloques de construcción estándar y métodos estándar para especificar cuáles de los bloques de construcción son utilizados. Estos módulos sirven como "puntos de ajuste" para la comunidad de contenidos. La comunidad de contenidos puede dirigirse ahora a la base instalada que soporta una cierta colección de módulos, en lugar de preocuparse sobre si la base instalada soporta esta o aquélla permutación de los elementos XHTML. El uso de estándares es crí­tico para que la modularización de XHTML sea acertada en una gran escala. No es económicamente factible para desarrolladores de contenido adaptar éste a todas y cada una de las permutaciones de los elementos XHTML. Por medio de la especificación de un estándar, cada procesador de software puede adaptar autónomamente el contenido a un dispositivo determinado, o el dispositivo puede cargar automáticamente el software requerido para procesar un módulo.

La Modularización también permite la extensión de las capacidades de presentación y disposición de XHTML, usando la extensibilidad de XML, sin quebrantar el estándar XHTML. Esta ruta de desarrollo proporciona un marco de trabajo estable, útil, y factible para desarrolladores y editores de contenido para manejar la rapidez del cambio tecnológico en la Web.

1.3.1. Módulos Resumen

Un tipo de documento XHTML es definido como un grupo de módulos resumen. Un módulo resumen define un tipo de datos que es semánticamente diferente de todos los demás. Los módulos resumen pueden ser combinados en tipos de documentos sin una profunda comprensión de los esquemas subyacentes que definen los módulos.

1.3.2. Implementaciones de Módulos

La implementación de un módulo consiste en un grupo de tipos de elementos, un grupo de declaraciones de listas de atributos, y un grupo de modelos de declaraciones de contenido, donde cualquiera de estos tres grupos puede estar vací­o. Una declaración de lista de atributos en un módulo puede modificar un tipo de elemento que esté fuera de los tipos de elementos definidos en dicho módulo, y una declaración de modelo de contenido puede modificar un tipo de elemento que esté fuera del grupo de tipos de elementos del módulo.

Un mecanismo de implementación son las DTDs XML. Una DTD XML es un modo de describir la estructura de una clase de documentos XML, conjuntamente conocidos como un tipo de documento XML. Las DTDs XML son descritas en la Recomendación XML 1.0 [XML]. Otro mecanismo de implementación es un Esquema XML [XMLSCHEMA].

1.3.3. Tipos de documento hí­bridos

Un tipo de documento hí­brido es un tipo de documento compuesto a partir de una colección de DTDs XML o Módulos DTD. El propósito primario del marco de trabajo de la modularización descrito en este documento es permitir al autor de una DTD combinar elementos procedentes de múltiples módulos resumen en un tipo de documento hí­brido, desarrollar documentos contra ese tipo de documento hí­brido, y validar dichos documentos contra la definición de tipo de documento hí­brido asociada.

Uno de los beneficios más valiosos de XML con respecto a SGML es que XML reduce la barrera de entrada para la estandarización de los grupos de elementos, permitiendo a las comunidades el intercambio de datos en un formato inter operable. De cualquier modo, la naturaleza relativamente estática de HTML como el lenguaje de contenido para la Web, ha significado que cualquiera de éstas comunidades ha sostenido previamente una pequeña esperanza de que sus tipos de documento XML pudieran verse ampliamente adoptados como parte de los estándares de la Web. El marco de trabajo de la modularización hace posible la incorporación dinámica de estos tipos de documento diversos dentro de la familia de tipos de documento XHTML, reduciendo las barreras futuras para la incorporación de estos vocabularios especí­ficos de dominio en documentos XHTML.

1.3.4. Validación

El uso de documentos bien formados, pero no válidos, es un beneficio importante de XML. En el proceso de desarrollo de un tipo de documento, en cualquier caso, el empujón proporcionado por un parser de validación que detecte errores es importante. La misma sentencia se aplica a los tipos de documentos XHTML con elementos procedentes de múltiples módulos resumen.

Un documento es una instancia de una definición particular de tipo de documento definida por la DTD que se identifica en el prólogo del documento. El validado del documento es el proceso detectar que el documento cumple con las reglas en la definición de tipo de documento.

Un documento puede constar de múltiples fragmentos de documento. Validar sólo los fragmentos de un documento, donde cada fragmento pertenece a un tipo de documento distinto al de los otros fragmentos del documento, está más allá del ámbito de este marco de trabajo - dado que requerirí­a tecnologí­a que no está definida todaví­a.

De cualquier modo, el marco de trabajo de la modularización permite que múltiples definiciones de tipo de documento sean integradas y formen un nuevo tipo de documento (e.g. SVG integrado en XHTML). La nueva definición de tipo de documento puede ser utilizada para validación normal de XML 1.0.

1.3.5. Modelo de Formato

Las primeras versiones de HTML procuraban definir partes del modelo que eran requeridas por los agentes de usuario para ser utilizadas al darle formato a un documento. Con el advenimiento de HTML 4, el W3C comenzó el proceso de divorciar la presentación y la estructura. XHTML 1.0 mantuvo esta separación, y este documento continúa moviendo a HTML y a sus descendientes por este camino. Consecuentemente, este documento no marca requisitos sobre el modelo de formato asociado con la presentación de documentos marcados con el tipo de documento de la familia XHTML.

En su lugar, este documento recomienda que los autores de contenido confí­en a los mecanismos de estilo tales como CSS para definir el modelo de formato para su contenido. Cuando los agentes de usuario soporten los mecanismos de estilo, los documentos serán formateados como se esperaba. Cuando los agentes de usuario no soporten los mecanismos de estilo, los documentos se formatearán como sea apropiado para dicho agente de usuario. Esto permite a la Familia de agentes de usuario XHTML soportar modelos de formato ricos en dispositivos donde sea apropiado, y modelos de formato menores en dispositivos donde eso es lo apropiado.

2. Términos y Definiciones

Esta sección es informativa.

Mientras que algunos términos son definidos en su momento, las siguientes definiciones son utilizadas por todo este documento. La familiaridad con la recomendación W3C XML 1.0 [XML] está altamente recomendada.

módulo resumen

una unidad de una especificación de tipo de documento correspondiente a un tipo distinto de contenido, que se corresponda con una construcción de marcado que refleje este tipo distinto.

modelo de contenido

la declaración de estructura de marcado permitida dentro de las instancias de un tipo de elemento. XML 1.0 diferencia dos tipos: elementos que  contengan sólo a otros elementos (no datos de carácter) y contenidos mixtos (elementos que pueden contener datos de carácter opcionalmente entremezclados con elementos hijos). Los últimos se caracterizan por una especificación de contenido que comienza con la cadena "#PCDATA" (denotando datos de carácter).

modelo de documento

la estructura efectiva y las restricciones de un tipo de documento dado. El modelo de documento constituye una representación abstracta de la estructura física o semántica de un clase de documentos.

tipo de documento

una clase de documentos que comparten una estructura abstracta común. La definición ISO 8879 [SGML] es como sigue: "una clase de documentos teniendo características similares; por ejemplo, diario, artículo, manual técnico, o memoria. (4.102)"

definición de tipo de documento (DTD)

una expresión formal, legible por máquinas de la estructura XML y reglas de sintaxis con las que un documento instancia de un tipo de documento específico debe estar conforme; el tipo de esquema usado en XML 1.0 para validar la conformidad de una instancia de documento a su tipo de documento declarado. El mismo modelo de marcado puede ser expresado por una gran variedad de DTDs.

driver

un archivo generalmente corto usado para declarar e instanciar los módulos de una DTD. Una buena regla de estilo es un driver de una DTD no contenga declaraciones de marcado que comprendan cualquier parte del modelo de documento en sí mismo.

elemento

una instancia de un tipo de elemento.

tipo de elemento

la definición de un elemento, esto es, un contenedor para una clase semánticamente distinta de contenido del documento.

entidad

una entidad es una unidad de almacenamiento lógica o física de contenido del documento. Las entidades pueden estar compuestas de marcado analizable XML o datos de carácter, o contenido no analizable (e.d., no-XML, posiblemente no-textual). El contenido de una entidad puede ser definido enteramente dentro de la entidad del documento ("entidades internas") o externas a la entidad del documento ("entidades externas"). En entidades analizables, el texto de reemplazamiento puede incluir referencias a otras entidades.

entidad de referencia

una cadena mnemotécnica utilizada como referencia al contenido de una entidad declarada (por ejemplo, "&amp;" para "&", "&lt;" para "<", "&copy;" para "©".)

identificador genérico

el nombre por el que se identifica el tipo de un elemento. También, el nombre del tipo de elemento.

documento híbrido

Un documento híbrido es un documento que usa más de un espacio de nombres XML. Los documentos híbridos deben ser definidos como documentos que contienen elementos o atributos procedentes de tipos de documento híbridos.

instanciar

reemplazar una referencia a una entidad con una instancia de su contenido declarado.

declaración de marcado

una construcción sintáctica dentro de una DTD declarando una entidad o definiendo una estructura de marcado. Dentro de las DTDs de XML, hay cuatro tipos específicos: una entidad de declaración define la relación entre un símbolo mnemotécnico y su contenido de reemplazamiento; una declaración de elemento restringe que tipos de elementos pueden darse como descendientes dentro de un elemento (ver también modelo de contenido); una declaración de lista de atributos define el conjunto de atributos para un tipo de elemento dado, y  puede establecer también las restricciopnes de tipos y valores por defecto; la declaración de una notación define la relación entre un nombre de notación y un identificador externo referenciando el formato de una entidad no procesable.

modelo de marcado

el vocabulario de marcado (e.d., la gama de nombres de elementos y atributos, notaciones, etc.) y la gramática (e.d., el uso prescrito para ese  vocabulario) como es definida por una definición de tipo de documento (e.d., un esquema) El modelo de marcado es la representación concreta en sintaxis de marcado del modelo de documento, y puede ser definido con varios niveles de restricciones de conformidad. El mismo modelo de documento puede ser expresado por una variedad de modelos de marcado.

módulo

una unidad abstracta dentro de un modelo de documento expresada como un fragmento de una DTD, usada para consolidar las declaraciones de marcado incrementando la flexibilidad, modificabilidad, reusabilidad y comprensión de estructuras específicas lógicas o semánticas.

modularización

una implementación de un modelo de modularización; el proceso de composición o descomposición de una DTD mediante la división de  sus declaraciones de marcado en unidades o grupos que soporten metas específicas. Los módulos pueden o no existir como entidades fichero separadas (e.d., las estructuras físicas y lógicas de una DTD puede ser un espejo de cualquier otra, pero esto no es un requerimiento).

modelo de modularización

el diseño abstracto de la definición del tipo de documento (DTD) en soporte de las metas de la modularización, como reusabilidad, extensibilidad, expresividad, facilidad de documentación, tamaño del código, consistencia e intuitividad de uso. Es importante notar que un modelo de modularización está relacionada sólo ortogonalmente con el modelo de documento que describe, por lo que dos modelos de modularización muy diferentes pueden describir el mismo tipo de documento.

entidades parámetro

una entidad cuyo ámbito de uso está dentro del prólogo del documento (e.d., el subconjunto externo/DTD o el subconjunto interno). Las entidades Parámetro son rechazadas dentro de la instancia del documento.

documento tipo de documento padre

Un tipo de documento padre de un documento híbrido es el tipo de documento del elemento raíz.

etiqueta

marcado descriptivo que delimita el principio y el final(incluyendo su identificador genérico y cualesquiera atributos) de un elemento.

3. Definición de Conformidad

Esta sección es normativa.

En orden de asegurar que los documentos de la familia-XHTML son máximamente portables a través de los agentes de usuario de la familia-XHTML, esta especificación define rígidamente los requisitos de conformidad para ambos y para los tipos de documentos de la familia-XHTML. Mientras que las definiciones de conformidad pueden encontrarse en esta sección, éstas hacen necesariamente referencia a textos normativos dentro de este documento, dentro de la especificación base de XHTML [XHTML1], y dentro de otras especificaciones relacionadas. Solamente es posible comprender totalmente los requerimientos de conformidad de XHTML mediante una lectura completa de todas las referencias normativas.

Las palabras claves "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", y "OPTIONAL" en este documento van a ser interpretadas como se describe en [RFC2119].

3.1. Conformidad de Documentos del Tipo XHTML Host Language

Es posible modificar tipos de documentos existentes y definir enteramente nuevos tipos de documentos usando a la vez módulos definidos en esta especificación y otros módulos. De modo que un tipo de documento es "Conforme con XHTML Host Language" cuando reúne los siguientes criterios:

1. El tipo de documento debe ser definido usando uno de los métodos de implementación definidos por el W3C. Actualmente esto está limitado a DTDs XML, pero los Esquemas XML estarán disponibles pronto. El resto de esta sección se refiere a "DTDs" aunque otras implementaciones sean posibles.
2. La DTD que define el tipo de documento debe tener un identificador único como es definido en Reglas de Nomenclatura que use la cadena "XHTML" en su primer símbolo del texto de la descripción pública.
3. La DTD que define el tipo de documento debe incluir, como mínimo, la Estructura, el Hipertexto, el Texto, y la Lista de módulos definidos en esta especificación.
4. Para cada uno de los módulos definidos por el W3C que sean incluidos, todos los elementos, atributos, tipos de atributos (incluyendo cualquier lista requerida de valores enumerados), y cualquier modelo de contenido mínimo deben ser incluidos (y opcionalmente extendidos) en el modelo de contenido del tipo de documento. Cuando los modelos de contenido sean extendidos, todos los elementos y atributos (junto con sus tipos o cualquier lista de valores enumerados) requeridos en el modelo de contenido original deben continuar siendo requeridos.
5. La DTD que define el tipo de documento debe definir los elementos y atributos adicionales. De cualquier modo, éstos deben estar en su propio espacio de nombres XML [XMLNAMES].

3.2. Conformidad de documentos del tipo Grupo de Integración XHTML

También es posible definir tipos de documentos que estén basados en XHTML, pero que no sean adheridos a su estructura. Por lo que un tipo de documento será de "Conformidad con el grupo de Integración de XHTML" cuando siga los siguientes criterios:

1. El tipo de documento debe ser definido usando uno de los métodos de implementación definidos por el W3C. Actualmente esto está limitado a DTDs XML, pero los Esquemas XML estarán disponibles pronto. El resto de esta sección se refiere a "DTDs" aunque otras implementaciones sean posibles.
2. La DTD que define el tipo de documento debe tener un identificador único como es definido en Reglas de Nomenclatura que NO use la cadena "XHTML" en su primer símbolo del texto de la descripción pública.
3. La DTD que define el tipo de documento debe incluir, como mínimo, la Estructura, el Hipertexto, el Texto, y la Lista de módulos definidos en esta especificación.
4. Para cada uno de los módulos definidos por el W3C que sean incluidos, todos los elementos, atributos, tipos de atributos (incluyendo cualquier lista requerida de valores enumerados), y cualquier modelo de contenido mínimo deben ser incluidos (y opcionalmente extendidos) en el modelo de contenido del tipo de documento. Cuando los modelos de contenido sean extendidos, todos los elementos y atributos (junto con sus tipos o cualquier lista de valores enumerados) requeridos en el modelo de contenido original deben continuar siendo requeridos.
5. La DTD que define el tipo de documento debe definir los elementos y atributos adicionales. De cualquier modo, éstos deben estar en su propio espacio de nombres XML [XMLNAMES].

3.3. Conformidad de los Módulos de la Familia XHTML

Esta especificación define un método para definir módulos de conformidad XHTML. Un módulo será conforme a esta especificación cuando cumpla con los siguientes criterios:

1. El tipo de documento debe ser definido usando uno de los métodos de implementación definidos por el W3C. Actualmente esto está limitado a DTDs XML, pero los Esquemas XML estarán disponibles pronto. El resto de esta sección se refiere a "DTDs" aunque otras implementaciones sean posibles.
2. La DTD que define el módulo debe tener un identificador único como es definido en Reglas de Nomenclatura.
3. Cuando el módulo es definido usando una DTD XML, el módulo debe aislar los nombres de sus entidades de parámetros mediante el uso de prefijos únicos o cualquier otro método similar.
4. La definición del módulo debe tener una definición en prosa que describa los requerimientos sintácticos y semánticos de los elementos, atributos, y/o modelos de contenido que declare.
5. La definición del módulo no debe rechazar ningún nombre de elemento que sea definido en otros módulos definidos por el W3C, excepto cuando el modelo de contenido y la semántica de esos elementos sea bien idéntica al original o bien una extensión del original, o cuando los nombres de los elementos rehusados estén dentro de su propio espacio de nombres (ver abajo).
6. La definición de elementos y atributos del módulo debe ser parte de un espacio de nombres XML [XMLNAMES]. Si el módulo es definido por una organización distinta del W3C, este espacio de nombres NO debe ser el mismo espacio de nombres que es definido en otros módulos del  W3C.

3.4. Conformidad de Documentos de la Familia XHTML

Un documento de conformidad con la familia XHTML es una instancia válida de un Tipo de Documento XHTML Host Language.

3.5. Conformidad de la Familia de Agentes de Usuario XHTML

Un agente de usuario de conformidad debe seguir todos los criterios siguientes (como es definido en [XHTML1]):

1. Para ser consistente con la Recomendación XML 1.0 [XML], el agente de usuario debe analizar y evaluar si un documento XHTML es "gramaticalmente correcto".Si el agente de usuario se dice convalidante, debe contrastar los documentos con las DTD de acuerdo con [XML].
2. Cuando un agente de usuario dice soportar recursos definidos en esta especificación o requeridos por esta especificación como referencia normativa, debe hacerlo de modo que sea consistente con la definición de los recursos.
3. Cuando una aplicación de usuario procesa un documento XHTML como XML genérico [XML], tan sólo debería reconocer atributos del tipo ID (e.g. el atributo id de la mayoría de los elementos XHTML) como identificadores de fragmentos.
4. Si una aplicación de usuario encuentra un elemento que no reconoce, debe presentar el contenido de dicho elemento al usuario.
5. Si una aplicación de usuario encuentra un atributo que no reconoce, debe ignorar completamente la directriz que marque el atributo (e.d., el atributo y su valor).
6. Si una aplicación de usuario encuentra un valor de un atributo que no reconoce, debe usar en su lugar el valor por defecto del atributo.
7. Si encuentra una referencia a una entidad (distinta a las entidades predefinidas) para la que la aplicación de usuario no ha procesado ninguna declaración (lo que podría suceder si la declaración se encuentra en un subconjunto externo al que la aplicación de usuario no ha accedido), la entidad debe presentarse como los caracteres (comenzando con & y terminando con punto y coma) que componen la referencia a la entidad.
8. Cuando se presente el contenido, las aplicaciones de usuario que encuentren caracteres o referencias a entidades de tipo carácter que reconozcan pero que no sean capaces de mostrar, deberían mostrar el documento de tal manera que el usuario aprecie claramente que no ha sido posible una presentación correcta.

9. Los espacios en blanco se manejan de acuerdo a las siguientes reglas. Los siguientes caracteres se definen en [XML] como caracteres de espacios en blanco:

   • ESPACIO (&#x0020;)
   • TABULACIÓN (&#x0009;)
   • RETORNO DE CARRO (&#x000D;)
   • SALTO DE LÍNEA (&#x000A;)

   El procesador XML normaliza varios sistemas de códigos de fin de línea en un único carácter de avance de línea que se pasa a la aplicación.

   El agente de usuario debe procesar los caracteres de espacios en blanco de los datos recibidos del procesador XML como sigue:

   • Todos los espacios en blanco que rodean a un elemento en bloque deberían ser suprimidos.
   • Los comentarios se suprimen por completo y no afectan a la manipulación de espacios en blanco. Un carácter de espacio en blanco a ambos lados de un comentario se trata como dos espacios en blanco.
   • En elementos donde el atributo 'xml:space' tenga el valor 'preserve', la aplicación de usuario debe conservar intactos todos los espacios en blanco (con excepción de los caracteres de espacio en blanco de encabezamiento y terminación, que deberían ser suprimidos).
   • Cuando el atributo 'xml:space' no tenga el valor 'preserve', entonces:
     • Todos los espacios en blanco que rodean o están dentro de un elemento de nivel de bloque deberían ser suprimidos.
     • Los caracteres de SALTO DE LÍNEA deben ser convertidos en uno de los siguientes caracteres: un carácter  ESPACIO, un ESPACIO DE ANCHURA NULA (&#x200B;), o ningún carácter (e.d. removido). La elección del carácter resultante dependerá del agente de usuario y está condicionada por la propiedad script de los caracteres que preceden y siguen al carácter de  SALTO DE LÍNEA.
     • Una secuencia de caracteres de espacios en blanco sin ningún  SALTO DE LÍNEA debe ser reducida a un único carácter ESPACIO.
     • Una secuencia de caracteres de espacios en blanco con uno o más  SALTOS DE LÍNEA debe ser reducida del mismo modo que un único carácter SALTO DE LÍNEA.

   El espacio en blanco en los valores de atributos se procesa de acuerdo con [XML].

   Nota (informativa): Para determinar como convertir un carácter de SALTO DE LÍNEA un agente de usuario debería considerar los siguientes casos, por los que el script de caracteres en cada uno de los casos de los SALTOS DE LÍNEA determine la elección del reemplazamiento. Los caracteres de script COMÚN (como la puntuación) son tratados por el mismo script en el otro caso:

   1. Si los caracteres precedentes y siguientes a un SALTO DE LÍNEA pertenecen a un script en el que el carácter ESPACIO es usado como un separador de palabras, el carácter SALTO DE LÍNEA debería ser convertido en un carácter ESPACIO. Ejemplos de dichos scripts son Latín, Griego, y Cirílico.
   2. Si los caracteres precedentes y siguientes a un SALTO DE LÍNEA pertenecen a un script basado en ideografía o sistema de escritura en el que no hay separadores de palabras, el carácter SALTO DE LÍNEA no debería ser convertido en un carácter. Ejemplos de dichos scripts o sistemas de escritura son Chino, Japonés.
   3. Si los caracteres precedentes y siguientes a un SALTO DE LÍNEA pertenecen a un script no basado en ideografía o sistema de escritura en el que no hay separadores de palabras, el carácter SALTO DE LÍNEA debería ser convertido en un carácter ESPACIO DE ANCHURA NULA (&#x200B;) o en ningún carácter. Ejemplos de dichos scripts son Tailandés, Khmer.
   4. Si ninguna de las condiciones de (1) hasta (3) es verdadera, el carácter SALTO DE  LÍNEA debería ser convertido en un carácter ESPACIO.

   La documentación técnica Unicode [UNICODE] TR#24 (Script Names) proporciona una asignación de nombres de script a todos los caracteres.

3.6. Reglas de Nomenclatura

Los tipos de documento XHTML Host Language deben adherirse tan estrictamente a las convenciones de nomenclatura como sea posible para el software y los usuarios para determinar fácilmente la relación entre documentos del tipo XHTML. Los nombres para los tipos de documentos implementados como definiciones de tipo de documento XML son definidos mediante Identificadores Formales Públicos (FPIs). Dentro de los FPIs, los campos están separados por secuencias del carácter doble barra (//). Los diversos campos deben componerse como sigue:

1. El campo principal debe ser "-" para indicar un recurso definido privadamente.
2. El segundo campo debe contener el nombre de la organización responsable de mantener el citado ítem. No existe un registro formal para estos nombres de organización. Cada organización debería definir un nombre que sea único. El nombre utilizado por el W3C es, por ejemplo, W3C.
3. El tercer campo contendrá dos construcciones: el texto de la clase pública seguido por el texto de la descripción pública. El primer símbolo en el tercer campo es el texto de la clase pública que debería estar adherida a ISO 8879 Clause 10.2.2.1 Public Text Class. Solamente documentos de conformidad con XHTML Host Language deberían comenzar el texto de la descripción pública con el símbolo XHTML. El texto de la descripción pública debería contener la cadena XHTML si el tipo de documento es de conformidad con el Grupo de Integración. El campo debería contener también un identificador único definido por la organización (e.g., MyML 1.0). Este debería estar compuesto de un nombre único y un identificador de la versión que pueda ser actualizado cuando el tipo de documento evolucione.
4. El cuarto campo define el lenguaje en el que se ha desarrollado este ítem (e.g., EN).

Usando estas reglas, el nombre para un tipo de documento de conformidad con XHTML Host Language debería ser -//MyCompany//DTD XHTML MyML 1.0//EN. El nombre para un módulo de conformidad con la familia XHTML debería ser -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN. El nombre para un tipo de documento de conformidad con XHTML debería ser -//MyCompany//DTD Special Markup with XHTML//EN.

3.7. Evolución de los Módulos XHTML

A cada módulo definido en esta especificación se le da un identificador único que lo adhiere a las reglas de nomenclatura de la sección previa. Con el tiempo, un módulo puede evolucionar. Una ramificación lógica de dicha evolución puede ser que algunos aspectos del módulo no sean mucho más tiempo compatibles con su definición previa. Para ayudarnos a asegurarnos que los tipos de documentos definidos contra los módulos definidos en esta especificación continúan operativos, los identificadores asociados con un módulo que cambie serán actualizados. Específicamente, el Identificador Formal Público y el Identificador del Sistema del módulo serán cambiados mediante la modificación del identificador de versión incluido en ambos. Los tipos de Documento que vayan a incorporar la funcionalidad actualizada necesitarán ser actualizados similarmente.

En adición, la(s) versión(es) anterior(es) del módulo continuarán estando accesibles vía su anterior identificador único. De este modo, los tipos de documento desarrollados usando módulos XHTML continuarán funcionando del mismo modo usando sus definiciones originales aunque la colección se expanda y evolucione. Similarmente, las instancias de documento escritas contra dichos tipos de documento continuarán validando usando las definiciones anteriores de los módulos.

Otros autores de Familias de Módulos y Tipos de Documento XHTML son alentados a adoptar una estrategia similar para asegurarse del funcionamiento continuado de los tipos de documento basados en esos módulos y las instancias de documentos basados en esos tipos de documento.

4. Definiendo Módulos Resumen

Esta sección es normativa.

Un módulo resumen es una definición de un módulo XHTML usando texto en prosa y algunas convenciones informales de marcado. Mientras que una definición no es generalmente usual en el procesado por la máquina del tipo de documento, es crítica ayudando a la gente a comprender qué está contenido en el módulo. Esta sección define el modo en el que los módulos resumen de XHTML son definidos. En un módulo de conformidad XHTML  no está requerido proporcionar una definición del módulo resumen. De cualquier modo, se sugiere altamente a cualquiera que desarrolle un módulo XHTML proporcionar una definición de dicho módulo para aumentar su facilidad de uso.

4.1. Convenciones Sintácticas

Los módulos resumen no están definidos con una gramática formal. De cualquier modo, las definiciones se adherirán a las siguientes convenciones sintácticas. Estas convenciones son similares a las de las DTDs de XML, y deberían ser familiares para los autores de DTDs XML. Cada elemento sintáctico discreto puede ser combinado con otros para construir expresiones más complejas conformes con el álgebra definida aquí.

nombre de elemento

Cuando se incluye un elemento en un modelo de contenido, su nombre explicito será listado.

sistema de contenido

Algunos módulos definen listas de nombres explícitos de elementos llamados sistemas de contenido. Cuando un sistema de contenido es incluido en un modelo de contenido, su nombre será listado.

expr ?

Cero o una instancias de expr están permitidas.

expr +

Una o más instancias de expr son requeridas.

expr *

Cero o más instancias de expr están permitidas.

a , b

La expresión a está requerida, seguida por la expresión b.

a | b

Bien la expresión a o bien la expresión b están requeridas.

a - b

La expresión a es permitida, omitiendo elementos en la expresión b.

paréntesis

Cuando una expresión está contenida entre paréntesis, la evaluación de cualquier subexpresión dentro de los paréntesis tiene lugar antes de la evaluación de expresiones fuera de los paréntesis (comenzando primero por el nivel más bajo en la jerarquía).

extendiendo elementos pre-definidos

En algunos casos, un módulo agrega atributos a un elemento. En estos casos, el nombre del elemento está seguido por un ampersand (&).

definiendo atributos requeridos

Cuando un elemento requiere la definición de un atributo, dicho nombre de atributo está seguido por un asterisco (*).

definiendo el tipo de valores de atributo

Cuando un módulo define el tipo de valor de un atributo, lo hace listando el tipo entre paréntesis después del nombre del atributo.

definiendo los valores legales de los atributos

Cuando un módulo define los valores legales para un atributo, lo hace listando explícitamente los valores legales (encerrados entre comillas), separados por barras verticales (|), dentro de paréntesis siguiendo al nombre del atributo. Si el atributo tiene un valor por defecto, dicho valor está seguido por un asterisco (*). Si el atributo tiene un valor fijo, el nombre del atributo está seguido por un signo igual (=) y el valor fijo encerrado entre comillas.

4.2. Tipos de Contenido

Las definiciones de módulos Resumen definen mínimamente, modelos de contenido atómicas para cada módulo. Estos modelos de contenido mínimos hacen referencia a los elementos en el propio módulo. además, pueden hacer referencia a elementos en otros módulos respecto de los que el módulo resumen es dependiente. Finalmente, el modelo de contenido en algunos casos requiere que el texto esté permitido como contenido de uno o más elementos. En estos casos, el símbolo usado para texto es PCDATA. Este es un término, definido en la Recomendación XML 1.0, que hace referencia al procesado de datos de carácter. Un tipo de contenido puede ser definido también como EMPTY o vacío, queriendo decir que el elemento no tiene contenido en su mínimo modelo de contenido.

4.3. Tipos de Atributos

En algunas ocasiones, es necesario definir los tipos de valores de atributos o el grupo explícito de valores permitidos para los atributos. Los siguientes tipos de atributos (definidos en la Recomendación XML 1.0) son utilizados en las definiciones de módulos resumen:

En adición a estos tipos de datos predefinidos, la Modularización de XHTML define los siguientes tipos de datos y sus semánticas (como es apropiado):

Tipo de Dato	Descripción
Character	Un único carácter de [ISO10646].
Charset	Un código de carácter, según [RFC2045].
Charsets	Una lista separada por espacios de códigos de carácter, según [RFC2045].
Color	El tipo de valor del atributo "Color" se refiere a definiciones de color como son especificadas en [SRGB]. Un valor de un color puede ser tanto un número hexadecimal (precedido por una marca de cuadro) o uno de los siguientes dieciséis nombres de colores. Los nombres de color son case-insensitive (insensibles al uso de mayúsculas y minúsculas). Nombres de Colores y valores sRGB Negro = "#000000" Verde = "#008000" Plateado = "#C0C0C0" Lima = "#00FF00" Gris = "#808080" Oliva = "#808000" Blanco = "#FFFFFF" Amarillo = "#FFFF00" Marrón = "#800000" Marino = "#000080" Rojo = "#FF0000" Azul = "#0000FF" Púrpura = "#800080" Teal = "#008080" Fucsia = "#FF00FF" Agua = "#00FFFF" Por tanto, los valores de color "#800080" y "Purple" se refieren ambos al color púrpura.
ContentType	Un tipo de medio, según [RFC2045].
ContentTypes	Una lista separada por comas de tipos de medios, según [RFC2045].
Coords	Una lista separada por comas de coordenadas a usar en áreas definidas.
Datetime	Información de día y hora.
FPI	Una cadena de caracteres representando un Identificador Formal Público SGML.
FrameTarget	Nombre del frame usado como destino para resultados de ciertas acciones.
LanguageCode	Un código de lenguaje, según [RFC3066].
Length	El valor puede estar tanto en pixels como en porcentaje del espacio vertical u horizontal disponible. Por tanto, el valor "50%" significa la mitad del espacio disponible.
LinkTypes	Los autores pueden usar los siguientes tipos de link reconocidos, listados aquí con sus interpretaciones convencionales. Un valor de LinkTypes se refiere a una lista separada por espacios de tipos de link. Los caracteres de espacio en blanco no están permitidos dentro de los tipos de link. Estos tipos de link son case-insensitive, e.d., "Alternate" tiene el mismo significado que "alternate". Los Agentes de Usuario, motores de búsqueda, etc. deben interpretar estos tipos de link en una gran variedad de modos. Por ejemplo, los agentes de usuario deben proporcionar acceso a documentos enlazados mediante una barra de navegación. Alternate Designa versiones sustituibles para el documento en que se da el link. Cuando se usa en conjunto con el atributo hreflang , implica una versión traducida del documento. Cuando se usa en conjunto con el atributo media , implica una versión diseñada para un medio diferente (o media). Stylesheet Se refiere a una hoja de estilo externa. Ver el Módulo Style para los detalles. Es usado junto con el tipo de link "Alternate" para proporcionar hojas de estilo alternativas seleccionables por el usuario. Start Se refiere al primer documento en una colección de documentos. Este tipo de link le dice a los motores de búsqueda qué documento es considerado por el autor el punto de partida de la colección. Next Se refiere al siguiente documento en una secuencia lineal de documentos. Los agentes de usuario pueden elegir  pre-cargar el "siguiente" documento, para reducir el tiempo percibido de carga. Prev Se refiere al documento previo en una serie ordenada de documentos. Algunos agentes de usuario también soportan el sinónimo "Previous". Contents Se refiere a un documento que sirve como tabla de contenidos. Algunos agentes de usuario también soportan el sinónimo ToC (de "Table of Contents"). Index Se refiere a un documento proporcionando un índice para el documento actual. Glossary Se refiere a un documento proporcionando un glosario de términos que pertenecen al documento actual. Copyright Se refiere a la sentencia de copyright para el documento actual. Chapter Se refiere a un documento que sirve como un capítulo en una colección de documentos. Section Se refiere a un documento que sirve como una sección en una colección de documentos. Subsection Se refiere a un documento que sirve como una subsección en una colección de documentos. Appendix Se refiere a un documento que sirve como un apéndice en una colección de documentos. Help Se refiere a un documento que ofrece ayuda (más información, enlaces a otra fuente de información, etc.) Bookmark Se refiere a un bookmark. Un bookmark es un enlace a un punto clave dentro de un documento extenso. El atributo title puede ser utilizado, por ejemplo, para etiquetar el bookmark. Notar que varios bookmarks pueden ser definidos en un mismo documento.
MediaDesc	El atributo MediaDesc es una lista separada por comas de descriptores de medios. La siguiente es una lista de tipos reconocidos de descriptores de medios: screen Intencionado para pantallas no paginadas de computadoras. tty Intencionado para medios que utilicen una rejilla de caracteres de terreno fijo, como los teletipos, terminales, o dispositivos portátiles con capacidades de presentación limitadas. tv Intencionado para dispositivos del tipo de la televisión (baja resolución, color, capacidad de scroll limitada). projection Intencionado para proyectores. handheld Intencionado para dispositivos de mano (pantalla pequeña, monocromáticos, gráficos de mapas de bits, ancho de banda limitado). print Intencionado para paginado, material opaco y para documentos vistos en pantalla en modo presentación preliminar. braille Intencionado para dispositivos braille de respuesta táctil. aural Intencionado para sintetizadores de sonido. all Soportable por todos los dispositivos. Futuras versiones de XHTML pueden introducir nuevos valores y pueden permitir valores a los que se les pasen parámetros. Para facilitar la introducción de estas extensiones, los agentes de usuario de conformidad deben ser capaces de procesar el valor del atributo media como sigue: El valor es una lista separada por comas de las entradas. Por ejemplo, media="screen, 3d-glasses, print and resolution > 90dpi" es mapeado a: "screen" "3d-glasses" "print and resolution > 90dpi" Cada entrada es truncada justo antes del primer carácter que no sea una letra de US ASCII [a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), dígito [0-9] (hex 30-39), o guión-menos (hex 2d). En el ejemplo, esto da: "screen" "3d-glasses" "print" Una búsqueda independiente del uso de mayúsculas o minúsculas se hace entonces con el grupo de tipos de medios definido anteriormente. Los agentes de usuario ignorarán las entradas que no procedan. En el ejemplo lo hacemos con screen y print. Nota. Las hojas de estilo pueden incluir variaciones de medios dentro de ellas (e.g., la construcción CSS @media). En estos casos es muy apropiado el uso de "media =all".
MultiLength	El valor puede ser una longitud o una distancia relativa. Una distancia relativa tiene la forma "i*", donde "i" es un entero. Cuando se asigna un espacio entre elementos que compiten por dicho espacio, los agentes de usuario asignan píxel y longitudes de porcentaje primero, entonces dividen el espacio que permanece disponible entre medidas relativas. Cada longitud relativa recibe una proporción del espacio disponible que resulta proporcional al entero que precede al "*". El valor "*" es equivalente a "1*". Por tanto, si se encuentran disponibles 60 pixels de espacio después de que el agente de usuario asigna espacios de píxel y porcentaje, y las longitudes relativas que están compitiendo son 1*, 2*, y 3*, al 1* le serán asignados 10 pixels, al 2* le serán asignados 20 pixels, y al 3* le serán asignados 30 pixels.
MultiLengths	Una lista de items separados por comas del tipo MultiLength.
Number	Uno o más dígitos
Pixels	El valor es un entero que representa el número de pixels del fondo (pantalla, papel). Por tanto, el valor "50" quiere decir cincuenta pixels. Por información normativa sobre la definición de un píxel, consulte por favor [CSS2]
Script	Los datos de Script pueden ser el contenido del elemento "script" y el valor de los atributos de eventos intrínsecos. Los agentes de usuario no deben evaluar los datos de un script como marcado HTML y en su lugar deben pasar dichos datos a un motor de script. La sensitividad al uso de mayúsculas o minúsculas de los datos de un script depende del lenguaje de scripting. Por favor, nótese que los datos de un script que sean contenidos de un elemento no pueden contener referencias de carácter, pero los datos de script que son el valor de un atributo si que pueden contenerlas.
Shape	La forma de una región.
Text	Datos textuales arbitrarios, que poseen significado para su lectura por humanos.
URI	Un Identificador Uniforme de Recurso, también [URI].
URIs	Una lista separada por espacios de Identificadores Uniformes de Recursos, también [URI].

4.4. Un Ejemplo de Definición de Módulo Resumen

Esta sección es informativa

Esta sección define un ejemplo de módulo resumen que ejemplifique como aprovechar las reglas de sintaxis definidas previamente. Como en este ejemplo se están tratando de utilizar toda la variedad de elementos sintácticos definidos, es algo complicado. Las definiciones típicas de módulos serían mucho más simples que ésta. Finalmente, notar que este módulo hace referencia a la colección de atributos Common. Se trata de una colección definida en la especificación Modularización de XHTML que incluye todos los atributos básicos que la mayoría de elementos necesitan.

4.4.1. Módulo XHTML de Esquí

El Módulo XHTML de Esquí define el marcado utilizado cuando se describen aspectos de un albergue de esquí. Los elementos y atributos definidos en este módulo son:

Este módulo también define el grupo de contenidos Aspen con el modelo de contenido mínimo lodge | lift | chalet | room | lobby | fireplace.

5. Módulos Resumen de XHTML

Esta sección es normativa.

Esta sección especifica los contenidos de los módulos resumen de XHTML. Estos módulos son definiciones resumidas de colecciones de elementos, atributos, y sus modelos de contenido. Estos módulos resumen pueden ser mapeados en cualquier mecanismo de especificación apropriado. Implementaciones de los Módulos DTD XHTML, por ejemplo, mapearán estos módulos en DTDs como es descrito en [XML].

Los diseñadores de contenidos y los diseñadores de dispositivos deberían ver esta sección como una guía para la definición de la funcionalidad proporcionada por los distintos módulos de XHTML definidos. Cuando se desarrollan documentos o se define un perfil para una clase de documentos, los desarrolladores de contenidos pueden determinar cuáles de estos módulos son esenciales para expresar sus mensajes. Cuando se diseñan clientes, los desarrolladores de dispositivos deberían desarrollar los perfiles de sus dispositivos eligiendo entre los módulos resumen definidos aquí.

Excepto cuando se  especifique lo contrario en este documento, la semántica de estos elementos y atributos está definida en [HTML4].

5.1. Colecciones de Atributos

La mayor parte de los módulos resumen en esta sección definen los atributos requeridos para los elementos. La tabla siguiente define algunas colecciones de atributos que son referenciadas en los módulos. Estas expresiones no deberían ser consideradas de ningún modo normativas o mandatorias. Son una conveniencia editorial para este documento. Cuando sean usadas en el resto de esta sección, es la expansión del término la que es normativa, no el término en si mismo.

Los siguientes grupos básicos de atributos son utilizados en la mayoría de elementos. En cada caso en el que son utilizados, su uso es identificado vía su nombre de colección en lugar de enumerando la lista.

Notar que la colección de Eventos solamente está definida cuando el Módulo de Eventos Intrínsecos está seleccionado. De cualquier otro modo, la colección de Eventos está vacia.

Notar también que la colección Style solamente está definida cuando el Módulo del Atributo Style está seleccionado. De cualquier otro modo, la colección Style está vacía.

5.2. Módulos del Núcleo

Los módulos del núcleo son módulos cuya presencia es requerida en cualquier Documento de Conformidad con la Familia XHTML.

5.2.1. Módulo de Estructura

El Módulo de Estructura define los principales elementos estructurales para XHTML. Estos elementos actúan efectivamente como la base para el modelo de contenido de la mayoría de tipos de documento de la familia XHTML. Los elementos y atributos incluidos en este módulo son:

Este módulo es la definición estructural básica  para los contenidos XHTML. El elemento html actúa como elemento raíz para todos los Documentos del Tipo de la Familia XHTML.

Notar que el valor del atributo xmlns está definido para ser "http://www.w3.org/1999/xhtml". Notar también que debido a que el atributo xmlns es tratado especialmente por los procesadores XML compatibles con espacios de nombre [XMLNAMES], es legal tenerlo presente como un atributo de cada elemento. De cualquier modo, una vez que el atributo xmlns es utilizado en el contexto de un módulo XHTML, tanto con un prefijo como sin él, el valor del atributo debería ser el espacio de nombres XHTMLdefinido aquí. Ver Definiendo el Espacio de Nombres de un Módulo para más reglas relacionadas con el uso de espacios de nombres con módulos de la familia XHTML.

Implementación: DTD

5.2.2. Módulo de Texto

Este módulo define todos los elementos que contengan texto básico, atributos, y su modelo de contenido:

El modelo de contenido mínimo para este módulo define algunos grupos de contenidos:

Cabeceras

h1 | h2 | h3 | h4 | h5 | h6

Bloques

address | blockquote | div | p | pre

En línea

abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span | strong | var

Flujo

Heading | Block | Inline

Implementación: DTD

5.2.3. Módulo de Hipertexto

El Módulo de Hipertexto proporciona el elemento que es utilizado para definir enlaces de hipertexto a otros recursos. Este módulo soporta los siguientes elementos y atributos: