Nota de Traducción
Este documento se encontrará en estado de borrador durante un periodo indefinido de tiempo dedicado a efectuar las correciones oportunas.(Los posibles errores presentes en este documento, debidos a la
traducción, son de la responsabilidad del traductor y no
son achacables en modo alguno al W3C). Para cualquier comentario
sobre la traducción dirigirse a Pedro
Palazón Candel
Este documento se encuentra también alojado en la web de la Organización Sidar con URI:http://www.sidar.org/traduc/modxhtml/index.html
La única versión normativa
oficial de este documento es la versión original (en
inglés): http://www.w3.org/TR/xhtml-modularization/
Modularización de
XHTML™
Recomendación
del W3C de 10 de Abril de 2001
- Esta versión:
-
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410
(Un único archivo
HTML, Versión
PostScript, Versión
PDF, Archivo ZIP, o Archivo TAR-Gzip)
- Última versión:
- http://www.w3.org/TR/xhtml-modularization
- Versión Previa:
-
http://www.w3.org/TR/2001/PR-xhtml-modularization-20010222
- Editores:
- Murray Altheim, Sun Microsystems
Frank Boumphrey, HTML Writers Guild
Sam Dooley, IBM
Shane McCarron, Applied Testing and
Technology
Sebastian
Schnitzenbaumer, Mozquito
Technologies AG
Ted Wugofski, Openwave (formerly Gateway)
Copyright ©2001 W3C®
(MIT,
INRIA, Keio), All
Rights Reserved. W3C
liability,
trademark,
document use and
software licensing rules apply.
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 el Grupo de Trabajo de
HTML del W3C (de acceso
exclusivo a sus miembros) 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
www-html@w3.org (archivo).
Para subscribirse envíe un email a www-html-request@w3.org
con la palabra subscribe en la línea del asunto
(subject).
Por favor remita los errores en este documento a www-html-editor@w3.org
(archivo).
La lista de
errores conocidos en esta especificación está
disponible en
http://www.w3.org/2001/04/REC-xhtml-modularization-20010410-errata.
La versión en Inglés de esta
especificación es la única versión
normativa. Se encuentra disponible información sobre las
traducciones de
este documento en http://www.w3.org/MarkUp/translations.
Una lista de la Recomendaciones actuales del W3C y otros
documentos técnicos puede encontrarse en http://www.w3.org/TR.
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.
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, "&" para
"&", "<" para "<", "©" 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:
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- La DTD que define el módulo debe tener un
identificador único como es definido en Reglas de Nomenclatura.
- 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.
- 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.
- 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).
- 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]):
- 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].
- 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.
- 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.
- Si una aplicación de usuario encuentra un elemento que
no reconoce, debe presentar el contenido de dicho elemento al
usuario.
- 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).
- 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.
- 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.
- 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.
-
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 ( )
- TABULACIÓN (	)
- RETORNO DE CARRO (
)
- SALTO DE LÍNEA (
)
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 (​), 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:
- 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.
- 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.
- 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 (​) o en ningún carácter.
Ejemplos de dichos scripts son Tailandés, Khmer.
- 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:
- El campo principal debe ser "-" para indicar un recurso
definido privadamente.
- 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.
- 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.
- 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:
| Tipo de Atributo |
Definición |
| CDATA |
Datos de Carácter |
| ID |
Un identificador único del documento |
| IDREF |
Una referencia a un identificador único del
documento |
| IDREFS |
Una lista separada por espacios de referencias a
identificadores únicos de documento |
| NAME |
Un nombre con los mismos caracteres que contiene el ID
anterior |
| NMTOKEN |
Un nombre compuesto solamente de símbolos de nombre
como es definido en XML 1.0 [XML] |
| NMTOKENS |
Uno o más valores NMTOKEN separados mediante espacios
en blanco |
| PCDATA |
Datos de carácter Procesables |
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:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| resort |
Common, href (CDATA) |
description, Aspen+ |
| lodge |
Common |
description, (Aspen - lift)+ |
| lift |
Common, href |
description? |
| chalet |
Common, href |
description? |
| room |
Common, href |
description? |
| lobby |
Common, href |
description? |
| fireplace |
Common, href |
description? |
| description |
Common |
PCDATA* |
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.
| Nombre de Colección |
Atributos en la Colección |
| Core |
class (NMTOKENS), id (ID), title (CDATA) |
| I18N |
xml:lang (NMTOKEN) |
| Events |
onclick (Script), ondblclick (Script),
onmousedown (Script), onmouseup (Script),
onmouseover (Script), onmousemove (Script),
onmouseout (Script), onkeypress (Script),
onkeydown (Script), onkeyup (Script) |
| Style |
style (CDATA) |
| Common |
Core + Events + I18N +
Style |
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:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| body |
Common |
(Heading | Block | List)* |
| head |
I18N, profile (URI) |
title |
| html |
I18N, version (CDATA), xmlns
(URI =
"http://www.w3.org/1999/xhtml") |
head, body |
| title |
I18N |
PCDATA |
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:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| abbr |
Common |
(PCDATA | Inline)* |
| acronym |
Common |
(PCDATA | Inline)* |
| address |
Common |
(PCDATA | Inline)* |
| blockquote |
Common, cite (URI) |
(PCDATA | Heading | Block | List)* |
| br |
Core |
EMPTY |
| cite |
Common |
(PCDATA | Inline)* |
| code |
Common |
(PCDATA | Inline)* |
| dfn |
Common |
(PCDATA | Inline)* |
| div |
Common |
(PCDATA | Flow)* |
| em |
Common |
(PCDATA | Inline)* |
| h1 |
Common |
(PCDATA | Inline)* |
| h2 |
Common |
(PCDATA | Inline)* |
| h3 |
Common |
(PCDATA | Inline)* |
| h4 |
Common |
(PCDATA | Inline)* |
| h5 |
Common |
(PCDATA | Inline)* |
| h6 |
Common |
(PCDATA | Inline)* |
| kbd |
Common |
(PCDATA | Inline)* |
| p |
Common |
(PCDATA | Inline)* |
| pre |
Common,
xml:space="preserve" |
(PCDATA | Inline)* |
| q |
Common, cite (URI) |
(PCDATA | Inline)* |
| samp |
Common |
(PCDATA | Inline)* |
| span |
Common |
(PCDATA | Inline)* |
| strong |
Common |
(PCDATA | Inline)* |
| var |
Common |
(PCDATA | Inline)* |
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:
Este módulo añade el elemento a al
grupo de contenido En línea
del Módulo de Texto.
Implementación: DTD
5.2.4.
Módulo de Lista
Como sugiere su nombre, el Módulo de Lista proporciona
elementos orientados a listas. Específicamente, El
Módulo de Lista soporta los siguientes elementos y
atributos:
Este módulo también define el grupo de contenido
Lista con el mínimo modelo de contenido (dl | ol | ul)+ y agrega este grupo al
grupo de contenidos Flujo del Módulo de Texto.
Implementación: DTD
5.3.
Módulo de Applet
Este módulo es desaconsejado - en desuso. Una
funcionalidad similar puede encontrarse en el Módulo Object.
El Módulo de Applet proporciona elementos para
referenciar aplicaciones externas. Específicamente,
el Módulo de Applet soporta los siguientes elementos y
atributos:
| Elemento |
Atributos |
Modelo de Contenido Mínimo |
| applet |
Core, alt* (Text), archive (CDATA), code
(CDATA),
codebase (URI), height* (Length), object
(CDATA),
width* (Length) |
(PCDATA | Flow | param)* |
| param |
id (ID),
name* (CDATA), type (ContentType), value (CDATA), valuetype
("data"* | "ref" | "object") |
EMPTY |
Cuando el Módulo de Applet es utilizado, añade
el elemento applet al grupo En línea de
contenidos del Módulo de Texto.
Implementación: DTD
5.4. Módulos de
Extensión de Texto
Esta sección define una variedad de módulos de
marcado textuales adicionales.
5.4.1. Módulo de
Presentación
Este módulo define elementos, atributos, y un modelo de
contenido mínimo para el marcado relacionado con una
presentación simple:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| b |
Common |
(PCDATA | Inline)* |
| big |
Common |
(PCDATA | Inline)* |
| hr |
Common |
EMPTY |
| i |
Common |
(PCDATA | Inline)* |
| small |
Common |
(PCDATA | Inline)* |
| sub |
Common |
(PCDATA | Inline)* |
| sup |
Common |
(PCDATA | Inline)* |
| tt |
Common |
(PCDATA | Inline)* |
Cuando este módulo es utilizado, el elemento
hr es añadido al grupo
de contenidos de bloque del Módulo de Texto. En
adición, los elementos b, big, i, small, sub,
sup, y tt son añadidos al grupo de
contenidos En Línea del Módulo de Texto.
Implementación: DTD
5.4.2.
Módulo de Edición
Este módulo define elementos y atributos para usar en
marcado relacionado con la edición:
Cuando este módulo es usado, los elementos
del y ins son añadidos al grupo
de contenidos En Línea del Módulo de Texto.
Implementación: DTD
5.4.3.
Módulo de Texto Bi-direccional
El Módulo de Texto Bi-direccional define un elemento
que puede ser utilizado para declarar las reglas bi-direccionales
para el contenido de los elementos.
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| bdo |
Core, dir* ("ltr" |
"rtl") |
(PCDATA | Inline)* |
Cuando este módulo es usado, el elemento
bdo es añadido al grupo de contenidos En
Línea del Módulo de Texto. Seleccionando este
módulo también se añade el atributo
dir* ("ltr" | "rtl") a la colección de
atributos I18N.
Implementación: DTD
5.5. Módulos de
Formulario
5.5.1.
Módulo de Formulario Básico
El Módulo de Formulario Básico proporciona los
elementos relacionados con los formularios, pero sólo de
una forma limitada. Específicamente, el Módulo de
Formulario Básico soporta los siguientes elementos,
atributos, y modelo de contenido mínimo:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| form |
Common, action* (URI), method
("get"* | "post"), enctype (ContentType) |
(Heading | List | Block - form)+ |
| input |
Common, accesskey (Character),
checked ("checked"), maxlength (Number), name (CDATA), size
(Number),
src (URI),
tabindex (Number), type ("text"* | "password"
| "checkbox" | "radio" | "submit" | "reset" | "hidden" ), value
(CDATA) |
EMPTY |
| label |
Common, accesskey (Character),
for (IDREF) |
(PCDATA | Inline - label)* |
| select |
Common, multiple
("multiple"), name (CDATA), size (Number),
tabindex (Number) |
option+ |
| option |
Common, selected
("selected"), value (CDATA) |
PCDATA |
| textarea |
Common, accesskey (Character),
cols* (Number), name (CDATA), rows*
(Number),
tabindex (Number) |
PCDATA |
Este módulo define dos grupos de contenido:
- Form
- form
- Formctrl
- input | label | select |
textarea
Cuando este módulo es usado, añade los
contenidos del Formulario al grupo de
contenidos de bloque del Módulo de Texto y
añade el contenido de los controles de Formulario -
Formctrl - al grupo de contenidos En Línea tal como
están definidos en el Módulo de Texto.
Implementación: DTD
5.5.2.
Módulo de Formulario
El Módulo de Formulario proporciona todas las
características de los formularios que se pueden encontrar
en HTML 4.0. Específicamente, el Módulo de
Formulario soporta:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| form |
Common, accept (ContentTypes), accept-charset
(Charsets), action* (URI), method
("get"* | "post"), enctype (ContentType) |
(Heading | List | Block - form | fieldset)+ |
| input |
Common, accept (ContentTypes), accesskey
(Character), alt (Text), checked
("checked"), disabled ("disabled"), maxlength (Number), name
(CDATA),
readonly ("readonly"), size (Number), src (URI), tabindex
(Number),
type ("text"* | "password" | "checkbox" | "button" | "radio" |
"submit" | "reset" | "file" | "hidden" | "image"), value (CDATA) |
EMPTY |
| select |
Common, disabled
("disabled"), multiple ("multiple"), name (CDATA), size
(Number),
tabindex (Number) |
(optgroup | option)+ |
| option |
Common, disabled
("disabled"), label (Text), selected ("selected"), value
(CDATA) |
PCDATA |
| textarea |
Common, accesskey (Character),
cols* (Number), disabled ("disabled"), name
(CDATA),
readonly ("readonly"), rows* (Number), tabindex (Number) |
PCDATA |
| button |
Common, accesskey (Character),
disabled ("disabled"), name (CDATA), tabindex (Number), type
("button" | "submit"* | "reset"), value (CDATA) |
(PCDATA | Heading | List | Block - Form | Inline -
Formctrl)* |
| fieldset |
Common |
(PCDATA | legend | Flow)* |
| label |
Common, accesskey (Character),
for (IDREF) |
(PCDATA | Inline - label)* |
| legend |
Common, accesskey (Character) |
(PCDATA | Inline)+ |
| optgroup |
Common, disabled
("disabled"), label* (Text) |
option+ |
Este módulo define dos grupos de contenido:
- Form
- form | fieldset
- Formctrl
- input | select | textarea | label |
button
Cuando este módulo es usado, añade los
contenidos del Formulario al grupo de
contenidos de bloque del Módulo de Texto y
añade el contenido de los controles de Formulario -
Formctrl - al grupo de contenidos En Línea tal como
están definidos en el Módulo de Texto.
El Módulo de Formulario es un superconjunto del
Módulo de Formulario Básico. Estos módulos
no deben ser usados juntos en un único tipo de
documento.
Implementación: DTD
5.6. Módulos de
Tablas
5.6.1. Módulo de Tablas
Básicas
El Módulo de Tablas Básicas proporciona
elementos relacionados con tablas, pero sólo de una forma
limitada. Específicamente, el Módulo de Tablas
Básicas soporta:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| caption |
Common |
(PCDATA | Inline)* |
| table |
Common , summary ( Text ), width (
Length
) |
caption?, tr+ |
| td |
Common, abbr (Text), align
("left" | "center" | "right"), axis (CDATA), colspan (Number), headers
(IDREFS),
rowspan (Number), scope ("row" | "col"),
valign ("top" | "middle" | "bottom") |
(PCDATA | Flow - table)* |
| th |
Common, abbr (Text), align
("left" | "center" | "right"), axis (CDATA), colspan (Number), headers
(IDREFS),
rowspan (Number), scope ("row" | "col" ),
valign ("top" | "middle" | "bottom") |
(PCDATA | Flow - table)* |
| tr |
Common, align ("left" |
"center" | "right"), valign ("top" | "middle" | "bottom") |
(td | th)+ |
Cuando este módulo es usado, añade el elemento
table al grupo de contenidos
de bloque del Módulo de Texto.
Implementación: DTD
5.6.2.
Módulo de Tablas
Como su nombre sugiere, el Módulo de Tablas proporciona
elementos relacionados con las tablas que son mejores para ser
accedidos mediante agentes de usuario no visuales.
Específicamente, el Módulo de Tablas soporta los
siguientes elementos, atributos, y modelos de contenido:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| caption |
Common |
(PCDATA | Inline)* |
| table |
Common, border (Pixels),
cellpadding (Length), cellspacing (Length),
datapagesize (CDATA), frame ("void" | "above" |
below" | "hsides" | "lhs" | "rhs" | "vsides" | "box" | "border"),
rules ("none" | "groups" | "rows" | "cols" | "all"), summary
(Text),
width (Length) |
caption?, ( col* | colgroup* ), (( thead?, tfoot?, tbody+ ) |
( tr+ )) |
| td |
Common, abbr (Text), align
("left" | "center" | "right" | "justify" | "char"), axis (CDATA), char
(Character), charoff (Length), colspan
(Number),
headers (IDREFS), rowspan (Number), scope
("row", "col", "rowgroup", "colgroup"), valign ("top" | "middle"
| "bottom" | "baseline") |
(PCDATA | Flow)* |
| th |
Common, abbr (Text), align
("left" | "center" | "right" | "justify" | "char"), axis (CDATA), char
(Character), charoff (Length), colspan
(Number),
headers (IDREFS), rowspan (Number), scope
("row", "col", "rowgroup", "colgroup"), valign ("top" | "middle"
| "bottom" | "baseline") |
(PCDATA | Flow)* |
| tr |
Common, align ("left" |
"center" | "right" | "justify", "char"), char (Character),
charoff (Length), valign ("top" | "middle" |
"bottom" | "baseline") |
(td | th)+ |
| col |
Common, align ("left" |
"center" | "right" | "justify", "char"), char (Character),
charoff (Length), span (Number), valign
("top" | "middle" | "bottom" | "baseline"), width (MultiLength) |
EMPTY |
| colgroup |
Common, align ("left" |
"center" | "right" | "justify", "char"), char (Character),
charoff (Length), span (Number), valign
("top" | "middle" | "bottom" | "baseline"), width (MultiLength) |
col* |
| tbody |
Common, align ("left" |
"center" | "right" | "justify", "char"), char (Character),
charoff (Length), valign ("top" | "middle" |
"bottom" | "baseline") |
tr+ |
| thead |
Common, align ("left" |
"center" | "right" | "justify", "char"), char (Character),
charoff (Length), valign ("top" | "middle" |
"bottom" | "baseline") |
tr+ |
| tfoot |
Common, align ("left" |
"center" | "right" | "justify", "char"), char (Character),
charoff (Length), valign ("top" | "middle" |
"bottom" | "baseline") |
tr+ |
Cuando este módulo es usado, añade el elemento
table al grupo de contenidos
de bloque del Módulo de Texto.
Implementación: DTD
5.7.
Módulo de Imagen
El Módulo de Imagen proporciona métodos para el
embebido básico de imágenes, y puede ser usado en
algunas implementaciones independientemente de mapas de imagen en
cliente. El Módulo de Imagen soporta los siguientes
elementos y atributos:
Cuando este módulo es usado, añade los
contenidos del elemento img al grupo de contenidos
En Línea del Módulo de Texto.
Implementación: DTD
5.8.
Módulo de Mapa de Imagen en el Lado-Cliente
El Módulo de Mapa de Imagen en el Lado-Cliente
proporciona elementos para mapas de imagen del lado cliente.
Requiere que el Módulo de Imagen (u otro módulo
que soporte el elemento img) esté incluido.
El Módulo de Mapa de Imagen en el Lado-Cliente soporta los
siguientes elementos:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
| a& |
coords (CDATA), shape ("rect" | "circle" |
"poly" | "default") |
n/a |
| area |
Common, accesskey (Character),
alt* (Text),
coords (CDATA), href (URI), nohref
("nohref"), shape ("rect"* | "circle" | "poly" | "default"),
tabindex (Number) |
EMPTY |
| img& |
usemap (IDREF) |
n/a |
| input& |
usemap (IDREF) |
n/a |
| map |
I18N, Events, class (NMTOKEN), id*
(ID), title
(CDATA) |
((Heading | Block) | area)+ |
| object& |
usemap (IDREF) |
Nota: Solamente cuando el módulo object está
incluido |
Cuando este módulo es usado, añade el elemento
map al grupo de contenidos En Línea del
Módulo de Texto.
Implementación: DTD
5.9.
Módulo de Mapa de Imagen en el Lado-Servidor
El Módulo de Mapa de Imagen en el Lado-Servidor
proporciona soporte para selección de imágenes y
transmisión de coordenadas de selección. Requiere
que el Módulo de Imagen (u otro módulo que soporte
el elemento img) esté incluido. El
Módulo de Mapa de Imagen en el Lado-Servidor soporta los
siguientes atributos:
| Elementos |
Atributos |
Modelo de Contenido Mínimo |
Notas |
| img& |
ismap ("ismap") |
n/a |
|
| input& |
ismap ("ismap") |
n/a |
Cuando el Módulo de Formulario o de Formulario
Básico está seleccionado. |
Implementación: DTD
5.10.
Módulo de Object
El Módulo Object proporciona elementos de
propósito general para la inclusión de objetos.
Específicamente, el Módulo