Esta especificación define un conjunto de objetos e interfaces para acceder y manipular objetos del documento. La funcionalidad especificada (la funcionalidad del Núcleo) es suficiente para permitir a los desarrolladores de software y autores de scripts de Webs acceder y manipular contenido HTML [HTML 4.01] y XML [XML 1.0] analizado dentro de productos conformes. El API del Núcleo del DOM permite también crear y poblar un objeto de un Documento
usando únicamente llamadas al API de DOM. Una solución para cargar un Documento
y almacenarlo continuamente se da en [Cargar y Guardar en DOM Nivel 3].
El DOM presenta los documentos como una jerarquía de objetos Node
(Nodos) que a su vez implementan otras interfaces más especializadas. Algunos tipos de nodos pueden tener nodos child (hijos) de varios tipos, y otros son nodos hoja que no pueden tener nada bajo ellos en la estructura del documento. Para XML y HTML, los tipos de nodos, y los tipos de nodos que estos pueden tener como hijos son los siguientes:
Document
-- Element
(uno como máximo),ProcessingInstruction
, Comment
,DocumentType
(uno como máximo)
DocumentFragment
-- Element
, ProcessingInstruction
, Comment
, Text
, CDATASection
, EntityReference
DocumentType
-- sin hijosEntityReference
-- Element
,
ProcessingInstruction
, Comment
,
Text
, CDATASection
,
EntityReference
Element
-- Element
, Text
,
Comment
, ProcessingInstruction
,
CDATASection
, EntityReference
Attr
-- Text
,
EntityReference
ProcessingInstruction
-- sin hijos
Comment
-- sin hijos
Text
-- sin hijos
CDATASection
-- sin hijos
Entity
-- Element
,
ProcessingInstruction
, Comment
,
Text
, CDATASection
,
EntityReference
Notation
-- sin hijos
El DOM especifica además una interfaz NodeList
para manejar listas ordenadas de Nodes
(Nodos), como los hijos de un Node
(Nodo), o los Elements (Elementos) devueltos por el método Element.getElementsByTagNameNS(URI espacios de nombres, Nombre local)
, y también una interfaz NamedNodeMap
para manejar listas no ordenadas de nodos referenciados por su atributo de nombre, como los atributos de un Element
(Elemento). En DOM, los objetos NodeList
y NamedNodeMap
están vivos, es decir, los cambios en la estructura subyacente del documento son reflejados en todos los objetos NodeList
y NamedNodeMap
relevantes. Por ejemplo, si un usuario del DOM obtiene un objeto NodeList
que contenga los hijos de un Element
, y a continuación añade más hijos a ese element (o los elimina, o modifica), estos cambios se reflejan automáticamente en el NodeList
, sin que el usuario tenga que realizar ninguna otra acción. Asimismo, los cambios de un Node
en el árbol se reflejan en todas las referencias a ese Node
desde los objetos NodeList
y NamedNodeMap
.
Finalmente, toda interfaz Text
, Comment
, y CDATASection
heredan del interfaz CharacterData
.
La mayoría de los APIs definidos por esta especificación son interfaces más que clases. Eso significa que una implementación concreta solo necesita exponer los métodos con los nombres definidos y la operación especificada, no implementar las clases que corresponden directamente a las interfaces. Esto permite que los APIs del DOM se implementen como una fina capa encima de aplicaciones antiguas con sus propias estructuras de datos, o encima de aplicaciones jerarquías de clases diferentes. Esto también significa que los constructores ordinarios (en el sentido de Java o C++) no pueden usarse para crear objetos del DOM, ya que los objetos subyacentes que deben ser construidos pueden tener muy poca relación con las interfaces del DOM. La solución convencional a esto en el diseño orientado a objetos es definir métodos constructores que creen ejemplares de objetos que implementen las diferentes interfaces. Los objetos que implementan una interfaz "X" se crean con un método "createX()" de la interfaz Document
; Esto es así porque todos los objetos del DOM habitan en el contexto de un documento específico.
Las APIs del Núcleo del DOM están diseñadas para ser compatibles con un amplio espectro de lenguajes, incluyendo tanto lenguajes de scripts de uso general como los lenguajes más complejos usados principalmente por programadores profesionales. Así, las APIs del DOM necesitan trabajar bajo distintas filosofías de gestión de memoria, desde plataformas de lenguaje que no exponen al usuario a la gestión de la memoria en absoluto, a aquellos (especialmente Java) que proporcionan constructores explícitos pero también un mecanismo de recogida automática de basura para reclamar la memoria libre, pasando por aquellas (especialmente C/C++) que generalmente exigen al programador que reserve explícitamente la memoria para el objeto, que controle dónde se usa, y que la libere explícitamente para su reutilización. Para asegurar que el API es consistente en todas las plataformas, el DOM no contempla en absoluto las cuestiones de gestión de memoria, sino que deja éstas a cada implementación. Ninguno de los enlaces explícitos para los lenguajes definidos por la API del DOM (para ECMAScript y Java) requieren de ningún método de gestión de memoria, pero los enlaces con el DOM que se crean para otros lenguajes (especialmente C o C++) probablemente necesitarán dicho soporte. Estas extensiones serán responsabilidad de aquellos que adapten el API del DOM a un lenguaje específico, no el Grupo de Trabajo de DOM.
Si bien sería deseable tener nombres de atributos y métodos que fueran cortos, informativos, con consistencia interna, y familiares para los usuarios de APIs similares, los nombres tampoco deberían entrar en conflicto con los nombres de APIs antiguas soportadas por las implementaciones del DOM. Además tanto el IDL del DMO (OMG) [OMG IDL] y ECMAScript [ECMAScript] tienen limitaciones significativas a la hora de eliminar las ambigüedades en los nombres provenientes de espacios de nombres (namespaces) diferentes, de modo que es difícil evitar conflictos con nombres cortos y familiares. Así, los nombres del DOM tienden a ser largos y bastante descriptivos con el fin de ser únicos en todas las plataformas.
El Grupo de Trabajo ha intentado también ser consistente internamente al usar los diferentes términos, incluso cuando en otras APIs ciertas distinciones pueden no ser comunes. Por ejemplo, la API de DOM utiliza el método de nombre "remove" ("quitar") cuando el método cambia el modelo estructural, y el método de nombre "delete" ("borrar") cuando el método suprime algo dentro del modelo estructural. La cosa que se borra no se devuelve. La cosa que se quita puede ser devuelta, cuando tenga sentido devolverla.
Las APIs del Núcleo del DOM presentan dos conjuntos un tanto diferentes de interfaces para un documento XML/HTML: uno presenta una aproximación "orientada a objetos" con una jerarquía de herencia, y una visión "simplificada" que permite que todas las manipulaciones se realicen a través de la interfaz Node
sin requerir interfaces de conversión (casts) (en Java o en otros lenguajes C) o interfaz de petición de llamadas en entornos COM. Estas operaciones son bastante costosas en Java y COM, y el DOM pude ser utilizado en entornos de rendimiento crítico, por lo que añadimos una funcionalidad significativa usando simplemente la interfaz Node
. Como muchos otros usuarios encontrarán la jerarquía hereditaria más fácil de entender que la aproximación de que en DOM "todo es un Node
", también soportamos las interfaces completas de alto nivel para aquellos que prefieran un API más orientado a objetos.
En la práctica, esto significa que hay una cierta carga de redundancia en el API. El Grupo de Trabajo considera que la aproximación "hereditaria" es la visión primaria del API, y que el conjunto completo de funcionalidades de Node
es un "extra" que los usuarios pueden emplear, pero que no elimina la necesidad de métodos que un análisis orientado a objetos consideraría necesario en otras interfaces. (Por supuesto, cuando el análisis orientado a objetos (O-O) conduce a un método que es idéntico a otro existente en la interfaz Node
, no especificamos uno completamente redundante). Así, aunque hay un atributo genérico Node.nodeName
(nodo.nombredenodo) en la interfaz Node
, sigue habiendo un atributo Element.tagName
en la interfaz Element
; ambos atributos deben contener el mismo valor, pero ellos consideran que vale la pena soportar ambos, dadas las diferentes exigencias que debe satisfacer la API del DOM.
Para asegurar la interoperatibilidad, esta especificación especifica los siguientes tipos básicos utilizados en varios módulos del DOM. Incluso aunque el DOM utiliza los tipos básicos en las interfaces, los enlaces pueden usar diferentes tipos y los enlaces normativos solo son dados para Java y ECMAScript en esta especificación.
DOMString
El tipo DOMString
se usa para almacenar caracteres [Unicode] como una secuencia de unidades de 16-bit usando UTF-16 como se define en [Unicode] y en la Enmienda 1 de [ISO/IEC 10646].
Los caracteres son normalizados totalmente como se define en el apéndice B de [XML 1.1] si:
true
(verdadero) mientras se carga el documento o el documento fuese certificado como se define en [XML 1.1];
true
(verdadero) mientras se utiliza el método Document.normalizeDocument()
, o mientras se utiliza el método Node.normalize()
;
Observe que, con excepción de Document.normalizeDocument()
y Node.normalize()
, en la manipulación de caracteres utilizando métodos DOM no se garantiza que se preserve un texto totalmente normalizado.
Un DOMString
es una secuencia de unidades de 16-bit.
valuetype DOMString sequence<unsigned short>;
La codificación UTF-16 fue elegida debido a su amplia extensión en programación. Observe que tanto para HTML y XML, el conjunto de caracteres del documento (y por lo tanto la notación de las referencias numéricas de caracteres) está basado en UCS [ISO/IEC 10646]. Una referencia a un carácter numérico simple en un documento fuente pude por lo tanto en algunos casos corresponder a dos unidades de 16-bit en un DOMString
(una sustitución de mayor peso y una sustitución de menor peso). Para cuestiones relacionadas con comparaciones de cadenas, dirigirse a Comparación de Cadenas en el DOM.
Para Java y ECMAScript, DOMString
está destinado al tipo Cadena
(String) porque ambos lenguajes utilizan también UTF-16 para su codificación.
Nota: En Agosto del 2000, la especificación OMG IDL ([OMG IDL]) incluyó el tipo wstring
. Sin embargo, esa definición no encontrón la interoperatibilidad con los criterios de la API del DOM ya que ello requiere de negociación para decidir el ancho y la codificación de un carácter.
DOMTimeStamp
El Tipo DOMTimeStamp
se utiliza para almacenar una fecha absoluta o relativa.
Un DOMTimeStamp
representa un número de milisegundos.
typedef unsigned long long DOMTimeStamp;
Para Java, DOMTimeStamp
está destinado al tipo
long
(largo). Para ECMAScript, DOMTimeStamp
está destinado al tipo Date
(Fecha) porque el rango del tipo integer
(entero) es más pequeño.
DOMUserData
El tipo DOMUserData
se utiliza para almacenar datos de la aplicación.
Un DOMUserData
representa una referencia a un dato de la aplicación.
typedef any DOMUserData;
Para Java, DOMUserData
está destinado al tipo
Object
(objeto). Para ECMAScript, DOMUserData
está destinado al tipo any type
(cualquier tipo).
EL DOM tiene muchas interfaces que implican un emparejamiento de cadenas. Para XML, la comparación de cadenas son sensibles a mayúsculas y minúsculas (case-sensitive) y realizadas con una comparación binaria de las unidades de 16-bit del DOMStrings
. Sin embargo, para lenguajes insensibles a mayúsculas y minúsculas (case-insensitive), como HTML 4.01 o anteriores, estas comparaciones son insensibles a mayúsculas y minúsculas (case-insensitive) son apropiadas.
Observe que los procesadores HTML a menudo realizan una normalización de marcas en mayúsculas (con menor frecuencia en minúsculas) después de que la estructura del DOM sea construida. Este típicamente utiliza las mayúsculas para los nombres de element (elementos) y las minúsculas para los nombres de atributos. Por esta razón, las aplicaciones deben también comparar los nombres de elementos y atributos devueltos por la implementación DOM de una manera insensible a mayúsculas y minúsculas (case-insensitive).
La normalización del carácter, es decir, la transformación en su forma totalmente normalizada como se define en [XML 1.1], es asumida para pasarla en tiempo de serialización. El módulo del DOM Nivel 3 Cargar y Guardar [DOM Nivel 3 Cargar y Guardar] proporciona un mecanismo de serialización. (ver la interfaz DOMSerializer
, sección 2.3.1) y utiliza los parámetros de DOMConfiguration
"normalize-characters" (normalizar caracteres) y "check-character-normalion " (test de normalización de caracteres) para asegurar que el texto es totalmente normalizado [XML 1.1]. Otros mecanismos de serialización construidos sobre el Núcleo del DOM Nivel 3 tienen que asegurar que el texto es totalmente normalizado.
La especificación DOM confía en los valores DOMString
como identificadores de recursos, tal que se cumplan las siguientes condiciones:
El termino "URI absoluta" se refiere a un identificador de recurso completo y el termino "URI relativa" se refiere a un identificador de recuro incompleto.
Dentro de las especificaciones del DOM, estos identificadores son denominados URIs, "Uniform Resource Identifiers" (Identificadores de Recurso Uniformes), pero esto es en sentido absoluto. La implementación del DOM no procesa necesariamente estas URIs conforme a la especificación del URI [IETF RFC 2396]. Generalmente la forma particular de estos identificadores debe ser ignorada.
Cuando no es posible ignorar completamente el tipo de un URI del DOM, debido a que un identificador relativo tiene que ser pasado a absoluto o porque el contenido debe ser recuperado, la implementación del DOM debe al menos soportar tipos de identificadores apropiados para procesar el contenido. [HTML 4.01], [XML 1.0], y la especificación de espacio de nombre (namespace) asociados [Espacios de Nombres XML] sostenidos sobre [IETF RFC 2396] determinan caracteres permitidos y resuelven las URIs relativas. Otras especificaciones tales como espacios de nombre (namespaces) en XML [Espacios de Nombres XML 1.1] pueden confiar en la alternativa de tipos de identificadores de recursos que pueden, por ejemplo, incluir caracteres no ASCII (non-ASCII), necesitando apoyo para los tipos de identificadores de recursos alternativos donde sea requerido por la especificación aplicable.
DOM Nivel 2 y 3 soportan espacios de nombres XML [Espacio de Nombres XML] mediante el aumento de varios interfaces del Núcleo del DOM Nivel 1 para permitir crear y manipular elementos y atributos asociados a los espacios de nombre. Cuando [XML 1.1] está en uso (vea Document.xmlVersion
), el DOM Nivel 3 también soporta
[Espacios de Nombres XML 1.1].
DOM está preocupado, por los atributos especiales utilizados para la declaración de espacios de nombres XML que aun son expuestos y pueden ser manipulados justamente como cualquier otro atributo. Sin embargo, los nodos permanentemente son enlazados a URIs de espacios de nombre cuando son creados. Consecuentemente, mover un nodo dentro de un documento, usando un prefijo de espacio de nombre DOM o un URI espacio de nombre. Asimismo, creando un nodo con un prefijo espacio de nombre y URI espacio de nombre, o cambiando el prefijo espacio de nombre o el nodo, no termina en una adición, retirada o modificación de cualquier atributo especial para declarar espacios de nombres apropiados en XML. La validación de espacios de nombre no se cumple; la aplicación DOM es la responsable. En particular, ya que el mapeo entre prefijos y URIs de espacios de nombre no se cumple, el resultado del documento no puede ser ingenuamente seriado. Por ejemplo, las aplicaciones deberían declarar cada espacio de nombre en uso cuando un documento es serializado.
En general, la implementación del DOM (y superiores) no realizan ninguna normalización o conversión (canonicalización) del URI. Los URIs dados a DOM son asumidos para ser validos (Ej., caracteres como espacios en blanco son escapados/evitados correctamente), y no se realiza ninguna comprobación léxica. Las referencias absolutas de URI son tratadas como cadenas y comparadas literalmente. Las referencias a URIs de espacios de nombres relativas son tratadas como indefinidas. Para asegurar la interoperatibilidad solo se deberían utilizar las referencias de URI de espacios de nombres absolutas (es decir, referencias URI que empiezan con un nombre de esquema y dos puntos). Las aplicaciones deberían utilizar el valor null (nulo)
como el parámetro de namespaceURI
para los métodos que no desean tener ningún espacio de nombre. En lenguajes de programación donde las cadenas vacías pueden ser diferentes a nulo (null), las cadenas vacías, cuando son dadas como un URI de espacio de nombre, son convertidas a null
. Esto es verdadero aun cuando DOM no haga ninguna comprobación léxica de URIs.
Nota: Element.setAttributeNS(null, ...)
pone el atributo en la partición por tipo de elemento como se define en Particiones de Espacio de Nombres XML en [Espacios de Nombres XML].
Nota: En el DOM, todos los atributos de espacio de nombre declarados están por definición atados al URI de espacio de nombre: "http://www.w3.org/2000/xmlns/". Estos son los atributos cuyo prefijo de espacio de nombre o nombre cualificado es "xmlns" como se presenta en [Espacios de Nombres XML 1.1].
En un documento sin espacios de nombres, la lista hija de una Referencia de Entidad
de un nodo es siempre la misma que la corresponde a la Entidad
. Esto no es verdadero en un documento donde una entidad contiene a prefijos de espacio de nombre sin vincular. En tal caso, el descendente de la correspondiente Referencia de Entidad
de nodos puede ser atado a diferentes URIs de espacio de nombre, dependiendo de donde sean las referencias de entidad. También, porque, en el DOM, los nodos siempre permanecen vinculados al mismo URI de espacio de nombre, moviendo la Referencia de Entidad
los nodos pueden llevar a documentos que no puedan ser serializados. Esto es verdad cuando el método Document.createEntityReference(name)
se utiliza para crear referencias de entidades que correspondan a tales identidades, donde los descendentes devueltos de la (EntityReference) Referencia de Entidad
no est6acute;n vinculados. Mientras DOM Nivel 3 tiene soporte para la resolución de prefijos de espacios de nombres, el uso de tales entidades y referencias de entidad deberían ser evitados o utilizarse en caso extremo.
Los métodos "NS" (NameSpace - Espacio de Nombre), tales como Document.createElementNS(namespaceURI, qualifiedName)
y Document.createAttributeNS(namespaceURI, qualifiedName)
, son propuestos para ser utilizados por aplicaciones de espacio de nombre consistentes. Las aplicaciones simples que no utilizan espacios de nombres pueden utilizar los métodos del DOM Nivel 1, tales como Document.createElement(tagName)
y Document.createAttribute(name)
. Los elementos y atributos creados por este sistema no tienen ningún prefijo de espacio de nombre, URI de espacio de nombre, o nombre local.
Nota: Los métodos de espacios de nombre del DOM Nivel 1 son ignorados. Por lo tanto, mientras que por fuerza se utilizan estos métodos cuando no se trata con espacios de nombres, la utilización de estos y los nuevos al mismo tiempo deberían ser evitados. Los métodos de DOM Nivel 1 únicamente identifican nodos de atributos para su Node.nodeName
. Al contrario, los métodos del DOM Nivel 2 relacionados con espacios de nombres, identifican nodos de atributos para su Node.namespaceURI
y Node.localName
. Por esta diferencia fundamental, mezclar ambos conjuntos de métodos puede conducir a resultados imprevisibles. En particular, utilizando Element.setAttributeNS(URI espacio de nombre, Nombre cualificado, valor)
, un elemento (element) puede tener dos atributos (o más) que tengan el mismo Node.nodeName
, pero diferente Node.namespaceURI
s. Llamando a Element.getAttribute(nombre)
con ese nodeName
podría entonces devolver cualquiera de esos atributos. El resultado depende de la implementación. Igualmente, utilizando Element.setAttributeNode(nuevo atributo)
, uno puede obtener dos atributos (o más) que tengan diferente Node.nodeName
s pero el mismo Node.prefix
y Node.namespaceURI
. En este caso Element.getAttributeNodeNS(URI espacio de nombre, Nombre local)
devolverá uno u otro atributo, dependiendo de la implementación. La única garantía en tales casos es que todos los métodos que tienen acceso a un elemento llamado por su nodeName
accederá al mismo elemento, y todos los métodos que acceden a un nodo (node) por su URI y nombre local (localname) accederá al mismo nodo. Por ejemplo, Element.setAttribute(nombre, valor)
y Element.setAttributeNS(URI espacio de nombre, Nombre cualificado, valor)
afectan al nodo devuelto igual que Element.getAttribute(nombre)
y Element.getAttributeNS(URI espacio de nombre, Nombre local)
, respectivamente.
El DOM Nivel 3 añade soporte para la propiedad [URI Base] definida en [Conjunto de Información XML] para proporcionar un nuevo atributo sobre la interfaz del Nodo
que expone esta información. Sin embargo, a diferencia del atributo Node.namespaceURI
, el atributo Node.baseURI
no es una pieza estática de la información que cada nodo lleva. En cambio, este es un valor que dinámicamente es calculado de acuerdo a [Base XML]. Esto significa que este valor depende de la localización del nodo en el árbol y moverlo de un lugar a otro en el árbol puede afectar a su valor. Otros cambios, como agregar o cambiar un atributo xml:base
en un nodo que es preguntado o de uno de sus ascendentes puede también afectar a su valor.
Una consecuencia de esto es que cuando referencias de entidad externa son expandidas en la construcción del Documento
uno puede tener que añadir, o modificar, un atributo xml:base al Elemento
de los nodos al principio del contenido en la entidad que será expandida para que el Node.baseURI
devuelva el valor correcto. En el caso de Instrucción de Procesado
de los nodos originales contenidos en la entidad que será expandida perderán la información. [DOM Nivel 3 Cargar y Guardar] mantiene elementos aquí descritos y generan una advertencia en el último caso.
Como nuevos vocabularios de XML son desarrollados, para estas definiciones de vocabularios se está empezando también a definir APIs especializadas para manipular las instancias XML de estos vocabularios. Esto generalmente está hecho por la ampliación del DOM que proporciona interfaces y métodos que realizan operaciones frecuentemente necesarias para sus usuarios. Por ejemplo, las especificaciones MathML (funciones matemáticas) [MathML 2.0] y SVG [SVG 1.1] han desarrollado extensiones DOM para permitir a los usuarios manipular los casos de esos vocabularios usando la semántica apropiada para matemáticas e imágenes, respectivamente, así como la semántica genérica del DOM XML. Los casos de SVG y MathML a menudo son embebidos en los Documentos XML conformados de forma diferente a XHTML.
Mientras que los Espacios de Nombres (Namespaces) en la especificación de XML [Espacios de Nombres XML] proporcionan mecanismos para integrar estos documentos a nivel de sintaxis, está claro que la Recomendación DOM Nivel 2 [Núcleo del DOM Nivel 2] no es bastante rico para cubrir todas las cuestiones que se han encontrado haciendo estas diferentes implementaciones DOM siendo utilizadas juntas en una sola aplicación. DOM Nivel 3 trata con las exigencias causadas por fragmentos embebidos escritos según lenguajes de marcas específicos (el componente embebido) en un documento donde el resto de marcas no se escriben según a al lenguaje de marcas especifico (el documento anfitrión). Este no trata con fragmentos embebidos por referencias o unión.
Una implementación DOM que soporta el Núcleo del DOM Nivel 3 deberá ser capaz de colaborar con subcomponentes que implementen DOMs específicos para ensamblar un documento compuesto que puede ser leído y manipulado vía interfaces de DOM como si esto fuese un todo.
La operación normal de tipo de conversión (typecast) sobre un objeto debería soportar las interfaces esperadas por el código heredado para un tipo de documento dado. Las técnicas de conversión de tipos (Typecasting) pueden no ser adecuadas para la selección entre múltiples especificaciones de DOM de un objeto el cual fue combinado en tiempo de ejecución, porque todos estos no pueden ser parte del mismo objeto que se definió por el modelo de objetos de enlace. Los conflictos son los más obvios con el objeto Documento
, ya que este es compartido como propietario por el resto del documento. En un documento homogéneo, los elementos confían en el documento para servicios especializados y construcción de nodos especializados. En un documento heterogéneo, los elementos de diferentes módulos esperan servicios diferentes y APis del mismo objeto del Documento
, ya que solo puede haber un dueño y una raí en la jerarquía del documento.
Cada módulo DOM define una o más funcionalidades, listadas en la sección de conformidad (Conformidad). Las funcionalidades son insensibles a mayúsculas y minúsculas (case-insensitive) y son definidas también por un conjunto específico de versiones. Por ejemplo, esta especificación define las funcionalidades "Núcleo"
y "XML"
, para la versión "3.0"
. Las versiones "1.0"
y "2.0"
pueden ser utilizadas también para definir las funcionalidades en el correspondiente nivel de DOM. Para evitar posibles conflictos, por convención los nombres referidos a funcionalidades definidos fuera de la especificación DOM deberían hacerse únicos. Las aplicaciones entonces podrían requerir para las funcionalidades que sean soportados por una implementación DOM utilizando los métodos DOMImplementationSource.getDOMImplementation(funcionalidades)
o DOMImplementationSource.getDOMImplementationList(funcionalidades)
, comprueba las funcionalidades soportados por una implementación DOM usando el método DOMImplementation.hasFeature(funcionalidad, versión)
, o por un nodo especificado utilizando Node.isSupported(funcionalidad, versión)
. Observe que cuando se utilizan los métodos que toman una funcionalidad y una versión como parámetros, las aplicaciones pueden usar null
(nulo) o una cadena vacía para el parámetro versión si no desean especificar una versión en particular para la funcionalidad especificada.
Hasta los módulos de DOM Nivel 2, todas las interfaces, que eran una extensión de otra existente, era accesible utilizando modelos de mecanismos de enlaces específicos si la funcionalidad asociada a la extensión era soportada. Por ejemplo, un caso de interfaz EventTarget
podría ser obtenido desde una interfaz del Nodo
si la funcionalidad "Events" era soportada por el nodo.
Como se comento en implementaciones Mixtas del DOM, el Núcleo del DOM Nivel 3 debería ser capaz de colaborar con subcomponentes específicos DOMs implementados. Para ese efecto, se introdujeron los métodos DOMImplementation.getFeature(funcionalidad, versión)
y Node.getFeature(funcionalidad, versión)
. En el caso de DOMImplementation.hasFeature(funcionalidad, versión)
y Node.isSupported(funcionalidad, versión)
, si un signo más "+" precede a cualquier nombre de funcionalidad, las implementaciones están considerando que la funcionalidad especificada no puede ser convertida directamente pero requiere el descubrimiento por DOMImplementation.getFeature(funcionalidad, versión)
y Node.getFeature(funcionalidad, versión)
. Sin el más, solo son consideradas las funcionalidades cuyas interfaces son convertibles directamente.
// ejemplo 1, sin precedencia del "+" if (myNode.isSupported("Events", "3.0")) { EventTarget evt = (EventTarget) myNode; // ... } // ejemplo 2, con el "+" if (myNode.isSupported("+Events", "3.0")) { // (el signo más "+" es irrelevante para el método getFeature en sí mismo // y es ignorado por este método de todos modos) EventTarget evt = (EventTarget) myNode.getFeature("Events", "3.0"); // ... }
Como las versiones anteriores de la especificación del DOM solo definieron un conjunto de interfaces, las aplicaciones tuvieron que confiar en algunas implementaciones dependientes del código en un principio. Sin embargo, la codificación estricta de la aplicación en una implementación específica impide que la aplicación funcione en otras implementaciones y que se utilice la implementación más conveniente disponible. Al mismo tiempo, las implementaciones también pueden necesitar cargar módulos o realizar otras instalaciones para adaptarse eficientemente a un conjunto de carácterísticas/funcionalidades diferentes y a veces mutuamente excluyentes.
Para solucionar estos problemas esta especificación presenta un objeto DOMImplementationRegistry
con una función que deja que una aplicación encuentre implementaciones, basadas en las carácterísticas/funcionalidades específicas que esta requiere. Como se encuentra este objeto y a que se parece exactamente no se define aquí, porque esto no puede ser realizado en un lenguaje de manera independiente. En cambio, cada lenguaje vinculado define su propia forma de hacer esto. Vea Vínculo con el Lenguaje Java y Vínculo con el Lenguaje ECMAScript para las especificaciones.
En todos los casos, aunque, el DOMImplementationRegistry
proporciona un método getDOMImplementation
que acepta una cadena de funcionalidades, que es pasada a cada DOMImplementationSource
conocido hasta que un DOMImplementation
adecuado sea encontrado y devuelto. El DOMImplementationRegistry
también proporciona un método getDOMImplementationList
que acepta una cadena de funcionalidades, que es pasada a cada DOMImplementationSource
conocido, y devuelve una lista de DOMImplementations
adecuados. Estos dos métodos son iguales que los encontrados en la interfaz DOMImplementationSource
.
Cualquier número de objetos DOMImplementationSource
pueden ser registrados. Una fuente pude devolver uno o más DOMImplementation
únicos (singletons) o construir objetos DOMImplementation
, dependiendo según de si la funcionalidad requiere un estado específico en el objeto DOMImplementation
.
Las interfaces dentro de esta sección son consideradas fundamentales, y debe ser completamente implementado para todas las implementaciones con conformidad del DOM, incluyendo todas las implementaciones DOM HTML [HTML DOM Nivel 2], a menos que no sea especificado.
Una aplicación DOM debe utilizar el método DOMImplementation.hasFeature(funcionalidad, versión)
con los valores de Parámetros "Core" (Núcleo) y "3.0" (respectivamente) para determinar si este módulo es o no realmente soportado por la implementación. Cualquier aplicación con conformidad a DOM Nivel 3 o módulo del DOM Nivel 3 debe conformarse al módulo Núcleo. Por favor referirse a conformidad para más información en esta misma especificación. El módulo del Núcleo del DOM Nivel 3 es compatible con el módulo del Núcleo del DOM Nivel 2 [Núcleo del DOM Nivel 2], es decir, una implementación con el Núcleo DOM Nivel 3 que devuelve verdadero
con el número de versión
"3.0"
debe también devolver verdadero
para esta funcionalidad
cuando el número de versión
es "2.0"
, ""
o, null
(nulo).
Las operaciones del DOM sólo provocan excepciones en circunstancias "excepcionales", es decir, cuando una operación es imposible de realizar (también por razones lógicas, porque se pierden datos, o porque la implementación se vuelve inestable). En general, los métodos del DOM devuelven valores de error específico en situaciones ordinarias de procesamiento, tales como errores de exceso de rango al utilizar NodeList
.
Las implementaciones deben provocar otras excepciones bajo otras circunstancias. Por ejemplo, las implementaciones deben provocar una excepción dependiendo de la implementación si se pasa un argumento null
cuando null
no era esperado.
Algunos lenguajes y sistemas de objetivo no soportan el concepto de excepción. Para tales sistemas, las condiciones de error pueden ser indicadas utilizando mecanismos de información de errores nativos. Para algunos vinculados, por ejemplo, los métodos pueden devolver códigos de error similares los enumerados en las descripciones de los métodos correspondientes.
Excepción DOMException { unsigned short code; }; // ExceptionCode (Código de Excepción) const unsigned short INDEX_SIZE_ERR = 1; const unsigned short DOMSTRING_SIZE_ERR = 2; const unsigned short HIERARCHY_REQUEST_ERR = 3; const unsigned short WRONG_DOCUMENT_ERR = 4; const unsigned short INVALID_CHARACTER_ERR = 5; const unsigned short NO_DATA_ALLOWED_ERR = 6; const unsigned short NO_MODIFICATION_ALLOWED_ERR = 7; const unsigned short NOT_FOUND_ERR = 8; const unsigned short NOT_SUPPORTED_ERR = 9; const unsigned short INUSE_ATTRIBUTE_ERR = 10; // Introducido en DOM Nivel 2: const unsigned short INVALID_STATE_ERR = 11; // Presentado en DOM Nivel 2: const unsigned short SYNTAX_ERR = 12; // Introducido en DOM Nivel 2: const unsigned short INVALID_MODIFICATION_ERR = 13; // Introducido en DOM Nivel 2: const unsigned short NAMESPACE_ERR = 14; // Introducido en DOM Nivel 2: const unsigned short INVALID_ACCESS_ERR = 15; // Introducido en DOM Nivel 3: const unsigned short VALIDATION_ERR = 16; // Introducido en DOM Nivel 3: const unsigned short TYPE_MISMATCH_ERR = 17;
Un entero que indica el tipo de error generado.
Nota: Otros códigos numéricos son reservados por W3C para posibles usos futuros.
DOMSTRING_SIZE_ERR
DOMString
.
HIERARCHY_REQUEST_ERR
Nodo
es insertado en algún sitio al que no pertenece.
INDEX_SIZE_ERR
INUSE_ATTRIBUTE_ERR
INVALID_ACCESS_ERR
, introducido en DOM Nivel 2.INVALID_CHARACTER_ERR
INVALID_MODIFICATION_ERR
, introducido en DOM Nivel 2.INVALID_STATE_ERR
, introducido en DOM Nivel 2.NAMESPACE_ERR
, introducido en DOM Nivel 2.NOT_FOUND_ERR
Nodo
en un contexto en el que no existe.
NOT_SUPPORTED_ERR
NO_DATA_ALLOWED_ERR
Nodo
que no soporta datos.
NO_MODIFICATION_ALLOWED_ERR
SYNTAX_ERR
, introducido en DOM Nivel 2.TYPE_MISMATCH_ERR
, introducido en DOM Nivel 3.VALIDATION_ERR
, introducido en DOM Nivel 3.insertBefore
o removeChild
hiciera al Nodo
no válido con respecto a una "validez parcial", esta excepción sería provocada y la operación no se realizaría. Este código es usado en [Validación del DOM Nivel 3]. Vea está especificación para información adicional.
WRONG_DOCUMENT_ERR
Nodo
es usado en un documento diferente del que lo creó (que no lo soporte).
La interfaz DOMStringList
proporciona la abstracción de un conjunto ordenado de valores DOMString
, sin definir o restringir como se implementa este conjunto. Los elementos (items) en el DOMStringList
son accesibles por un índice entero que empieza en el 0.
// Introducido en DOM Nivel 3: interfaz DOMStringList { DOMString item(in unsigned long index); readonly attribute unsigned long length; boolean contains(in DOMString str); };
contains
DOMStringList
.
str
of type
DOMString
|
|
item
index
th. Si index
es mayor o igual que el número de DOMString
s en la lista, esto devuelve null
(nulo).
index
of type unsigned long
La interfaz NameList
proporciona la abstracción de un conjunto ordenado de pares paralelos de valores de nombre y espacio de nombre (que podrían ser valores nulos), sin definir o establecer como se implementa este conjunto. Los elementos en el NameList
son accesibles por un índice entero, comenzando desde 0.
// Introducido en DOM Nivel 3: interfaz NameList { DOMString getName(in unsigned long index); DOMString getNamespaceURI(in unsigned long index); readonly attribute unsigned long length; boolean contains(in DOMString str); boolean containsNS(in DOMString namespaceURI, in DOMString name); };
length
of type unsigned long
, readonlylength-1
ambos inclusive.
contains
NameList
.
str
of type DOMString
|
|
containsNS
NameList
.
|
|
getName
index
th en el conjunto.
index
of type unsigned long
El nombre de la posición |
getNamespaceURI
index
th en el conjunto.
index
of type unsigned long
El URI de espacio de nombre en la posición |
La interfaz DOMImplementationList
proporciona la abstracción de un conjunto ordenado de implementaciones DOM, sin definir o establecer como es implementado este conjunto. Los elementos en el DOMImplementationList
son accesibles por un índice entero, comenzando desde 0.
// Introducido en DOM Nivel 3: interfaz DOMImplementationList { DOMImplementation item(in unsigned long index); readonly attribute unsigned long length; };
length
of type unsigned long
, readonlyDOMImplementation
s (implementaciones DOM) en la lista. El rango de índices validos de nodos hijos va desde 0 a length-1
ambos inclusive.
item
index
th en el conjunto. Si index
es mayor o igual que el número de DOMImplementation
s en la lista, este devuelve null
.
index
of type unsigned long
El |
Esta interfaz permite a DOM implementar soporte de una o más implementaciones, basado en rasgos de funcionalidades requeridas y versiones, como se especificó en Funcionalidades del DOM. Cada objeto DOMImplementationSource
implementado es listado en la lista de enlace específica de fuentes disponibles para que sus objetos DOMImplementation
estén disponibles.
// Introducido en DOM Nivel 3: interfaz DOMImplementationSource { DOMImplementation getDOMImplementation(in DOMString features); DOMImplementationList getDOMImplementationList(in DOMString features); };
getDOMImplementation
features
of type DOMString
getDOMImplementationList
.
"XML 3.0 Traversal +Events 2.0"
solicitará una implementación DOM que soporte el módulo "XML" para su versión 3.0, un módulo que soporte el módulo "Traversal" para cualquier versión, y el módulo "Events" para su versión 2.0. El módulo "Events" debe ser accesible utilizando el método Node.getFeature()
y DOMImplementation.getFeature()
.
La primera implementación DOM que soporte las funcionalidades designadas, o |
getDOMImplementationList
features
of type DOMString
Una lista de implementaciones DOM que soportan las funcionalidades deseadas. |
La interfaz DOMImplementation
proporciona un conjunto de métodos para realizar operaciones que son independientes de cualquier ejemplo particular del modelo de objetos del documento.
interfaz DOMImplementation { boolean hasFeature(in DOMString feature, in DOMString version); // Introducido en DOM Nivel 2: DocumentType createDocumentType(in DOMString qualifiedName, in DOMString publicId, in DOMString systemId) raises(DOMException); // Introducido en DOM Nivel 2: Document createDocument(in DOMString namespaceURI, in DOMString qualifiedName, in DocumentType doctype) raises(DOMException); // Introducido en DOM Nivel 3: DOMObject getFeature(in DOMString feature, in DOMString version); };
createDocument
introducido en DOM Nivel 2DocumentType
dado para crear el documento, la implementación puede concretar que objetos Document
soportan funcionalidades adicionales en el "Núcleo", como "HTML" [HTML DOM Nivel 2]. De otra parte, poniendo el DocumentType
después de que el documento fuese creado hace que esto sea muy poco probable de que ocurra. Alternativamente, los métodos de creación Document
especificados, como createHTMLDocument
[HTML DOM Nivel 2], pueden ser usados para obtener los tipos específicos de objetos Document
.
namespaceURI
of type DOMString
null
.
qualifiedName
of type DOMString
null
.doctype
of type DocumentType
null
.doctype
no es null
, su atributo Node.ownerDocument
se pone al documento que está siendo creado.
INVALID_CHARACTER_ERR: provocada si el nombre cualificado especificado no es un nombre XML de acuerdo con [XML 1.0].
NAMESPACE_ERR: provocada si el
WRONG_DOCUMENT_ERR: provocada si NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad "XML" y el lenguaje expuesto por el documento no soporta Espacios de Nombres XML (tal como [HTML 4.01]). |
createDocumentType
introducido en DOM Nivel 2DocumentType
vacío. Las declaraciones de entidad y las notaciones no están disponibles. Las extensiones de entidades de referencia y los atributos adicionales predefinidos no ocurren.
qualifiedName
of type DOMString
publicId
of type DOMString
systemId
of type DOMString
Un nuevo nodo |
INVALID_CHARACTER_ERR: provocada si el nombre cualificado especificado no es un nombre XML de acuerdo con [XML 1.0]. NAMESPACE_ERR: provocada si NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad "XML y el lenguaje expuesto por el documento no soporta Espacios de Nombres de XML (como [HTML 4.01]). |
getFeature
introducido en DOM Nivel 3DOMImplementation
.
Devuelve un objeto que implementa las APIs especializadas de la funcionalidad y versión especificadas, si lo hay, o |
hasFeature
|
|
DocumentFragment
es un objeto Document
"aligerado" o "mínimo". Es muy común querer extraer una porción del árbol de un documento o crear un nuevo fragmento de un documento. Imaginemos la implementación de un comando de usuario como cortar o reordenar un documento moviendo fragmentos. Es deseable tener un objeto que pueda contener dichos fragmentos y resulta bastante natural utilizar para este fin un Nodo. Si bien es cierto que un objeto Document
podría realizar este papel, un objeto Document
pude ser potencialmente un objeto pesado, dependiendo de la implementación subyacente. Lo que en realidad se necesita para esto es un objeto muy ligero. DocumentFragment
es este objeto.
Además, ciertas operaciones -- tales como insertar nodos como hijos de otro Node
-- pueden tomar objetos DocumentFragment
como argumentos; esto hace que todos los nodos hijo del DocumentFragment
sean movidos a la lista de hijos de este nodo.
Los hijos de un nodo DocumentFragment
son cero o más nodos que representan las partes superiores de un número de sub-árboles que definen la estructura del documento. Los nodos DocumentFragment
no necesitan ser documentos XML bien formados (aunque necesitan seguir las reglas impuestas sobre entidades analizadas XML bien formadas, las cuales pueden tener múltiples nodos superiores). Por ejemplo, un DocumentFragment
podría tener un único hijo y ese nodo hijo podrí ser un nodo Text
. Este modelo de estructura no representaría ni a un documento HTML ni a un documento XML bien formado.
Cuando un DocumentFragment
es insertado dentro de un Document
(o en cualquier otro Node
que pueda tener hijos) los hijos del DocumentFragment
y no el DocumentFragment
son insertados en el Node
. Esto hace que DocumentFragment
sea muy útil cuando el usuario quiere crear nodos que sean hermanos; el DocumentFragment
actúa como el padre de estos nodos de modo tal que el usuario puede usar los métodos estándar de la interfaz Node
, como por ejemplo Node.insertBefore
("insertar Antes") y Node.appendChild
("insertar Hijo").
interfaz DocumentFragment : Node { };
La interfaz Document
representa el documento HTML o XML completo. Conceptualmente, es la raíz del árbol del documento, y proporciona el acceso primario a los datos del documento.
Como los elementos, nodos de texto, comentarios, instrucciones de procesamiento, etc., no pueden existir fuera del contexto de un Document
, la interfaz Document
también contiene los métodos constructores necesarios para crear estos objetos. Los objetos Node
creados tienen un atributo ownerDocument
que los asocia con el Document
dentro de cuyo contexto fueron creados.
interfaz Document : Node { // Modificado en DOM Nivel 3: readonly attribute DocumentType doctype; readonly attribute DOMImplementation implementation; readonly attribute Element documentElement; Element createElement(in DOMString tagName) raises(DOMException); DocumentFragment createDocumentFragment(); Text createTextNode(in DOMString data); Comment createComment(in DOMString data); CDATASection createCDATASection(in DOMString data) raises(DOMException); ProcessingInstruction createProcessingInstruction(in DOMString target, in DOMString data) raises(DOMException); Attr createAttribute(in DOMString name) raises(DOMException); EntityReference createEntityReference(in DOMString name) raises(DOMException); NodeList getElementsByTagName(in DOMString tagname); // Introducido en DOM Nivel 2: Node importNode(in Node importedNode, in boolean deep) raises(DOMException); // Introducido en DOM Nivel 2: Element createElementNS(in DOMString namespaceURI, in DOMString qualifiedName) raises(DOMException); // Introducido en DOM Nivel 2: Attr createAttributeNS(in DOMString namespaceURI, in DOMString qualifiedName) raises(DOMException); // Introducido en DOM Nivel 2: NodeList getElementsByTagNameNS(in DOMString namespaceURI, in DOMString localName); // Introducido en DOM Nivel 2: Element getElementById(in DOMString elementId); // Introducido en DOM Nivel 3: readonly attribute DOMString inputEncoding; // Introducido en DOM Nivel 3: readonly attribute DOMString xmlEncoding; // Introducido en DOM Nivel 3: attribute boolean xmlStandalone; // raises(DOMException) on setting // Introducido en DOM Nivel 3: attribute DOMString xmlVersion; // raises(DOMException) on setting // Introducido en DOM Nivel 3: attribute boolean strictErrorChecking; // Introducido en DOM Nivel 3: attribute DOMString documentURI; // Introducido en DOM Nivel 3: Node adoptNode(in Node source) raises(DOMException); // Introducido en DOM Nivel 3: readonly attribute DOMConfiguration domConfig; // Introducido en DOM Nivel 3: void normalizeDocument(); // Introducido en DOM Nivel 3: Node renameNode(in Node n, in DOMString namespaceURI, in DOMString qualifiedName) raises(DOMException); };
doctype
of type DocumentType
, readonly, modificado en DOM Nivel 3DocumentType
) asociada con este documento. Para documentos XML sin una declaración del tipo de documento esto devuelve null
. Para documentos HTML, un objeto DocumentType
puede ser devuelto, independientemente de la presencia o ausencia de la declaración del tipo de documento en el documento HTML.
DocumentType
, al nodo hijo de este Document
. Este nodo puede ser fijado al tiempo que se crea el documento y cambiado posteriormente usando métodos de manipulación de nodos hijos, tales como Node.insertBefore
, o Node.replaceChild
. Observe, sin embargo, que mientras unas implementaciones pueden instanciar diferentes tipos de objeto Document
soportando funcionalidades adicionales que las del "Núcleo", como "HTML" [DOM Level 2 HTML], basado en el DocumentType
especificado en tiempo de creación, cambiándolo después es muy improbable que resulte en el cambio una funcionalidad soportada.
documentElement
of type Element
, readonlydocumentURI
of type DOMString
, introducido en DOM Nivel 3null
si es indefinido o si el Document
fue creado utilizando DOMImplementation.createDocument
. No se realiza ninguna comprobación léxica cuando se fija este atributo; esto podría terminar en un valor null
devuelto cuando se utiliza Node.baseURI
.
Document
soporta la funcionalidad "HTML" [DOM Level 2 HTML], el atributo href del elemento BASE HTML toma precedencia sobre este atributo cuando se procesa Node.baseURI
.
domConfig
of type DOMConfiguration
, readonly, introducido en DOM Nivel 3Document.normalizeDocument()
es invocado.
implementation
of type DOMImplementation
, readonlyDOMImplementation
que maneja este documento. Una aplicación DOM puede usar objetos de múltiples implementaciones.
inputEncoding
of type DOMString
, readonly, introducido en DOM Nivel 3null
cuando no es conocido, como cuando Document
fue creado en memoria.strictErrorChecking
of type boolean
, introducido en DOM Nivel 3false
, la implementación es libre de no comprobar cada caso posible definido normalmente sobre operaciones DOM, y no muestra ningún DOMException
sobre operaciones DOM o reporta errores mientas se utiliza Document.normalizeDocument()
. En caso de error, el comportamiento es indefinido. Este atributo es true
por defecto.xmlEncoding
of type DOMString
, readonly, introducido en DOM Nivel 3null
cuando no se especifica o cuando no es conocido, como cuando el Document
fue creado en memoria.xmlStandalone
of type boolean
, introducido en DOM Nivel 3false
cuando no se especifica.
Nota: La verificación no se realiza sobre el valor cuando se fijan estos atributos. Las aplicaciones deberían usar Document.normalizeDocument()
con la "validación" de parámetros para verificar si el conjunto de valores obliga la validación para una declaración de documento independiente como se define en [XML 1.0].
NOT_SUPPORTED_ERR: provocada si este documento no soporta la funcionalidad "XML". |
xmlVersion
of type DOMString
, introducido en DOM Nivel 3"1.0"
. Si este documento no soporta funcionalidades "XML", el valor siempre es null
. Cambiando este atributo se afectará a los métodos de comprobación para caracteres no válidos en nombres XML. La aplicación deberá invocar Document.normalizeDocument()
para comprobar los caracteres no válidos en los Node
s que ya son parte de este Document
.
DOMImplementation.hasFeature(funcionalidad, versión)
con valores de parámetro "XMLVersion" y "1.0" (respectivamente) para determinar si una implementación soporta [XML 1.0]. Las aplicaciones DOM pueden usar el mismo método con valores de parámetro "XMLVersion" y "1.1" (respectivamente) para determinar si una aplicación soporta [XML 1.1]. En ambos casos, en orden para soportar XML, una implementación debe también soporta la funcionalidad "XML" definida en esta especificación. Los objetos Document
que soportan una versión de la funcionalidad "XMLVersion" no deben mostrar una excepción NOT_SUPPORTED_ERR
para el mismo número de versión cuando se utiliza Document.xmlVersion
.
NOT_SUPPORTED_ERR: provocada si la versión es fijada como un valor que no es soportado por este |
adoptNode
introducido en DOM Nivel 3ownerDocument
(propietario del documento) del nodo fuente, sus hijos, así como los atributos agregados al nodo si los hay. Si el nodo fuente tiene un padre, este es quitado primero de la lista hija del padre. Esto efectivamente permite mover un subárbol de un documento a otro (a diferencia de importNode()
que crea una copia del nodo fuente en vez de moverlo). Cuando esto falla, las aplicaciones deberían usar Document.importNode()
en su lugar. Observe que si el nodo adoptado es ya parte de este documento (es decir, el documento fuente y objetivo es el mismo), este método todavía tiene el efecto de quitar el nodo fuente de la lista hija de su padre, si lo hay. La siguiente lista describe los datos concretos para cada tipo de nodo.
ownerElement
se fija a null
y el flag (bandera) especificada
es fijada a true
en el Attr
adoptado. El descendente del Attr
fuente son adoptados recursivamente.Document
no pueden ser adoptados.DocumentType
no pueden ser adoptados.Entity
no pueden ser adoptados.EntityReference
es adoptado por si mismo, los descendentes son descartados, así que los documentos fuente y destino podían haber definido la entidad de manera diferente. Si el documento está siendo importado dentro de una definición proporcionada para este nombre de entidad, su valor es asignado.Notation
no pueden ser adoptados.Nota:
Ya que esto no crea nodos nuevos a diferencia del método Document.importNode()
, este método no muestra una excepción INVALID_CHARACTER_ERR
, y la aplicación deberá utilizar el método Document.normalizeDocument()
para comprobar si un nombre importado no es un nombre XML de acuerdo a la versión XML en uso.
source
of type Node
El nodo adoptado, o |
NOT_SUPPORTED_ERR: provocada si el nodo fuente es del tipo NO_MODIFICATION_ALLOWED_ERR: provocada si el nodo fuente es de solo lectura. |
createAttribute
Attr
con el nombre dado. Observe que la instancia Attr
puede ser fijada sobre un Element
utilizando el método setAttributeNode
.
createAttributeNS
.
name
of type DOMString
INVALID_CHARACTER_ERR: provocada si el nombre especificado no es un nombre XML de acuerdo a la versión en uso XML especificada en el atributo |
createAttributeNS
introducido en DOM Level 2null
como el parámetro namespaceURI
para métodos en los que desean no tener espacio de nombre (namespace).
namespaceURI
of type DOMString
qualifiedName
of type DOMString
Un nuevo objeto
|
INVALID_CHARACTER_ERR: provocada si el NAMESPACE_ERR: provocada si el NOT_SUPPORTED_ERR: Provocado siempre que el documento actual no soporte la funcionalidad |
createCDATASection
CDATASection
cuyo valor es la cadena especificada.
data
of type
DOMString
CDATASection
.
El nuevo objeto |
NOT_SUPPORTED_ERR: provocada si este documento es un documento HTML. |
createComment
createDocumentFragment
DocumentFragment
.
Un nuevo |
createElement
Element
, así los atributos pueden ser especificados directamente sobre el objeto devuelto.
Attr
que los representan son creados automáticamente y fijados al elemento.createElementNS
.
tagName
of type
DOMString
INVALID_CHARACTER_ERR: provocada si el nombre especificado no es un nombre XML conforme a la versión de XML en uso especificada en el atributo |
createElementNS
introducido en DOM Level 2
null
como el parámetro de URI de espacios de nombre (namespaceURI) para los métodos que deseen no tener espacios de nombres.
namespaceURI
of type DOMString
qualifiedName
of type DOMString
Un nuevo objeto
|
INVALID_CHARACTER_ERR: provocada si el NAMESPACE_ERR: provocada si el NOT_SUPPORTED_ERR: Provocada siempre que el documento actual no soporte funcionalidades |
createEntityReference
EntityReference
. Además, si la entidad referenciada es conocida, la lista de hijos del nodo EntityReference
es la misma que la del nodo Entity
correspondiente.
Nota: Si cualquier descendente del nodo Entity
tiene un prefijo de espacio de nombre suelto, el descendente correspondiente del nodo EntityReference
creado también está suelto; (Su namespaceURI
es null
). El DOM Nivel 2 y 3 no soportan ningún mecanismo que resuelva los prefijos de espacios de nombre en este caso.
name
of type
DOMString
Document.createElementNS
o Document.createAttributeNS
, ninguna comprobación de formato de espacio de nombre es realizada sobre el nombre de la entidad. Las aplicaciones deberían invocar Document.normalizeDocument()
con el parámetro "namespaces" establecido a true
para asegurar que el nombre de la entidad es un espacio de nombre bien formado.
El nuevo objeto |
INVALID_CHARACTER_ERR: provocada si el nombre especificado no es un nombre XML conforme a la versión XML en uso especificada en el atributo NOT_SUPPORTED_ERR: provocada si este documento es un documento HTML. |
createProcessingInstruction
ProcessingInstruction
dando el nombre especificado y la cadena de datos.
target
of type DOMString
Document.createElementNS
o Document.createAttributeNS
, ninguna comprobación de formato de espacio de nombre es realizada sobre el nombre objetivo. Las aplicaciones deberían invocar Document.normalizeDocument()
con el parámetro "namespaces" establecido a true
para asegurar que el nombre objetivo es un espacio de nombre de formato correcto.
data
of type
DOMString
El nuevo objeto |
INVALID_CHARACTER_ERR: provocada si el objetivo especificado no es un nombre XML conforme a la versión XML en uso especificada en el atributo NOT_SUPPORTED_ERR: provocada si este documento es un documento HTML. |
createTextNode
getElementById
introducido en DOM Level 2Element
que tiene un atributo ID con el valor dado. Si no existe dicho elemento, este devuelve null
. Si más de un elemento tiene un atributo ID con ese valor, se devuelve indefinido.
Attr.isId
para determinar si un atributo es del tipo ID.
Nota: Los atributos con el nombre "ID" o "id" no son del tipo ID a menos que así sea definido.
elementId
of type
DOMString
id
único para un elemento.
El elemento indicado o |
getElementsByTagName
NodeList
de todos los Elements
en el orden del documento con un nombre de etiqueta dado y que están contenidos en el documento.
tagname
of type
DOMString
tagname
es sensible a mayúsculas y minúsculas, sino depende de la sensibilidad a mayúsculas y minúsculas del lenguaje de etiquetas en uso.
getElementsByTagNameNS
introducido en DOM Level 2NodeList
de todos los Elements
con un nombre local y URI de espacio de nombre dado dentro del orden del documento.
namespaceURI
of type
DOMString
"*"
abarca todos los espacios de nombres.localName
of type
DOMString
importNode
introducido en DOM Level 2parentNode
es null
).
nodeName
y nodeType
del nodo fuente, más los atributos relacionados con los espacios de nombres (prefix
, localName
, y namespaceURI
). Como en la operación cloneNode
, el nodo fuente no es alterado. Los datos asociados al nodo importado no son transferidos. Sin embargo, si algún UserDataHandlers
ha sido especificado con el dato asociado dicha manipulación será llamada con el parámetro apropiado antes de que este método lo devuelva.nodeType
(tipo de nodo), intentando reflejar el comportamiento esperado si un fragmento de código fuente de XML o HTML fuese copiado de un documento a otro, reconociendo que los dos documentos pueden tener diferentes DTDs en el caso de XML. La siguiente lista describe los datos concretos para cada tipo de nodo.
ownerElement
es fijado a null
y el bandera (flag) especificada
es fijada a true
en el Attr
generado. Los descendentes del Attr
fuente son importados recursivamente y los nodos resultantes reensamblados para formar el sub-árbol correspondiente.
deep
no tiene efectos sobre los nodos Attr
; ellos siempre llevan a sus hijos cuando son importados.
deep
fue establecida a true
, los descendentes del DocumentFragment
fuente son recurrentemente importados y los nodos resultantes reensamblados bajo DocumentFragment
importado para formar el sub-árbol correspondiente. Si no, esto simplemente genera un DocumentFragment
vacío.
Document
no pueden ser importados.DocumentType
no pueden ser importados.Attr
generados son adjuntados al Element
generado. Los atributos predeterminados no son copiados, aunque si el documento que está siendo importado define atributos predeterminados para este nombre de elemento, esos son asignados. Si el parámetro importNode
deep
fue fijado a true
, los descendentes del elemento fuente son importados recursivamente y los nodos resultantes reensamblados para formar el sub-árbol correspondiente.
Entity
pueden ser importados, sin embargo en la liberación actual del DOM el DocumentType
es de solo lectura. La capacidad para añadir estos nodos importados a un DocumentType
. Será considerado para añadirlo a una futura liberación del DOM.publicId
, systemId
,
y notationName
son copiados. Si una importación deep
es requerida, los descendentes del Entity
fuente son importados recursivamente y los nodos resultantes reensamblados para formar el correspondiente sub-árbol.
EntityReference
es copiado, incluso si una importación deep
es requerida, desde los documentos fuente y destino podrían tener definidos identidad diferente. Si el documento que está siendo importado proporciona una definición para este nombre de entidad, su valor se asigna.
Notation
pueden ser importados, sin embargo en la liberación actual del DOM el DocumentType
es de solo lectura. La capacidad añadir estos nodos importados a un DocumentType
será considerada para añadirlo en una futura liberación del DOM.publicId
y systemId
son copiados.
deep
no tiene efecto sobre este tipo de nodos ya que no pueden tener ningún hijo.
target
y data
de esos nodos fuente.
deep
no tiene efecto sobre este tipo de nodos ya que estos no pueden tener ningún hijo.
CharacterData
sus atributos data
y length
del nodo fuente.
deep
no tiene efecto sobre estos tipos de nodos ya que no pueden tener ningún hijo.
importedNode
of type
Node
deep
of type boolean
true
, se importa recursivamente el sub-árbol bajo el nodo especificado; si es false
, solo se importa el nodo, como se explicó arriba. Esto no tiene efecto sobre el nodo que no puede tener ningún hijo, y sobre los nodos Attr
, y EntityReference
.
El nodo importado que pertenece a este |
NOT_SUPPORTED_ERR: provocada si el tipo de nodo que está siendo importado no es soportado. INVALID_CHARACTER_ERR: provocada si uno de los nombres importados no es un nombre XML conforme a la versión XML especificada en uso en el atributo |
normalizeDocument
introducido en DOM Nivel 3EntityReference
y Text
, como se define en el método Node.normalize()
.
Document.domConfig
y gobernando que operaciones realmente ocurren. Perceptiblemente este método podría hacer también el documento de espacio de nombre bien formado de acuerdo al algoritmo descrito en Normalización de Espacio de Nombre, comprueba el carácter de normalización, quita los nodos CDATASection
, etc. Vea DOMConfiguración
para más detalles.
// Mantiene en el documento la información definida // en el Conjunto de Información de XML (Java por ejemplo) DOMConfiguration docConfig = myDocument.getDomConfig(); docConfig.setParameter("infoset", Boolean.TRUE); myDocument.normalizeDocument();
Node.nodeName
que contiene caracteres no válidos de acuerdo con la versión de XML en uso, errores o advertencias (DOMError.SEVERITY_ERROR
o
DOMError.SEVERITY_WARNING
) serán reportadas utilizando el objeto DOMErrorHandler
asociado con el parámetro "error-handler". Observe que este método también podría reportar errores graves (DOMError.SEVERITY_FATAL_ERROR
) si una implementación no puede reponerse de un error.
renameNode
introducido en DOM Nivel 3ELEMENT_NODE
o ATTRIBUTE_NODE
.
Element
sus atributos son movidos al nuevo nodo, el nuevo nodo es insertado en la posición del viejo nodo usado teniendo la lista de los nodos hijos de su padre si lo tuviera, los datos del usuario que son adjuntados al nodo viejo son adjuntados al nuevo nodo.
Element
solo los atributos especificados son movidos, los atributos por defectos originados por el DTD son actualizados de acuerdo al nuevo nombre del elemento. Además, la implementación puede actualizar los atributos predeterminados de otros esquemas. Las aplicaciones pueden usar Document.normalizeDocument()
para garantizar que estos atributos son actualizados.
Attr
que esta asociado (atado) a un Element
, el nodo primero es eliminado del mapa de atributos de Element
. Entonces, una vez renombrado, bien por modificación del nodo existente o por creación de uno nuevo como se describió arriba, se vuelve a poner.
NODE_RENAMED
es lanzado,
http://www.w3.org/2001/xml-events
, DOMElementNameChanged
} o {http://www.w3.org/2001/xml-events
, DOMAttributeNameChanged
} es lanzado.
n
of type
Node
namespaceURI
of type
DOMString
qualifiedName
of type
DOMString
El nodo renombrado. Este es el nodo especificado o el nuevo nodo que fue creado para reemplazar el nodo especificado. |
NOT_SUPPORTED_ERR: provocada cuando el tipo de nodo especificado no es ni INVALID_CHARACTER_ERR: provocada si el nuevo nombre cualificado (correcto) no es un nombre XML de acuerdo con la versión XML en uso especificada en el atributo WRONG_DOCUMENT_ERR: provocada cuando el nodo especificado fue creado de un documento diferente al actual. NAMESPACE_ERR: provocada si el |
La interfaz Node
es el tipo de dato primario para la integridad del Modelo de Objetos del Documento. Representa un nodo individual del árbol del documento. Mientras que todos los objetos que implementan la interfaz Node
exponen métodos para tratar con hijos, no todos los objetos que implementan la interfaz Node
pueden tener hijos. Por ejemplo, los nodos Text
no pueden tener hijos, y al añadir hijos a tales nodos provoca una excepción DOMException
.
Los atributos nodeName
, nodeValue
y attributes
se han incluido como un mecanismo para obtener información del nodo sin destruir la interfaz específica derivada. En los casos donde no hay un mapa obvio de estos atributos para un nodeType
específico (Por Ejemplo, nodeValue
para un Element
o attributes
para un Comment
), esto devuelve null
. Observe que las interfaces especializadas pueden contener mecanismos adicionales y convenientes para obtener y establecer la información relevante.
interfaz Node { // NodeType const unsigned short ELEMENT_NODE = 1; const unsigned short ATTRIBUTE_NODE = 2; const unsigned short TEXT_NODE = 3; const unsigned short CDATA_SECTION_NODE = 4; const unsigned short ENTITY_REFERENCE_NODE = 5; const unsigned short ENTITY_NODE = 6; const unsigned short PROCESSING_INSTRUCTION_NODE = 7; const unsigned short COMMENT_NODE = 8; const unsigned short DOCUMENT_NODE = 9; const unsigned short DOCUMENT_TYPE_NODE = 10; const unsigned short DOCUMENT_FRAGMENT_NODE = 11; const unsigned short NOTATION_NODE = 12; readonly attribute DOMString nodeName; attribute DOMString nodeValue; // raises(DOMException) on setting // raises(DOMException) on retrieval readonly attribute unsigned short nodeType; readonly attribute Node parentNode; readonly attribute NodeList childNodes; readonly attribute Node firstChild; readonly attribute Node lastChild; readonly attribute Node previousSibling; readonly attribute Node nextSibling; readonly attribute NamedNodeMap attributes; // Modificado en DOM Nivel 2: readonly attribute Document ownerDocument; // Modificado en DOM Nivel 3: Node insertBefore(in Node newChild, in Node refChild) raises(DOMException); // Modificado en DOM Nivel 3: Node replaceChild(in Node newChild, in Node oldChild) raises(DOMException); // Modificado en DOM Nivel 3: Node removeChild(in Node oldChild) raises(DOMException); // Modificado en DOM Nivel 3: Node appendChild(in Node newChild) raises(DOMException); boolean hasChildNodes(); Node cloneNode(in boolean deep); // Modificado en DOM Nivel 3: void normalize(); // Introducido en DOM Nivel 2: boolean isSupported(in DOMString feature, in DOMString version); // Introducido en DOM Nivel 2: readonly attribute DOMString namespaceURI; // Introducido en DOM Nivel 2: attribute DOMString prefix; // raises(DOMException) on setting // Introducido en DOM Nivel 2: readonly attribute DOMString localName; // Introducido en DOM Nivel 2: boolean hasAttributes(); // Introducido en DOM Nivel 3: readonly attribute DOMString baseURI; // DocumentPosition const unsigned short DOCUMENT_POSITION_DISCONNECTED = 0x01; const unsigned short DOCUMENT_POSITION_PRECEDING = 0x02; const unsigned short DOCUMENT_POSITION_FOLLOWING = 0x04; const unsigned short DOCUMENT_POSITION_CONTAINS = 0x08; const unsigned short DOCUMENT_POSITION_CONTAINED_BY = 0x10; const unsigned short DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC = 0x20; // Introducido en DOM Nivel 3: unsigned short compareDocumentPosition(in Node other) raises(DOMException); // Introducido en DOM Nivel 3: attribute DOMString textContent; // raises(DOMException) on setting // raises(DOMException) on retrieval // Introducido en DOM Nivel 3: boolean isSameNode(in Node other); // Introducido en DOM Nivel 3: DOMString lookupPrefix(in DOMString namespaceURI); // Introducido en DOM Nivel 3: boolean isDefaultNamespace(in DOMString namespaceURI); // Introducido en DOM Nivel 3: DOMString lookupNamespaceURI(in DOMString prefix); // Introducido en DOM Nivel 3: boolean isEqualNode(in Node arg); // Introducido en DOM Nivel 3: DOMObject getFeature(in DOMString feature, in DOMString version); // Introducido en DOM Nivel 3: DOMUserData setUserData(in DOMString key, in DOMUserData data, in UserDataHandler handler); // Introducido en DOM Nivel 3: DOMUserData getUserData(in DOMString key); };
Un entero indicando que tipo de nodo es este.
Nota: Los códigos numéricos hasta el 200 son reservados por W3C para posibles usos futuros.
ATTRIBUTE_NODE
Attr
.CDATA_SECTION_NODE
CDATASection
.COMMENT_NODE
Comment
.DOCUMENT_FRAGMENT_NODE
DocumentFragment
.DOCUMENT_NODE
Document
.DOCUMENT_TYPE_NODE
DocumentType
.ELEMENT_NODE
Element
.ENTITY_NODE
Entity
.ENTITY_REFERENCE_NODE
EntityReference
.NOTATION_NODE
Notation
.PROCESSING_INSTRUCTION_NODE
ProcessingInstruction
.TEXT_NODE
Text
.Los valores de nodeName
, nodeValue
, y attributes
varían de acuerdo al tipo de nodo como sigue:
Interfaz | nodeName | nodeValue | atributos |
---|---|---|---|
Attr |
Igual que Attr.name , el nombre del atributo |
Igual que Attr.value , el valor del atributo |
null |
CDATASection |
"#cdata-section" |
Igual que CharacterData.data , el contendido de la Sección CDATA |
null |
Comment |
"#comment" |
Igual que CharacterData.data , el contenido del comentario |
null |
Document |
"#document" |
null |
null |
DocumentFragment |
"#document-fragment" |
null |
null |
DocumentType |
Igual que DocumentType.name , nombre del tipo de documento |
null |
null |
Element |
Igual que Element.tagName , nombre de la etiqueta |
null |
NamedNodeMap |
Entity | nombre de la entidad (entity) |
null |
null |
EntityReference | nombre de la entidad referenciada |
null |
null |
Notation | nombre de notación |
null |
null |
ProcessingInstruction |
Igual que ProcessingInstruction.target , el destino |
Igual que ProcessingInstruction.data , el dato |
null |
Text |
"#text" |
Igual que CharacterData.data , el contenido del nodo texto |
null |
Una mascara de bit (bitmask) indicando la posición relativa en el documento de un nodo con respecto a otro nodo.
Si los dos nodos comparados son el mismo nodo, entonces no se pone ninguna flags en el valor devuelto.
Sino, el orden de los dos nodos es determinado buscando contenedores comunes -- contenedores que contenga a ambos. Un nodo contiene directamente a cualquier nodo hijo. Un nodo también contiene directamente a cualquier otro nodo asociado así como los atributos contenidos en un elemento o entidades y notaciones contenidas en un tipo de documento. Los nodos contenidos en el contenido de un nodo también son contenidos, pero directamente menor al número de aumentos de contenedores que intervienen.
Si no hay nodo contenedor común, entonces el orden es basado en el orden entre el contenedor raíz de cada nodo que no está en ningún contenedor. En este caso, el resultado es deshabilitado e implementado específicamente. Este resultado es estable mientras estos contenidos de nodos exteriores permanecen en la memoria y no son insertados en algún contenido de otro nodo. Este sería el caso cuando los nodos pertenecen a diferentes documentos o fragmentos, y se clona el documento o se inserta un fragmento pudiendo cambiar el orden.
Si uno de los nodos que está siendo comparado contiene otro nodo, entonces el contenedor precede al nodo contenido, e inversamente el nodo contenido sigue al contenedor. Por ejemplo, cuando comparando un elemento con su propio atributo o hijo, el elemento nodo precede a su nodo atributo y a su nodo hijo, y ambos siguen al primero.
Si ninguno de los casos anteriores se aplica, entonces existe un contenedor más directo común para los nodos que son comparados. En este caso, el orden es determinado en base a la determinación de los dos nodos directamente contenidos en este contendor más directo común que es o contiene los correspondientes nodos que están siendo comparados.
Si estos dos nodos determinados son ambos nodos hijos, entonces el orden natural de DOM de estos nodos determinados dentro del nodo que los contiene es devuelto como el orden del los correspondientes nodos. Este podría ser el caso, por ejemplo, cuando comparamos dos elementos hijos de un mismo elemento.
Si uno de los dos nodos determinados es un hijo y el otro no, entonces el nodo correspondiente al nodo hijo sigue al nodo correspondiente del nodo no hijo. Este podría ser el caso, por ejemplo, cuando comparamos un atributo de un elemento con un elemento hijo del mismo elemento.
Si ninguno de los dos nodos determinados es un nodo hijo y un nodo determinado tiene un mayor valor de nodeType
que el otro, entonces el nodo correspondiente precede al otro. Este podría ser el caso, por ejemplo, cuando comparamos una entidad de un tipo de documento con una notación de ese mismo tipo de documento.
Si ninguno de los dos nodos determinados son un nodo hijo y el nodeType
es el mismo para ambos nodos determinados, entonces el orden devuelto entre los nodos determinados depende de la implementación. Este orden se estable mientras el mismo tipo de nodo (nodeType) no sea insertado dentro o borrado del contenedor directo. Este podría ser el caso, por ejemplo, cuando comparamos dos atributos de un mismo elemento, e insertamos o borramos atributos adicionales que implican cambios de orden entre los atributos existentes.
DOCUMENT_POSITION_CONTAINED_BY
DOCUMENT_POSITION_CONTAINS
DOCUMENT_POSITION_DISCONNECTED
DOCUMENT_POSITION_FOLLOWING
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC
DOCUMENT_POSITION_PRECEDING
attributes
of type NamedNodeMap
, readonlyNamedNodeMap
contiene los atributos de este nodo (si este es un Element
) o null
si no.baseURI
of type DOMString
, readonly, introducido en DOM Nivel 3null
si la implementación no fuera capaz de obtener la URI absoluta. Este valor es procesado como se describe en URIs Base. Sin embargo, cuando Document
soporta una carácterística "HTML" [DOM Nivel 2 HTML], la URI base es completada utilizando primero el valor del atributo href del elemento BASE HTML, y el valor del atributo documentURI
de la interfaz Document
si no.childNodes
of type NodeList
, readonlyNodeList
contiene todos los hijos de este nodo. Si no hay hijos, este NodeList
no contiene nodos.firstChild
of type Node
, readonlynull
.lastChild
of type Node
, readonlynull
.localName
of type DOMString
, readonly, introducido en DOM Level 2ELEMENT_NODE
y ATTRIBUTE_NODE
y nodos creados con métodos de DOM Nivel 1, tales como Document.createElement()
, esto siempre es null
.namespaceURI
of type DOMString
, readonly, introducido en DOM Level 2null
si este no está especificado (ver XML Namespaces).ELEMENT_NODE
y ATTRIBUTE_NODE
y nodos creados con métodos de DOM Nivel 1, tales como Document.createElement()
, esto siempre es null
.
Nota: Por la Especificación de Espacios de Nombres en XML [XML Namespaces] un atributo no puede heredar su espacio de nombre (namespace) del elemento al que es adjuntado. Si un atributo no da explícitamente un espacio de nombre, este simplemente no tiene espacio de nombre.
nextSibling
of type Node
, readonlynull
.nodeName
of type DOMString
, readonlynodeType
of type unsigned short
, readonlynodeValue
of type DOMString
null
, los ajustes sobre el no tienen efecto, incluido si el nodo es solo lectura (read-only).
NO_MODIFICATION_ALLOWED_ERR: provocada cuando el nodo es de solo lectura y si este no es definido para ser |
DOMSTRING_SIZE_ERR: provocada cuando este devolvería más caracteres que los soportados en una variable |
ownerDocument
of type Document
, readonly, modificado en DOM Level 2Document
asociado con este nodo. Este es también el objeto Document
utilizado para crear un nuevo nodo. Cuando este nodo es un Document
o un DocumentType
que no se utiliza aun con ningún Document
, este es null
.parentNode
of type Node
, readonlyAttr
, Document
,
DocumentFragment
, Entity
, y Notation
pueden tener un padre. Sin embargo, si el nodo acaba de ser creado y aun no ha sido añadido al árbol, o si ha sido retirado del árbol, esto es null
.
prefix
of type DOMString
, introducido en DOM Level 2null
si no está especificado. Cuando este es definido para ser null
, los ajustes no tienen efectos, incluyendo si el nodo es de solo lectura.nodeName
, que sostiene el nombre cualificado (qualified name), así como los atributos tagName
y name
de las interfaces Element
y Attr
, cuando es aplicable.
null
hace a este no especificado, estableciéndolo como una cadena vacía dependiendo de la implementación.namespaceURI
y localName
.
ELEMENT_NODE
y ATTRIBUTE_NODE
y nodos creados con un método de DOM Level 1, tal como la interfaz createElement
del Document
, esto es siempre null
.
INVALID_CHARACTER_ERR: provocada si el prefijo especificado contiene un carácter ilegal de acuerdo con la versión de XML en uso especificado en el atributo NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NAMESPACE_ERR: provocada si el |
previousSibling
of type Node
, readonlynull
.textContent
of type DOMString
, introducido en DOM Nivel 3null
, los ajustes no tienen efecto. Sobre el ajuste, cualquier hijo posible de este nodo puede ser quitado y, si la nueva cadena no está vacía o es null
, se reemplaza por un simple nodo Text
conteniendo la cadena estos atributos que son fijados.
Text.isElementContentWhitespace
). Igualmente, sobre el ajuste, no se realiza ningún análisis, la cadena de entrada es tomada como contenido de texto puro.
Tipo de Nodo | Contenido |
---|---|
ELEMENT_NODE, ATTRIBUTE_NODE, ENTITY_NODE, ENTITY_REFERENCE_NODE, DOCUMENT_FRAGMENT_NODE |
concatenación del valor de atributo textContent de cada nodo hijo, excluyendo los nodos COMMENT_NODE y PROCESSING_INSTRUCTION_NODE. Esto es una cadena vacía si el nodo no tiene hijos. |
TEXT_NODE, CDATA_SECTION_NODE, COMMENT_NODE, PROCESSING_INSTRUCTION_NODE |
nodeValue |
DOCUMENT_NODE, DOCUMENT_TYPE_NODE, NOTATION_NODE | null |
NO_MODIFICATION_ALLOWED_ERR: provocada cuando el nodo es de solo lectura. |
DOMSTRING_SIZE_ERR: provocada cuando este devolviera más caracteres que los permitidos en una variable |
appendChild
modificado en DOM Nivel 3newChild
al final de la lista de hijos de este nodo. Si el newChild
ya está en el árbol, este se retira primero.
newChild
of type
Node
DocumentFragment
, el contenido entero del fragmento del documento es movido a la lista de hijos de este nodo.
El nodo a añadir. |
HIERARCHY_REQUEST_ERR: provocada si este nodo es de un tipo que no permite hijos del tipo de nodo WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura o si el padre anterior del nodo que esta siendo insertado es de solo lectura. NOT_SUPPORTED_ERR: Si el nodo |
cloneNode
parentNode
es null
) y ningún dato de usuario. Los datos de usuario asociados al nodo importado no son transferidos. Sin embargo, si algún UserDataHandlers
(manejador de datos de usuario) ha sido especificado con el dato asociado estos manejadores (handlers) podrán ser llamados con los parámetros apropiados después de que este método los devuelva.Element
copia todos los atributos y sus valores, incluyendo esos generados por el proceso XML para representar los atributos que falten, pero este método no copia algún hijo que contenga salvo que sea una clonación profunda. Este incluye el texto contenido en un Element
ya que el texto está contenido en un nodo hijo Text
. Clonando directamente un Attr
, como opuesto para ser clonado como parte de una operación de clonación de un Element
, devuelve un atributo específico (Especificado
es
true
). Clonando un Attr
siempre clona a sus hijos, ya que ellos representan sus valores, no importa si esta es una clonación profunda o no. Clonando un EntityReference
automáticamente construye su sub-árbol si un Entity
correspondiente está disponible, no importa si esta es una clonación profunda o no. La clonación de cualquier otro tipo de nodo simplemente devuelve una copia de este nodo.
EntityReference
son de solo lectura.
Además, clonaciones de nodos Attr
no especificados son especificados. Y, la clonación de nodos Document
, DocumentType
, Entity
, y Notation
dependen de la implementación.
deep
of type
boolean
true
, clona de forma recursiva el sub-árbol bajo el nodo especificado; si es false
, clona solamente dicho nodo (y sus atributos, si es un Element
).
El nodo duplicado. |
compareDocumentPosition
introducido en DOM Nivel 3other
of type
Node
|
Devuelve como el nodo es posicionado relativamente en el nodo de referencia. |
NOT_SUPPORTED_ERR: Cuando los nodos comparados son de diferentes implementaciones DOM que no coordinan devolver resultados constantes específicos de la implementación. |
getFeature
introducido en DOM Nivel 3Node
.
feature
of type
DOMString
version
of type
DOMString
Devuelve un objeto que implementa las APIs especializadas de la funcionalidad y versión especificada, si existe, o |
getUserData
introducido en DOM Nivel 3setUserData
con la misma clave (key).
key
of type
DOMString
Devuelve el |
hasAttributes
introducido en DOM Level 2
|
Devuelve |
hasChildNodes
|
Devuelve |
insertBefore
modificado en DOM Nivel 3newChild
antes del nodo hijo refChild
existente. Si refChild
es null
, inserta el newChild
al final de la lista de hijos.
newChild
es un objeto DocumentFragment
, todos sus hijos son insertados, en el mismo orden, antes de refChild
. Si el newChild
ya está en el árbol, este es primero retirado.
Nota: Insertar un nodo antes de si mismo depende de la implementación.
El nodo que se está insertando. |
HIERARCHY_REQUEST_ERR: provocada si este nodo es de un tipo que no permite hijos del tipo del nodo WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura o si el padre del nodo que se está insertando es de solo lectura. NOT_FOUND_ERR: provocada si NOT_SUPPORTED_ERR: Si este nodo es del tipo |
isDefaultNamespace
introducido en DOM Nivel 3namespaceURI
especificado es el espacio de nombre predeterminado o no.
namespaceURI
of type
DOMString
|
Devuelve |
isEqualNode
introducido en DOM Nivel 3Node.isSameNode()
. Todos los nodos que son los mismos van a ser también iguales, aunque lo contrario no puede ser verdad.nodeName
, localName
,
namespaceURI
, prefix
,
nodeValue
. Esto es: Ambos son null
, o tengan la misma longitud y sean carácter a carácter idénticos.atributos
NamedNodeMaps
son iguales. Esto es: Ambos son null
, o tienen la misma longitud y para cada nodo existente en un mapa en el que hay un nodo que existe en el mapa del otro y es igual, aunque no es necesario que sea el mismo índice.childNodes
NodeLists
son iguales. Esto es: Ambos son null
, o tienen la misma longitud y contienen nodos iguales en el mismo índice. Observe que la normalización puede afectar igualmente;, para evitar esto, los nodos deberían ser normalizados antes de ser comparados.DocumentType
sean iguales, las siguientes condiciones tienen que ser satisfechas:
publicId
, systemId
,
internalSubset
.entidades
NamedNodeMaps
son iguales.notaciones
NamedNodeMaps
son iguales.ownerDocument
, baseURI
, y parentNode
, el atributo especificado
para nodos Attr
, el atributo schemaTypeInfo
para nodos Attr
y Element
, el atributo Text.isElementContentWhitespace
para nodos Text
, así como cualquier otro dato de usuario o eventos a la escucha registrados sobre los nodos.
Nota: Como regla general, algo no mencionado en la descripción de arriba no es significativo en consideración con la verificación de igualdad. Observe que futuras versiones de esta especificación pueden tener en cuenta más atributos e implementaciones conforme a esta especificación esperando actualizarlas en consecuencia.
arg
of type
Node
|
Devuelve |
isSameNode
introducido en DOM Nivel 3Nodos
devueltas por la implementación se refiere al mismo objeto. Cuando dos referencias de Nodos
están referidas al mismo objeto, incluso si a través de un proxy, las referencias pueden ser utilizadas de manera completamente intercambiables, igual que todos los atributos tienen los mismos valores y llaman al mismo método DOM sobre una u otra referencia siempre tiene el mismo efecto.
other
of type
Node
|
Devuelve |
isSupported
introducido en DOM Level 2
|
Devuelve |
lookupNamespaceURI
introducido en DOM Nivel 3prefix
of type
DOMString
null
, el método devolverá el URI de espacio de nombre por defecto si lo hay.
Devuelve el URI de espacio de nombre asociado o |
lookupPrefix
introducido en DOM Nivel 3namespaceURI
of type
DOMString
Devuelve un prefijo de espacio de nombre asociado si lo encuentra o |
normalize
modificado en DOM Nivel 3Text
en el final del sub-árbol debajo de este Nodo
, incluyendo los atributos de nodos, dentro de una forma "normal" donde solo la estructura (Por ejemplo, elementos, contenidos, instrucciones de procesado, secciones CDATA y referencias vacías) separa nodos Text
, es decir, no hay ningún nodo Text
adyacente ni nodos Text
vacíos. Esto puede ser utilizado para asegurar que la representación de un documento DOM es el mismo si este es guardado y recargado, y es útil cuando operaciones (tales como buscar XPointer [XPointer]) que dependen de un documento con una estructura de árbol particular van a ser utilizadas. Si el parámetro "normalize-characters" del objeto DOMConfiguration
adjuntado a Node.ownerDocument
es true
, este método también normalizará completamente los caracteres de los nodos Text
.
Nota: En casos donde el documento contenga CDATASections
, la operación de normalización no será suficiente, ya que XPointers no diferencia entre nodos Text
y nodos CDATASection
.
removeChild
modificado en DOM Nivel 3oldChild
de la lista de hijos, y la devuelve.
oldChild
of type
Node
El nodo quitado. |
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NOT_FOUND_ERR: provocada si NOT_SUPPORTED_ERR: Si este nodo es del tipo |
replaceChild
modificado en DOM Nivel 3oldChild
por el newChild
en la lista de hijos, y devuelve el nodo oldChild
.
newChild
es un objeto DocumentFragment
, oldChild
es reemplazado por todos los hijos del DocumentFragment
, que son insertados en el mismo orden. Si el newChild
está correctamente en el árbol, es primero quitado.
Nota: Reemplazar un nodo con sigo mismo depende de la implementación.
El nodo reemplazado. |
HIERARCHY_REQUEST_ERR: provocada si este nodo es de un tipo que no permite hijos del tipo de nodo WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo o el padre del nuevo nodo es de solo lectura. NOT_FOUND_ERR: provocada si NOT_SUPPORTED_ERR: Si este nodo es del tipo |
setUserData
introducido en DOM Nivel 3getUserData
indicando la clave (key).
key
of type
DOMString
data
of type
DOMUserData
null
si se quita cualquier asociación existente a esa clave (key).
handler
of type
UserDataHandler
null
.
Devuelve el |
La interfaz NodeList
proporciona la abstracción de un conjunto ordenado de nodos, sin definir o restringir como se implementa este conjunto. Los objetos NodeList
en DOM son vivos.
Los elementos en NodeList
son accesibles por un índice entero, que comienza en el 0.
length
of type unsigned long
, readonlylength-1
, ambos inclusive.item
index
th del conjunto. Si index
es mayor o igual que el número de nodos de la lista, este devuelve null
.
index
of type
unsigned long
El nodo en la posición |
Los objetos que implementan la interfaz NamedNodeMap
son utilizados para representar conjuntos de nodos a los que se pueden acceder por su nombre. Observe que NamedNodeMap
no se hereda de un NodeList
; en efecto, los NamedNodeMaps
no se mantienen en ningún orden en particular. Los objetos contenidos en un objeto implementados en NamedNodeMap
deben ser también accesibles por un índice ordinal, pero esto es simplemente para permitir una enumeración adecuada del contenido de un NamedNodeMap
, y no implica que DOM especifique un orden para esos Nodos.
Los objetos NamedNodeMap
en DOM son vivos.
interfaz NamedNodeMap { Node getNamedItem(in DOMString name); Node setNamedItem(in Node arg) raises(DOMException); Node removeNamedItem(in DOMString name) raises(DOMException); Node item(in unsigned long index); readonly attribute unsigned long length; // Introducido en DOM Nivel 2: Node getNamedItemNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); // Introducido en DOM Nivel 2: Node setNamedItemNS(in Node arg) raises(DOMException); // Introducido en DOM Nivel 2: Node removeNamedItemNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); };
length
of type unsigned long
, readonly0
a length-1
inclusive.getNamedItem
name
.
name
of type
DOMString
nodeName
) a recuperar.getNamedItemNS
introducido en DOM Level 2namespaceURI
of type
DOMString
localName
of type
DOMString
NOT_SUPPORTED_ERR: Puede ser mostrada si la implementación no soporta la funcionalidad "XML" y el lenguaje expuesto en el Documento no soporta Espacios de Nombre XML (tal como [HTML 4.01]). |
item
index
th del mapa. Si el índice
es mayor o igual que el número de nodos en este mapa, esto devuelve null
.
index
of type
unsigned long
El nodo en la posición |
removeNamedItem
name
of type
DOMString
nodeName
) a quitar.
El nodo quitado de este mapa si existe un nodo con tal nombre. |
NOT_FOUND_ERR: provocada si no hay ningún nodo llamado NO_MODIFICATION_ALLOWED_ERR: provocada si este mapa es de solo lectura. |
removeNamedItemNS
introducido en DOM Level 2Node
. Si es así, aparece inmediatamente un atributo conteniendo el valor por defecto así como el correspondiente URI de espacio de nombre, nombre local y prefijo cuando sea aplicable.
namespaceURI
of type
DOMString
localName
of type
DOMString
El nodo quitado de este mapa si existe un nodo con dicho nombre local y URI de espacio de nombre. |
NOT_FOUND_ERR: provocada si no hay un nodo con el NO_MODIFICATION_ALLOWED_ERR: provocada si este mapa es de solo lectura. NOT_SUPPORTED_ERR: Pude ser provocada si la implementación no soporta la funcionalidad "XML" y el lenguaje expuesto en el documento no soporta Nombres de espacio XML (tal como [HTML 4.01]). |
setNamedItem
nodeName
. Si un nodo con este nombre existe ya en este mapa, este es reemplazado por el nuevo. Reemplazar un nodo por si mismo no tiene efecto.
nodeName
se utiliza para determinar el nombre con el cual debe ser almacenado, los nodos múltiples de determinados tipos (aquellos que tienen un valor de cadena "especial") no pueden almacenarse ya que los nombres entrarían en conflicto. Esto es preferible en lugar de permitir asignar alias a los nodos.
arg
of type
Node
nodeName
.
WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este mapa es de solo lectura. INUSE_ATTRIBUTE_ERR: provocada si HIERARCHY_REQUEST_ERR: provocada si se intenta añadir un nodo no perteneciente a este NamedNodeMap. Los ejemplos incluyen intentar insertar algún otro nodo Attr dentro del mapa de atributos de elementos o un nodo no vacío dentro del mapa de tipo de documento (DocumentType) de Entidades. |
setNamedItemNS
introducido en DOM Nivel 2namespaceURI
y localName
. Si el nodo con ese URI de espacio de nombre y ese nombre local ya existe en este mapa, este es reemplazado por el nuevo. Reemplazar un nodo por si mismo no tiene efecto.arg
of type
Node
namespaceURI
y localName
.
WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este mapa es de solo lectura. INUSE_ATTRIBUTE_ERR: provocada si HIERARCHY_REQUEST_ERR: provocada si se intenta añadir un nodo no perteneciente a este NamedNodeMap. Los ejemplos incluyen intentar insertar algún otro nodo Attr dentro del mapa de atributos de elementos o un nodo no vacío dentro del mapa de tipo de documentos (DocumentType) de Entidades. NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad "XML" y el lenguaje expuesto en el Documento no soporta Espacios de Nombre XML (tal como [HTML 4.01]). |
La interfaz CharacterData
extiende al Nodo con un conjunto de atributos y métodos para acceder a datos de caracteres DOM. Por claridad este conjunto es definido aquí en lugar de hacerlo sobre cada objeto que utilice estos atributos y métodos. Ningún objeto DOM corresponde directamente a CharacterData
, sin embargo Text
y otros hereden su interfaz de él. Todos los offsets
(posiciones) en esta interfaz comienzan desde 0
.
Como se explica en la interfaz DOMString
, las cadenas de texto en DOM son representadas en UTF-16, es decir, como una secuencia de unidades de 16-bit. En lo siguiente, el termino unidades 16-bit es usado siempre que es necesario indicar que la indexación en CharacterData está hecha en unidades de 16-bit.
interfaz CharacterData : Node { attribute DOMString data; // raises(DOMException) on setting // raises(DOMException) on retrieval readonly attribute unsigned long length; DOMString substringData(in unsigned long offset, in unsigned long count) raises(DOMException); void appendData(in DOMString arg) raises(DOMException); void insertData(in unsigned long offset, in DOMString arg) raises(DOMException); void deleteData(in unsigned long offset, in unsigned long count) raises(DOMException); void replaceData(in unsigned long offset, in unsigned long count, in DOMString arg) raises(DOMException); };
data
of type DOMString
CharacterData
. Sin embargo, los límites de una implementación pueden hacer que no quepa en un solo DOMString
la totalidad de los datos de un nodo. En tal caso, el usuario puede llamar a substringData
para recuperar los datos en bloques de tamaño apropiado.
NO_MODIFICATION_ALLOWED_ERR: provocada cuando el nodo es de solo lectura. |
DOMSTRING_SIZE_ERR: provocada cuando este devolviera más caracteres que los que caben en una variable |
length
of type unsigned long
, readonlydata
y del método substringData
descrito abajo. Esto puede tener el valor cero, es decir, los nodos CharacterData
pueden estar vacíos.
appendData
data
proporciona acceso a la concatenación de data
y el DOMString
especificado.
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. |
deleteData
data
y length
reflejan el cambio.
offset
of type
unsigned long
count
of type
unsigned long
offset
y count
excede a length
entonces todas las unidades de 16-bit desde offset
hasta el final de los datos son borradas.
INDEX_SIZE_ERR: provocada si el NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. |
insertData
INDEX_SIZE_ERR: provocada si el NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. |
replaceData
offset
of type
unsigned long
count
of type
unsigned long
offset
y count
excede a length
, entonces se reemplazan todas las unidades de 16-bit hasta el final de los datos; (es decir, el efecto es el mismo que el de una llamada al método remove
la misma subcadena, seguida de una invocación al método append
).
arg
of type
DOMString
DOMString
con la debe ser reemplazada la subcadena.
INDEX_SIZE_ERR: provocada si el NO_MODIFICATION_ALLOWED_ERR: Provocado si este nodo es de solo lectura. |
substringData
offset
of type
unsigned long
count
of type
unsigned long
La subcadena especificada. Si la suma de |
INDEX_SIZE_ERR: provocada si el DOMSTRING_SIZE_ERR: provocada si la subcadena de texto especificada no cabe en un |
La interfaz Attr
representa un atributo de un objeto Element
. Normalmente los valores permitidos para el atributo está definidos en el esquema asociado al documento.
Los objetos Attr
heredan la interfaz Node
, pero como en realidad no son nodos hijos del elemento al que describen, DOM no los considera parte del árbol del documento. Así, los atributos de Node
parentNode
, previousSibling
, y nextSibling
tienen un valor null
para los objetos Attr
. DOM considera que los atributos son propiedades de elementos, es decir, que no tienen una identidad separada de los elementos a los que están asociados; gracias a esto debería ser más sencillo implementar carácterísticas tales como atributos por defecto asociados a elementos de un tipo dado. Además, los nodos Attr
no pueden ser hijos inmediatos de un DocumentFragment
. Sin embargo, pueden asociarse a nodos Element
contenidos dentro de un DocumentFragment
. En resumen, los usuarios y los implementadores del DOM deben darse cuenta de que los nodos Attr
tienen algunas cosas en común con otros objetos que heredan la interfaz Node
, pero que son al mismo tiempo bastante diferentes a ellos
El valor efectivo del atributo se determina de la siguiente manera: si se le ha asignado a ese atributo explícitamente un valor, ese valor es el valor efectivo del atributo; en caso contrario, si hay una declaración para ese atributo, y dicha declaración incluye un valor por defecto, entonces el valor por defecto es el valor efectivo del atributo; en otro caso, no existe el atributo para este elemento en el modelo de estructura mientras no se haya añadido explícitamente. Observe que el atributo Node.nodeValue
del ejemplar Attr
también puede utilizarse para obtener la versión en forma de cadena del valor o valores del atributo.
Si explícitamente no se asignó un valor al atributo en el documento pero tiene un valor por defecto proporcionado por el esquema asociado con el documento, un nodo atributo podría ser creado con el conjunto especificado
a false
. Quitar nodos de atributo para los que un valor por defecto es definido en el esquema genera un nuevo nodo atributo con el valor por defecto y el conjunto especificado
a false
. Si la validación ocurriera invocando Document.normalizeDocument()
, los nodos de atributos equivalentes especificados
a false
son vueltos al procesar de acuerdo a los valores de atributos por defecto proporcionados por el esquema. Si no hay valor por defecto asociado con este atributo en el esquema, el nodo de atributo es descartado.
En XML, donde el valor de un atributo puede contener referencias a entidades, los nodos hijos del nodo Attr
pueden ser o bien nodos Text
o EntityReference
(cuando estos están en uso; ver la descripción de EntityReference
).
El Núcleo de DOM representa todos los valores de atributos como cadenas simples, incluso si el DTD o el esquema asociado con el documento declaran algún tipo específico como Símbolo (tokenized).
La forma de normalizar el valor del atributo es realizada por la implementación DOM dependiendo del conocimiento de la implementación acerca del esquema en uso. Normalmente, los atributos value
y nodeValue
de un nodo Attr
inicialmente devuelven el valor normalizado dado por el analizador. También es en el caso de que Document.normalizeDocument()
es llamado después (asumiendo que las opciones correctas han sido establecidas). Pero este no puede ser el caso después de la mutación, independientemente de si la mutación es realizada estableciendo directamente el valor de cadena o cambiando los nodos hijos de Attr
. En particular, esto es verdadero cuando las referencias de caracteres están implicadas, considerando que esos no son representados en el DOM y ni en el impacto de la normalización del valor del atributo. De otra parte, si la implementación conoce el esquema en uso cuando el valor del atributo es cambiado, y este es diferente de un tipo de CDATA, este puede normalizarse otra vez en ese momento. Esto es verdadero sobre todo en implementaciones DOM especializadas, como implementaciones DOM SVG, que almacena los valores de atributos de forma interna diferente de una cadena.
La siguiente tabla muestra algunos ejemplos de la relación entre el valor del atributo en el documento original (atributo analizado), el valor expuesto por DOM, y la serialización del valor:
Ejemplos | Valor de Atributo Analizado | Inicial Attr.value | Valor de atributo Serializado |
---|---|---|---|
Referencia de Carácter |
"x²=5" |
"x²=5" |
"x²=5" |
Entidad de Carácter embebido |
"y<6" |
"y<6" |
"y<6" |
Nueva línea Literal entre |
"x=5 y=6" |
"x=5 y=6" |
"x=5 y=6" |
Nueva línea normalizada entre |
"x=5 y=6" |
"x=5 y=6" |
"x=5 y=6" |
Entidad e con nueva línea literal |
<!ENTITY e '... ...'> [...]> "x=5&e;y=6" | Depende de la Implementación y de las Opciones de Carga | Depende de la Implementación y de las Opciones de Carga/Guardado |
interfaz Attr : Node { readonly attribute DOMString name; readonly attribute boolean specified; attribute DOMString value; // raises(DOMException) on setting // Introducido en DOM Nivel 2: readonly attribute Element ownerElement; // Introducido en DOM Nivel 3: readonly attribute TypeInfo schemaTypeInfo; // Introducido en DOM Nivel 3: readonly attribute boolean isId; };
isId
of type boolean
, readonly, introducido en DOM Nivel 3Elemento propietario
(ownerElement) de este atributo puede ser recuperado utilizando el método Document.getElementById
. La implementación podría utilizar varios caminos para determinar si a un nodo atributo se le conoce que contenga un identificador:
Document.normalizeDocument()
, los valores del post-schema-validation infoset contributions (PSVI contributions) (Aportador de información establecida de validación de esquema de envío) son utilizados para determinar si este atributo es un atributo ID de esquema resuelto usando el esquema resuelto de ID definido en [XPointer].
Document.normalizeDocument()
,
el valor del conjunto de información (infoset) [Definición del Tipo] se utiliza para determinar si este atributo es un atributo ID resuelto DTD usando el DTD resuelto de ID definido en [XPointer].
Element.setIdAttribute()
,
Element.setIdAttributeNS()
, o
Element.setIdAttributeNode()
, es decir, es un atributo ID resuelto de usuario;
Nota: El marco de trabajo de XPointer (ver sección 3.2 en [XPointer]) considera al DOM atributo ID resuelto de usuario como parte de la definición de XPointer ID resuelto externamente.
Document.normalizeDocument()
, todos los atributos ID determinados por el usuario son reformulados y toda la información de los nodos atributos ID es reevaluada de acuerdo al esquema utilizado. Como consecuencia, si el atributo Attr.schemaTypeInfo
contiene un tipo ID, isId
siempre devolverá verdadero (true).
name
of type DOMString
, readonlyNode.localName
es distinto de null
, este atributo es un nombre cualificado.ownerElement
of type Element
, readonly, introducido en DOM Level 2Element
al que este atributo va unido o null
si este atributo no está en uso.schemaTypeInfo
of type TypeInfo
, readonly, introducido en DOM Nivel 3Document.normalizeDocument()
,
schemaTypeInfo
puede no ser fiable si el nodo fue movido.
specified
of type boolean
, readonlyTrue
si a este atributo se le asigno explícitamente un valor en el documento, false
en caso contrario. Si la aplicación cambia el valor de este nodo atributo (incluso si acaba teniendo el mismo valor que el valor por defecto) entonces este es establecido a true
. La implementación pueden manejar los atributos con valores por defecto de otros esquemas de modo similar pero las aplicaciones deben utilizar Document.normalizeDocument()
para garantizar que esta información es actualizada.
value
of type DOMString
getAttribute
en la interfaz Element
.
Text
con los contenidos no analizados de la cadena, es decir, cualquier carácter que un procesador XML pueda reconocer como etiqueta (markup) es tratada como texto literal. Ver también el método Element.setAttribute()
.
NO_MODIFICATION_ALLOWED_ERR: provocada cuando el nodo es de solo lectura. |
La interfaz Element
representa un elemento en un documento HTML o XML. Los elementos pueden tener atributos asociados a ellos; como la interfaz Element
se hereda de Node
, puede utilizarse el atributo de la interfaz genérica Node
attributes
para obtener el conjunto de todos los atributos de un elemento. Existen métodos en la interfaz Element
para obtener o bien un objeto Attr
por su nombre o bien un valor de atributo por su nombre. En XML, en el cual un valor de atributo puede contener referencias a entidades, debería obtenerse un objeto Attr
para examinar el posiblemente complejo sub-árbol que representa el valor del atributo. Por otra parte, en HTML, en el cual todos los atributos tienen valores de cadenas simples, pueden emplearse con seguridad métodos más convenientes para acceder directamente al valor de un atributo.
Nota: En DOM Nivel 2, el método normalize
es heredado de la interfaz Node
donde este fue movido.
interfaz Element : Node { readonly attribute DOMString tagName; DOMString getAttribute(in DOMString name); void setAttribute(in DOMString name, in DOMString value) raises(DOMException); void removeAttribute(in DOMString name) raises(DOMException); Attr getAttributeNode(in DOMString name); Attr setAttributeNode(in Attr newAttr) raises(DOMException); Attr removeAttributeNode(in Attr oldAttr) raises(DOMException); NodeList getElementsByTagName(in DOMString name); // Introducido en DOM Nivel 2: DOMString getAttributeNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); // Introducido en DOM Nivel 2: void setAttributeNS(in DOMString namespaceURI, in DOMString qualifiedName, in DOMString value) raises(DOMException); // Introducido en DOM Nivel 2: void removeAttributeNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); // Introducido en DOM Nivel 2: Attr getAttributeNodeNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); // Introducido en DOM Nivel 2: Attr setAttributeNodeNS(in Attr newAttr) raises(DOMException); // Introducido en DOM Nivel 2: NodeList getElementsByTagNameNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); // Introducido en DOM Nivel 2: boolean hasAttribute(in DOMString name); // Introducido en DOM Nivel 2: boolean hasAttributeNS(in DOMString namespaceURI, in DOMString localName) raises(DOMException); // Introducido en DOM Nivel 3: readonly attribute TypeInfo schemaTypeInfo; // Introducido en DOM Nivel 3: void setIdAttribute(in DOMString name, in boolean isId) raises(DOMException); // Introducido en DOM Nivel 3: void setIdAttributeNS(in DOMString namespaceURI, in DOMString localName, in boolean isId) raises(DOMException); // Introducido en DOM Nivel 3: void setIdAttributeNode(in Attr idAttr, in boolean isId) raises(DOMException); };
schemaTypeInfo
of type TypeInfo
, readonly, introducido en DOM Nivel 3tagName
of type DOMString
, readonlyNode.localName
es diferente a null
, este atributo es un nombre cualificado. Por ejemplo, en:
<elementoEjemplo id="demo"> ... </elementoEjemplo> ,
tagName
tiene el valor "elementoEjemplo"
. Obsérvese que en XML se conserva la distinción entre mayúsculas y minúsculas, como en todas las operaciones del DOM. El DOM HTML devuelve el tagName
de un elemento HTML en la forma canónica en mayúsculas, independientemente de la forma en que se presentaba en el documento fuente HTML.getAttribute
getAttributeNS
introducido en DOM Level 2null
como el parámetro de namespaceURI
si estos no desean tener espacio de nombre.
namespaceURI
of type
DOMString
localName
of type
DOMString
NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad |
getAttributeNode
getAttributeNodeNS
.
name
of type
DOMString
nodeName
) del atributo a obtener.getAttributeNodeNS
introducido en DOM Level 2Attr
por nombre local y URI de espacio de nombre.null
como parámetro de namespaceURI
para los métodos si estos no desean tener espacio de nombre.
namespaceURI
of type
DOMString
localName
of type
DOMString
NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad |
getElementsByTagName
NodeList
de todos los Elementos
descendentes con un nombre de etiqueta dado, en el orden del documento.
name
of type
DOMString
Una lista de los nodos |
getElementsByTagNameNS
introducido en DOM Level 2NodeList
de todos los Elementos
descendentes con un nombre local y URI de espacio de nombre dado en el orden del documento.
namespaceURI
of type
DOMString
localName
of type
DOMString
NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad |
hasAttribute
introducido en DOM Level 2true
cuando un atributo con un nombre dado está especificado en este elemento o tiene un valor por defecto, false
en caso contrario.
name
of type
DOMString
|
|
hasAttributeNS
introducido en DOM Level 2true
cuando un atributo con un nombre local y URI de espacio de nombre dado está especificado en este elemento o tiene un valor por defecto, false
en caso contrario.null
como parámetro namespaceURI
para los métodos si estos no quieren tener un espacio de nombre.
namespaceURI
of type
DOMString
localName
of type
DOMString
|
|
NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad |
removeAttribute
Document.normalizeDocument()
para garantizar que esta información sea actualizada.removeAttributeNS
.name
of type
DOMString
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. |
removeAttributeNS
introducido en DOM Level 2Document.normalizeDocument()
para garantizar que esta información se actualiza.null
como el parámetro namespaceURI
para los métodos si estos no desean tener espacios de nombre.
namespaceURI
of type
DOMString
localName
of type
DOMString
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad |
removeAttributeNode
Attr
quitado es definido en el DTD, un nuevo nodo aparece inmediatamente con el valor por defecto así como con el URI de espacio de nombre, nombre local correspondientes, y el prefijo cuando sea aplicable. Las implementaciones pueden manejar los valores por defecto desde otros esquemas similares pero las aplicaciones deberían utilizar Document.normalizeDocument()
para garantizar que esta información se actualiza.
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NOT_FOUND_ERR: provocada si |
setAttribute
Attr
y además nodos Text
y EntityReference
, construir el sub-árbol apropiado, y usar setAttributeNode
para asignarlo como valor del atributo.setAttributeNS
.
INVALID_CHARACTER_ERR: provocada si el nombre especificado no es un nombre XML de acuerdo con la versión XML en uso especificada en el atributo NO_MODIFICATION_ALLOWED_ERR: provocada si el nodo es de solo lectura. |
setAttributeNS
introducido en DOM Level 2qualifiedName
(nombre cualificado), y su valor es cambiado por el valor
del parámetro. Este valor es una simple cadena; no es analizada en el momento de establecerla. De modo que cualquier código o markup (como por ejemplo sintaxis que debe ser reconocida como una referencia a una entidad) es tratada como texto literal, y la implementación debe transformarlo en secuencias de escape de forma apropiada al producir su salida. Para asignar a un atributo un valor que contenga referencias a entidades, el usuario puede crear un nodo Attr
y además nodos Text
y EntityReference
, construir el sub-árbol apropiado, y utilizar setAttributeNodeNS
o setAttributeNode
para asignarlo como valor del atributo.null
como parámetro del namespaceURI
para los métodos si estos no desean tener espacio de nombre.
namespaceURI
of type
DOMString
qualifiedName
of type
DOMString
value
of type
DOMString
INVALID_CHARACTER_ERR: provocada si el nombre cualificado especificado no es un nombre XML de acuerdo a la versión XML en uso especificado en el atributo NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NAMESPACE_ERR: provocada si el NOT_SUPPORTED_ERR: Puede ser provocada si la implementación no soporta la funcionalidad |
setAttributeNode
nodeName
) ya está presente en ese elemento, este es reemplazado por el nuevo. Reemplazar un nodo atributo por si mismo no tiene efecto.setAttributeNodeNS
.
WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. INUSE_ATTRIBUTE_ERR: provocada si |
setAttributeNodeNS
introducido en DOM Level 2null
como parámetro del URI de espacio de nombre
para los métodos si estos no desean tener espacio de nombre.
Si el atributo |
WRONG_DOCUMENT_ERR: provocada si NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. INUSE_ATTRIBUTE_ERR: provocada si NOT_SUPPORTED_ERR: Puede se provocada si la implementación no soporta la funcionalidad |
setIdAttribute
introducido en DOM Nivel 3isId
es true
, este método declara que el atributo especificado es un Atributo ID decidido por el usuario. Este afecta al valor de Attr.isId
y al comportamiento de Document.getElementById
, pero no cambia ningún esquema que puede estar en uso, en particular este no afecta a Attr.schemaTypeInfo
del nodo especificado Attr
. Usa el valor false
para el parámetro isId
para no declarar un atributo que será un atributo ID decidido por el usuario.
setIdAttributeNS
.
name
of type
DOMString
isId
of type
boolean
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NOT_FOUND_ERR: provocada si el nodo especificado no es un atributo de este elemento. |
setIdAttributeNS
introducido en DOM Nivel 3isId
es true
, este método declara el atributo especificado para ser un atributo ID decidido por el usuario. Este afecta al valor de Attr.isId
y al comportamiento de Document.getElementById
, pero no cambia ningún esquema que pueda ser usado, en particular este no afecta al Attr.schemaTypeInfo
del nodo Attr
especificado. Usa el valor false
para el parámetro isId
para declarar un atributo que no es un atributo ID decidido por el usuario.
namespaceURI
of type
DOMString
localName
of type
DOMString
isId
of type
boolean
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NOT_FOUND_ERR: provocada si el nodo especificado no es un atributo de este elemento. |
setIdAttributeNode
introducido en DOM Nivel 3isId
es true
, este método declara que el atributo especificado es un atributo ID designado por el usuario. Este afecta al valor de Attr.isId
y al comportamiento de Document.getElementById
, pero no cambia ningún esquema que pueda ser usado, en particular esto no afecta al Attr.schemaTypeInfo
del nodo Attr
especificado. Usa el valor false
para el parámetro isId
para declarar un atributo que no es un atributo ID designado por el usuario.
idAttr
of type
Attr
isId
of type
boolean
NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. NOT_FOUND_ERR: provocada si el nodo especificado no es un atributo de este elemento. |
La interfaz Text
es heredada de CharacterData
y representa el contenido textual (los llamados datos de caracteres en XML) de un Element
o Attr
. Si no hay código dentro de los contenidos de un elemento, el texto está contenido en un solo objeto que implementa la interfaz Text
que es el único hijo del elemento. Si hay código, este es analizado dentro de la información de los elementos (elementos, comentarios, etc.) y nodos Text
que forma la lista de hijos del elemento.
Cuando se dispone un documento por primera vez a través del DOM, hay un solo nodo Text
para cada bloque de texto. Los usuarios pueden crear nodos Text
adyacentes que representen los contenidos de un elemento dado sin ningún código intermedio, pero debería recordar que no hay manera de representar las separaciones entre estos nodos en XML o HTML, de modo que (en general) no persistirán entre sesiones de edición del DOM. El método Node.normalize()
combina estos objetos Text
adyacentes en un solo nodo para cada bloque de texto.
No se realiza ninguna comprobación léxica sobre el contenido de un nodo Text
y, dependiendo de la posición del documento, algunos caracteres deben ser escapados durante la serialización utilizando referencias de caracteres; por ejemplo los caracteres "<&" si el contenido textual es parte de un elemento o de un atributo, la secuencia de caracteres "]]>" cuando es parte de un elemento, las comillas dobles " o el apostrofe ' cuando es parte de un atributo.
interfaz Text : CharacterData { Text splitText(in unsigned long offset) raises(DOMException); // Introducido en DOM Nivel 3: readonly attribute boolean isElementContentWhitespace; // Introducido en DOM Nivel 3: readonly attribute DOMString wholeText; // Introducido en DOM Nivel 3: Text replaceWholeText(in DOMString content) raises(DOMException); };
isElementContentWhitespace
of type boolean
, readonly, introducido en DOM Nivel 3Document.normalizeDocument()
.wholeText
of type DOMString
, readonly, introducido en DOM Nivel 3Text
lógicamente nodos de texto adyacentes a este nodo, concatenados en el orden del documento.wholeText
en el nodo Text
que contiene "bar" devuelve "barfoo", mientras que en el nodo Text
que contiene "foo" devuelve "barfoo".
Figura: barTextNode.wholeText el valor es "barfoo" [SVG 1.0 versión]
replaceWholeText
introducido en DOM Nivel 3null
, cuando el texto a reemplazar es una cadena vacíaText
del mismo tipo (Text
o CDATASection
) al del nodo actual insertado en la posición del reemplazo.replaceWholeText
en el nodo Text
que contiene "bar" con "yo" en el argumento resulta lo siguiente:
Figura: barTextNode.replaceWholeText("yo") modifica el contenido textual de barTextNode con "yo" [SVG 1.0 versión]
EntityReference
son descendentes de solo lectura, el EntityReference
debe ser quitado en lugar de los nodos de solo lectura. Si algún EntityReference
que será quitado tiene descendentes que no sean nodos EntityReference
, Text
, o CDATASection
, el método replaceWholeText
debe fallar antes de la realización de cualquier modificación del documento, mostrando un DOMException
con el código NO_MODIFICATION_ALLOWED_ERR
.replaceWholeText
en el nodo Text
que contiene "bar" falla, porque el nodo EntityReference
"ent" contiene un nodo Element
el cual no puede ser quitado.
Figura: barTextNode.replaceWholeText("yo") muestra un NO_MODIFICATION_ALLOWED_ERR DOMException [SVG 1.0 versión]
content
of type
DOMString
Text
reemplazado.
El nodo |
NO_MODIFICATION_ALLOWED_ERR: provocada si uno de los nodos |
splitText
offset
especificado, manteniendo a ambos en el árbol como hermanos. Después de la división este nodo contendrá todos los datos/contenido hasta el punto offset
. Un nuevo nodo del mismo tipo, que contiene todos los datos/contenido desde y después del punto offset
, es devuelto. Si el nodo original tenía nodos padre, el nuevo nodo es insertado como el hermano siguiente del nodo original. Cuando el offset
es igual a la longitud de este nodo, el nuevo nodo no tiene datos.
offset
of type
unsigned long
0
.
El nuevo nodo, del mismo tipo que este nodo. |
INDEX_SIZE_ERR: provocada si el offset especificado es negativo o mayor que el número de unidades de 16-bit de NO_MODIFICATION_ALLOWED_ERR: provocada si este nodo es de solo lectura. |
Esta interfaz es heredada de CharacterData
y representa el contenido de un comentario, es decir, todos los caracteres entre el '<!--
' inicial y el '-->
' final. Obsérvese que esta es la definición de un comentario en XML, y, en la práctica, en HTML, aunque algunas herramientas HTML pueden implementar la estructura completa de comentarios SGML.
No se realiza ningún chequeo en el contenido de un comentario y es por lo tanto posible tener la secuencia de caracteres "--"
(doble-guión) en el contenido, el cual es ilegal en el comentario por la sección 2.5 de [XML 1.0]. La presencia de esta secuencia de caracteres debe generar un error grave durante la serialización.
interfaz Comment : CharacterData { };
La interfaz TypeInfo
representa el tipo referenciado de nodos Element
o Attr
, especificado en los esquemas asociados con el documento. El tipo es un par de propiedades URI de espacio de nombre y nombre, y depende del esquema del documento.
Si el esquema del documento es un XML DTD [XML 1.0], los valores están compuesto por los siguientes:
Attr
, typeNamespace
es "http://www.w3.org/TR/REC-xml"
y el typeName
representa la propiedad [tipo de atributo] en el [Establecer Información XML]. Si no hay declaración para el atributo, typeNamespace
y typeName
son null
.
Element
, typeNamespace
y typeName
son null
.
Si el esquema del documento es un Esquema XML [Parte 1 de Esquemas XML], los valores son computados así usando el post-schema-validation infoset contributions (también llamado aportación PSVI) (Aportador de información establecida de validación de esquema de envío):
null
.
Nota: En el momento de la escritura, la especificación del Esquema XML no requiere la exposición del tipo declarado. Así, las implementaciones DOM podrían decidir no proporcionar el tipo de información si la validez no es válida.
Nota:
Otros lenguajes de esquema están fuera del alcance de W3C y por lo tanto deberían definir como representar su sistema de tipos utilizando TypeInfo
.
// Introducido en DOM Nivel 3: interfaz TypeInfo { readonly attribute DOMString typeName; readonly attribute DOMString typeNamespace; // DerivationMethods const unsigned long DERIVATION_RESTRICTION = 0x00000001; const unsigned long DERIVATION_EXTENSION = 0x00000002; const unsigned long DERIVATION_UNION = 0x00000004; const unsigned long DERIVATION_LIST = 0x00000008; boolean isDerivedFrom(in DOMString typeNamespaceArg, in DOMString typeNameArg, in unsigned long derivationMethod); };
Estos son los valores disponibles para el parámetro derivationMethod
usados por el método TypeInfo.isDerivedFrom()
. Este es un conjunto de posibles tipos de derivación, y los valores representan las posiciones en bit. Si un bit en el parámetro derivationMethod
se establece a 1
, el tipo correspondiente de derivación será tenida en cuenta evaluando la derivación entre la referencia del tipo de definición y el otro tipo de definición. Cuando se utiliza el método isDerivedFrom
, combinando todos ellos en el parámetro derivationMethod
es equivalente a invocar el método para cada uno de ellos separadamente y combinando los resultados con la función OR booleana. Esta especificación solo define el tipo de derivación para Esquemas XML.
Además de los tipos de derivación de la lista de abajo, por favor observe que:
xsd:anyType
.
xsd:anySimpleType
por restricción.
xsd:anySimpleType
por restricción.
DERIVATION_EXTENSION
DERIVATION_LIST
DERIVATION_RESTRICTION
o DERIVATION_EXTENSION
, T2 es sacada de la otra definición de tipo por DERIVATION_RESTRICTION
, T1 tiene {variedad} la lista, y T2 es la (definición de tipo de elemento). observar que T1 podría ser igual a la definición de tipo de referencia, y T2 podría ser igual a otra definición de tipo.
DERIVATION_RESTRICTION
DERIVATION_UNION
DERIVATION_RESTRICTION
o DERIVATION_EXTENSION
, T2 es sacada de otra definición de tipo por DERIVATION_RESTRICTION
, T1 tiene {la variedad} la unión, y una de las definiciones del tipo miembro es T2. Observe que T1 podría ser igual que la definición del tipo referencia, y T2 podía ser igual que otra definición de tipo.
typeName
of type DOMString
, readonlynull
si es desconocido.
typeNamespace
of type DOMString
, readonlynull
si el elemento no tiene declaración o si no hay disponible información alguna del espacio de nombre.
isDerivedFrom
TypeInfo
en el método que se está llamando, y la otra definición de tipo, esto es el que se pasa como parámetro.
typeNamespaceArg
of type
DOMString
typeNameArg
of type
DOMString
derivationMethod
of type
unsigned long
|
Si el esquema del documento es un DTD o no es un esquema asociado con el documento, este método siempre devolverá |
Cuando asociamos una clave a un objeto en un nodo utilizando Node.setUserData()
la aplicación puede proporcionar un manejador que obtenga dicho objeto cuando el objeto asociado al nodo va a ser clonado, importado o renombrado. Esto puede ser usado por la aplicación para implementar distintos comportamientos respecto a los datos asociados a los nodos del DOM. Esta interfaz define esos manejadores.
// Introducido en DOM Nivel 3: interfaz UserDataHandler { // OperationType const unsigned short NODE_CLONED = 1; const unsigned short NODE_IMPORTED = 2; const unsigned short NODE_DELETED = 3; const unsigned short NODE_RENAMED = 4; const unsigned short NODE_ADOPTED = 5; void handle(in unsigned short operation, in DOMString key, in DOMUserData data, in Node src, in Node dst); };
Un número entero indicando el tipo de operación que se está realizando sobre un nodo.
NODE_ADOPTED
Document.adoptNode()
.NODE_CLONED
Node.cloneNode()
.NODE_DELETED
Nota: Esto puede no ser soportado o puede no ser seguro en ciertos entornos, tales como Java, donde la implementación no tiene un control real cuando los objetos son eliminados realmente.
NODE_IMPORTED
Document.importNode()
.NODE_RENAMED
Document.renameNode()
.handle
UserDataHandler
. El efecto de lanzar excepciones del manejador depende de la implementación DOM.
operation
of type
unsigned short
key
of type
DOMString
data
of type
DOMUserData
src
of type
Node
null
cuando el nodo está siendo eliminado.dst
of type
Node
null
.
DOMError
es un interfaz que describe un error.
// Introducido en DOM Nivel 3: interfaz DOMError { // ErrorSeverity const unsigned short SEVERITY_WARNING = 1; const unsigned short SEVERITY_ERROR = 2; const unsigned short SEVERITY_FATAL_ERROR = 3; readonly attribute unsigned short severity; readonly attribute DOMString message; readonly attribute DOMString type; readonly attribute DOMObject relatedException; readonly attribute DOMObject relatedData; readonly attribute DOMLocator location; };
Un número entero que indica la gravedad del error.
SEVERITY_ERROR
DOMError
es un error. Un SEVERITY_ERROR
puede no causar la parada del proceso si se puede recuperar del error, a menos que DOMErrorHandler.handleError()
devuelva false
.SEVERITY_FATAL_ERROR
DOMError
es un error grave. Un SEVERITY_FATAL_ERROR
causaría la detención normal del procesamiento. El valor devuelto de DOMErrorHandler.handleError()
es ignorado a menos que la implementación decida continuar, en tal caso el comportamiento es indefinido.SEVERITY_WARNING
DOMError
es una advertencia. Un SEVERITY_WARNING
no causará la parada del procesamiento, a menos que DOMErrorHandler.handleError()
devuelva false
.location
of type DOMLocator
, readonlymessage
of type DOMString
, readonlyrelatedData
of type DOMObject
, readonlyDOMError.type
depende de si hay algunos datos.
relatedException
of type DOMObject
, readonlyseverity
of type unsigned short
, readonlySEVERITY_WARNING
, SEVERITY_ERROR
, o SEVERITY_FATAL_ERROR
.type
of type DOMString
, readonlyDOMString
indicando la relación de datos que se espera en relatedData
. Los usuarios deberían referirse a la especificación del error en orden a encontrar su tipo DOMString
y definiciones relatedData
si las hay.
Nota:
Por ejemplo, Document.normalizeDocument()
genera alertas cuando el parámetro "split-cdata-sections" está en uso. Por lo tanto, el método genera un SEVERITY_WARNING
con type
"cdata-sections-splitted"
y el primer nodo CDATASection
en el orden del documento resultante de la división es devuelto por el atributo relatedData
.
DOMErrorHandler
es una interfaz de rellamada que la implementación DOM puede llamar cuando se reportan errores que ocurren mientras se procesan datos XML, o cuando se realiza algún otro procesamiento (por ejemplo, validación de un documento). Un objeto DOMErrorHandler
pude ser adjuntado a un Document
usando el "error-handler" (manejador de error) sobre la interfaz DOMConfiguration
. Si necesita ser reportado más de un error durante una operación, la secuencia y números de los errores pasados al manejador de errores depende de la implementación.
Las aplicaciones que están usando la implementación DOM se espera que implementen esta interfaz.
// Introducido en DOM Nivel 3: interfaz DOMErrorHandler { boolean handleError(in DOMError error); };
handleError
true
.
error
of type
DOMError
handleError
.
|
Si el método |
La interfaz DOMLocator
describe una localización (Por ejemplo donde ha ocurrido un error).
// Introducido en DOM Nivel 3: interfaz DOMLocator { readonly attribute long lineNumber; readonly attribute long columnNumber; readonly attribute long byteOffset; readonly attribute long utf16Offset; readonly attribute Node relatedNode; readonly attribute DOMString uri; };
byteOffset
of type long
, readonly-1
si no hay disponible byte a compensar.columnNumber
of type long
, readonly-1
si no hay disponible número de columna.lineNumber
of type long
, readonly-1
si no hay disponible número de línea.relatedNode
of type Node
, readonlynull
si no hay nodo disponible.uri
of type DOMString
, readonlynull
si no hay URI disponible.utf16Offset
of type long
, readonly-1
si no hay disponible una equivalente UTF-16.
La interfaz DOMConfiguration
representa la configuración de un documento y mantiene una tabla de parámetros reconocidos. Usando la configuración, es posible cambiar el comportamiento de Document.normalizeDocument()
, así como sustituir nodos CDATASection
con nodos Text
o especificando el tipo de esquema que debe ser utilizado cuando es requerida la validación del Document
. Los objetos DOMConfiguration
son utilizados también en [DOM Nivel 3 Cargar y Guardar] en las interfaces DOMParser
y DOMSerializer
.
Los nombres de parámetros usados por el objeto DOMConfiguration
son definidos en las partes de la especificación DOM Nivel 3. Los nombres son insensibles a las mayúsculas y las minúsculas (case-insensitive). Para evitar posibles conflictos, por acuerdo, los nombres referidos a parámetros definidos fuera de la especificación DOM deberían ser únicos. Como los parámetros son expuestos como propiedades en el Enlace de Lenguaje ECMAScript, se recomienda que los nombres sigan la sección "5.16 Identificadores" de [Unicode] incluyendo el carácter '-' (Guión-Menos) pero no es obligatorio para la implementación DOM. A las implementaciones del Núcleo de DOM Nivel 3 se les requiere que reconozcan todos los parámetros definidos en esta especificación. Algunos valores de parámetros pueden ser también requeridos para que sean soportados por la implementación. Referirse a la definición de un parámetro para saber si un valor debe ser soportado o no.
Nota: Los parámetros son iguales a las funcionalidades y propiedades usadas en SAX2 [SAX].
La lista de parámetros definidos en DOM:
"canonical-form"
true
DocumentType
(si hay alguno) del árbol, o quita declaraciones de espacios de nombre superfluas de cada elemento. Observe que esto está limitado a lo que puede ser representado en el DOM; en particular, no hay una forma para especificar el orden de atributos en DOM. Además,
true
también establecerá el estado de los parámetros indicados abajo. Los cambios posteriores del estado de uno de esos parámetros volverán la "forma canónica" de nuevo a false
.
false
:
"entidades",
"caracteres normalizados",
"secciones cdata".
true
:
"espacios de nombre",
"declaraciones de espacio de nombre",
"bien formados",
"elementos que contienen espacios en blanco".
false
"cdata-sections"
true
CDATASection
en el documento.false
CDATASection
del documento en nodos Text
. El nuevo nodo Text
es combinado con cualquier nodo Text
adyacente."check-character-normalization"
true
DOMError.type
igual a "check-character-normalization-failure" (la verificación de normalización de caracteres ha fallado).
false
"comments"
"datatype-normalization"
true
true
. Teniendo este parámetro activado cuando "validate" es false
no tiene efecto y no pasaría el esquema normalizado.
Nota: Ya que el documento contiene los resultados del procesamiento de XML 1.0, este parámetro no aplica a la normalización del valor del atributo como define la sección 3.3.3 de [XML 1.0] y se piensa que solo es para otros lenguajes de esquema Definición del Tipo de Documento (DTD).
false
"element-content-whitespace"
true
false
Text
que contienen espacios en blanco en el contenido del elemento, como describe [espacios en blanco en el contenido del elemento]. La implementación está esperando a utilizar el atributo Text.isElementContentWhitespace
para determinar si un nodo Text
debería ser descartado o no."entities"
true
EntityReference
en el documento.false
EntityReference
del documento, poniendo la expansión de la entidad directamente en su lugar. Los nodos Text
son normalizados, como define Node.normalize
. Solamente las referencias de entidades no expandidas son conservadas en el documento.
Nota:
Este parámetro no afecta a nodos Entity
.
"error-handler"
DOMErrorHandler
. Si se encuentra un error en el documento, la implementación re-llamaría al DOMErrorHandler
registrado usando este parámetro. La implementación puede proporcionar un objeto DOMErrorHandler
por defecto.
DOMError.relatedData
contendrá el nodo más cercado donde haya ocurrido el error. Si la implementación es incapaz de determinar el nodo donde ocurrió el error, DOMError.relatedData
contendrá el nodo Document
. Las mutaciones del documento que resultarán desde un manejador de errores dependerán del comportamiento en la implementación.
"infoset"
true
false
:
"validated-if-schema",
"entities",
"datatype-normalization",
"cdata-seccions".true
:
"namespace-dclarations",
"well-formed",
"element-content-whitespace",
"comments", "namespace".getParameter
devolviendo true
solamente si los parámetros individuales especificados arriba son establecidos apropiadamente.false
infoset
a false
no teniendo efecto."namespaces"
true
false
"namespace-declarations"
false
.
true
false
Node.prefix
) son conservados incluso si este parámetro es establecido a false
."normalize-characters"
true
false
"schema-location"
DOMString
que contiene una lista de URIs, separadas por espacios en blanco (los caracteres que corresponden a la S de producción no terminada definido en la sección 2.3 [XML 1.0]), eso representa otra vez el esquema con la validación que debería ocurrir, por ejemplo el esquema actual. Los tipos de esquemas referenciados en esta lista deben combinar el tipo especificado con el tipo del esquema
, si no el comportamiento de la implementación es indefinido.
schemaLocation
) en un documento de esquema (es decir usando el mecanismo import
esquema) comparten el mismo targetNamespace
, el esquema especificado por el usuario utilizando esta propiedad es el que será usado. Si dos esquemas especificados utilizando esta propiedad comparten el mismo targetNamespace
o no tienen espacio de nombre, su comportamiento depende de la implementación.
null
.
Nota:
El parámetro "schema-location"
(localización de esquema) es ignorado a no ser que el valor del parámetro "schema-type" (tipo de esquema) sea establecido. Se recomienda encarecidamente que Document.documentURI
sea fijada para que una implementación pueda resolver satisfactoriamente cualquier entidad externa referenciada.
"schema-type"
DOMString
que contiene un URI absoluto y representa el tipo de lenguaje de esquema usado para validar un documento. Observe que no se realiza una verificación léxica sobre el URI absoluto.
null
.
Nota:
Para Esquemas XML [Parte 1 de Esquemas XML], las aplicaciones deben usar el valor "http://www.w3.org/2001/XMLSchema"
. Para DTD XML [XML 1.0], las aplicaciones deben utilizar el valor "http://www.w3.org/TR/REC-xml"
. Otros lenguajes de Esquema están fuera del alcance de W3C y por lo tanto debería recomendar un URI absoluto para usar este método.
"split-cdata-sections"
true
DOMError.type
igual a "cdata-sections-splitted"
(sección cdata dividida) y un DOMError.relatedData
igual al primer nodo CDATASection
en el orden del documento resultante de la división.false
CDATASection
contiene un carácter no representable."validate"
true
true
.
Attr.specified
iguales a false
, como se especifica en la descripción de la interfaz Attr
;
Text.isElementContentWhitespace
para todos los nodos Text
;
Attr.isId
para todos los nodos Attr
;
Element.schemaTypeInfo
y Attr.schemaTypeInfo
.
Nota:
"validate-if-schema"
y "validate" son mutuamente excluyentes, estableciendo uno de ellos a true
se establecerá el otro a false
. Las aplicaciones deberían considerar también establecer el parámetro "well-formed" a true
, como predeterminado para esa opción, cuando el documento se valida.
false
true
.
"validate-if-schema"
true
true
.
Nota:
"validate-if-schema" y "validate" son mutuamente excluyentes, estableciendo uno de ellos a true
se establecerá el otro a false
.
false
true
.
"well-formed"
true
Document.xmlVersion
:
Node.nodeName
contiene caracteres no validos de acuerdo con su tipo de nodo y genera un DOMError
de tipo "wf-invalid-character-in-node-name"
(caracteres no válidos en el nombre del nodo bien formado), con un DOMError.SEVERITY_ERROR
grave, si es necesario;
Attr
, Element
, Comment
, Text
, CDATASection
tiene caracteres no válidos y genera un DOMError
de tipo "wf-invalid-character"
(caracteres no válidos bien formados), con un DOMError.SEVERITY_ERROR
grave, si es necesario;
ProcessingInstruction
contienen caracteres no válidos y genera un DOMError
de tipo "wf-invalid-character"
, con un DOMError.SEVERITY_ERROR
grave, si es necesario;
false
La resolución de los identificadores de sistema asociados con entidades se hace usando Document.documentURI
. Sin embargo, cuando la funcionalidad "LS" (Load and Save) definida en [DOM Nivel 3 Cargar y Guardar] es soportada por la implementación DOM, el parámetro "resource-resolver" puede ser también utilizado en objetos DOMConfiguration
unidos a los nodos Document
. Si este parámetro es definido, Document.normalizeDocument()
invocará el recurso para resolver en lugar de utilizar Document.documentURI
.
// Introducido en DOM Nivel 3: interfaz DOMConfiguration { void setParameter(in DOMString name, in DOMUserData value) raises(DOMException); DOMUserData getParameter(in DOMString name) raises(DOMException); boolean canSetParameter(in DOMString name, in DOMUserData value); readonly attribute DOMStringList parameterNames; };
parameterNames
of type DOMStringList
, readonlyDOMConfiguration
y al menos un valor que puede ser establecido por la aplicación. Observe que esta lista pude contener también nombres de parámetros definidos fuera de esta especificación.
canSetParameter
name
of type
DOMString
value
of type
DOMUserData
null
, el valor devuelto es true
.
|
|
getParameter
name
of type
DOMString
El objeto actual asociado con el parámetro especificado o |
NOT_FOUND_ERR: provocado cuando el nombre del parámetro no es reconocido. |
setParameter
name
of type
DOMString
value
of type
DOMUserData
null
si el usuario desea quitar el parámetro. Mientras que el valor del tipo de parámetro es definido como DOMUserData
, el tipo de objeto debe tomar el tipo definido por la definición del parámetro. Por ejemplo, si el parámetro es "error-handler", el valor debe ser del tipo DOMErrorHandler
.
NOT_FOUND_ERR: provocado cuando el nombre del parámetro no es reconocido. NOT_SUPPORTED_ERR: provocado cuando el nombre del parámetro es reconocido pero el valor requerido no puede ser establecido. TYPE_MISMATCH_ERR: provocado si el tipo de valor para este nombre del parámetro es incompatible con el tipo de valor esperado. |
Las interfaces aquí definidas forman parte del Núcleo de la especificación DOM, pero los objetos que expongan estas interfaces no se encontrarán nunca en implementaciones DOM que sólo traten con HTML.
Las interfaces de esta sección no son obligatorias. Una aplicación de DOM puede usar el método DOMImplementation.hasFeature(funcionalidad, versión)
con los valores de parámetros "XML" y "3.0" (respectivamente) para determinar si realmente este módulo es soportado o no por la implementación. En orden a soportar completamente este módulo, una implementación debe soportar también la funcionalidad del "Núcleo" definida en Interfaces Fundamentales: Módulo Núcleo y la funcionalidad "XMLVersion" con la versión "1.0" definida en Document.xmlVersion
. Por favor para información adicional vea Conformidad en esta especificación. El módulo XML de DOM Nivel 3 es compatible con los módulos XML de DOM Nivel 2 [Núcleo de DOM Nivel 2] y XML de DOM Nivel 1 [DOM Nivel 1], esto es una implementación XML de DOM Nivel 3 que devuelve true
para "XML" con la versión
número "3.0"
debe también devolver true
para esta funcionalidad
cuando el número de versión
es "2.0"
, "1.0"
, ""
o, null
.
Las secciones CDATA se usan para transformar en secuencias de escape bloques de texto que contienen caracteres que de otro modo serían considerados como código. El único delimitador reconocido en una sección CDATA es la cadena "]]>" que finaliza la sección CDATA. Las secciones CDATA no pueden anidarse. El propósito principal es la inclusión de material tal como fragmentos XML sin necesidad de escapar todos los delimitadores.
El atributo CharacterData.data
contiene el texto que está contenido en la sección CDATA. Observe que este puede contener caracteres que necesiten ser escapados fuera de la sección CDATA y que, dependiendo de la codificación de caracteres ("charset") elegida para la serialización, puede ser imposible escribir en la salida ciertos caracteres como parte de la sección CDATA.
La interfaz CDATASection
se hereda de la interfaz CharacterData
a través de la interfaz Text
. Los nodos CDATASection
adyacentes no son combinados cuando se usa el método de normalización
del la interfaz Node
.
No se realiza ninguna comprobación léxica sobre el contenido de la sección CDATA y esto hace posible tener la secuencia de caracteres "]]>"
en el contenido, lo que es ilegal en una sección CDATA según la sección 2.7 de [XML 1.0]. La presencia de esta secuencia de caracteres debe generar un error grave durante la serialización o la sección de cdata debe ser dividida antes de la serialización (vea también el parámetro "split-cdata-sections"
en la interfaz DOMConfiguration
).
Nota: Como ningún código es reconocido dentro de un CDATASection
, las referencias de caracteres numéricos no pueden ser utilizados como un mecanismo de escape en la serialización. Por lo tanto, la acción necesita ser tomada cuando se serializa un CDATASection
con una codificación de caracteres donde algunos de los caracteres contenidos no pueden ser representados. El fallo no produce un XML bien formado.
Una solución potencial en el proceso de serialización es determinar la sección CDATA antes del carácter, el carácter de salida usa una referencia de carácter o referencia de entidad, y abre una nueva sección CDATA para cualquier carácter remoto en el nodo texto. Observe, sin embargo, que algunas librerías de conversión de código en el momento de escribir no devuelven un error o excepción cuando un carácter se pierde en la codificación, haciendo que la tarea de asegurar estos datos no sea corrompida en la serialización haciéndolo más difícil.
interfaz CDATASection : Text { };
Cada Document
(documento) tiene un atributo doctype
cuyo valor es o bien null
o bien un objeto DocumentType
. La interfaz DocumentType
en el Núcleo de DOM proporciona una interfaz a la lista de entidades definidas para el documento, y poco más debido al efecto de espacios de nombre y de los distintos esfuerzos de esquemas XML en la representación del DTD no se entienden claramente a fecha de redacción de este documento.
El Nivel 3 del DOM no soporta la edición de los nodos DocumentType
. Los nodos DocumentType
son de solo lectura.
interfaz DocumentType : Node { readonly attribute DOMString name; readonly attribute NamedNodeMap entities; readonly attribute NamedNodeMap notations; // Introducido en DOM Nivel 2: readonly attribute DOMString publicId; // Introducido en DOM Nivel 2: readonly attribute DOMString systemId; // Introducido en DOM Nivel 2: readonly attribute DOMString internalSubset; };
entities
of type NamedNodeMap
, readonlyNamedNodeMap
contiene las entidades generales, tanto externas como internas, declaradas en el DTD. Los parámetros de las entidades no son contenidos. Las duplicaciones son descartadas. Por ejemplo en:
<!DOCTYPE ex SYSTEM "ex.dtd" [ <!ENTITY foo "foo"> <!ENTITY bar "bar"> <!ENTITY bar "bar2"> <!ENTITY % baz "baz"> ]> <ex/>
foo
y a la primera declaración de bar
pero no a la segunda declaración de bar
o baz
. Todos los nodos de este mapa implementan además la interfaz Entity
.entities
no pueden modificarse de ningún modo.internalSubset
of type DOMString
, readonly, introducido en DOM Level 2null
si no hay ninguno. Estos no contienen el delimitador corchetes ([ ]).
Nota: El contenido actual devuelto depende de cuanta información está disponible para la implementación. Esto pude variar dependiendo de varios parámetros, incluyendo el procesador XML que construye el documento.
name
of type DOMString
, readonlyDOCTYPE
.notations
of type NamedNodeMap
, readonlyNamedNodeMap
que contiene las notaciones declaradas en el DTD. Los duplicados se descartan. Todos los nodos en el mapa implementan además la interfaz Notation
.
notations
no pueden ser modificadas de ninguna forma.publicId
of type DOMString
, readonly, introducido en DOM Level 2systemId
of type DOMString
, readonly, introducido en DOM Level 2Esta interfaz representa una notación declara en el DTD. Una notación cualquiera declarada, por el nombre, el formato de una entidad no analizada (ver la sección 4.7 de la especificación XML 1.0 [XML 1.0]), o se usa para la declaración formal de destinos de instrucciones de procesamiento (ver la sección 2.6 de la especificación XML 1.0 [XML 1.0]). El atributo nodeName
heredado de Node
se hace igual al nombre declarado de la notación.
El Núcleo DOM no soporta la edición de nodos Notation
; son por lo tanto de solo lectura.
Un nodo Notation
no tiene ningún padre.
interfaz Notation : Node { readonly attribute DOMString publicId; readonly attribute DOMString systemId; };
publicId
of type DOMString
, readonlynull
.
systemId
of type DOMString
, readonlynull
. Esto puede o no ser un URI absoluto.Esta interfaz representa una entidad conocida, analizada o no, en un documento XML. Obsérvese que esto modeliza la entidad en si misma no la declaración de la entidad.
El atributo nodeName
que está heredado de Node
contiene el nombre de la entidad.
Un procesador XML puede optar por expandir completamente las entidades antes de pasar el modelo estructurado al DOM; en este caso no habrá ningún nodo EntityReference
en el árbol del documento.
XML no obliga a que un procesador XML no validado lea y procese las declaraciones de entidades hechas en el subconjunto externo o declaradas en entidades paramétricas externas. Esto significa que algunas clases de aplicaciones no necesitan expandir las entidades analizadas declaradas en el subconjunto externo, y que el valor por el que se reemplaza la entidad puede no estar disponible. Cuando el texto de reemplazo está disponible, la lista de nodos hijos del nodo Entity
correspondiente representa la estructura del valor de reemplazo. En caso contrario, la lista de hijos está vacía.
El Nivel 3 de DOM no soporta la edición de los nodos Entity
; si un usuario quiere realizar cambios en el contenido de un Entity
, cada nodo EntityReference
relacionado ha de ser reemplazado en el modelo de estructura por un clon de los contenidos en Entity
, y entonces los cambios deseados deben realizarse en cada uno de esos clones. Todos los nodos Entity
y sus descendentes son de solo lectura.
Un nodo Entity
no tiene ningún padre.
Nota: Si al entidad contiene prefijo de espacio de nombre ilimitado, el URI de espacio de nombre
del nodo correspondiente en el subárbol del nodo Entity
es null
. Esto mismo es cierto para nodos EntityReference
que se refieran a esta entidad, cuando estas son creadas utilizando el método createEntityReference
de la interfaz Document
.
interfaz Entity : Node { readonly attribute DOMString publicId; readonly attribute DOMString systemId; readonly attribute DOMString notationName; // Introducido en DOM Nivel 3: readonly attribute DOMString inputEncoding; // Introducido en DOM Nivel 3: readonly attribute DOMString xmlEncoding; // Introducido en DOM Nivel 3: readonly attribute DOMString xmlVersion; };
inputEncoding
of type DOMString
, readonly, introducido en DOM Nivel 3null
si esta es una entidad del subconjunto externo o si es desconocida.notationName
of type DOMString
, readonlynull
.publicId
of type DOMString
, readonlynull
en caso contrario.systemId
of type DOMString
, readonlynull
en caso contrario. Esto puede ser un URI absoluto o no.xmlEncoding
of type DOMString
, readonly, introducido en DOM Nivel 3null
en caso contrario.xmlVersion
of type DOMString
, readonly, introducido en DOM Nivel 3null
en caso contrario.
Los nodos EntityReference
pueden ser utilizados para representar una referencia de una entidad en el árbol de nodos. Obsérvese que las referencias de caracteres y las referencias a entidades predefinidas son consideradas expandidas por el procesador HTML o XML de modo que los caracteres son representados por sus equivalentes Unicode más que por una referencia de entidades. Además, el procesador XML puede expandir referencias a entidades mientras construye el Document
, en lugar de proporcionar nodos EntityReference
. Si lo que hace es proporcionar tales nodos, entonces para un nodo EntityReference
que represente una referencia a una entidad conocida existe un Entity
, y el sub-árbol del nodo EntityReference
es una copia del sub-árbol del nodo Entity
. Sin embargo, lo anterior no puede ser verdadero cuando una entidad no es obligada a contener un prefijo de espacio de nombre. En tal caso, debido al prefijo de espacio de nombre la resolución depende de donde es la referencia de la entidad, los descendentes del nodo EntityReference
pueden ser obligados a un URIs de espacio de nombre diferente. Cuando un nodo EntityReference
representa una referencia a una entidad desconocida, el nodo no tiene hijos y su valor de reemplazo, cuando utiliza por ejemplo Attr.value
, está vacío.
Como con los nodos Entity
, los nodos EntityReference
y todos sus descendentes son de solo lectura.
Nota: Los nodos EntityReference
pueden causar problemas en la normalización del contenido de elementos y en el valor de atributos cuando, como en XML 1.0 y el esquema de XML, la normalización se realiza después de la referencia de la entidad son expandidos.
interfaz EntityReference : Node { };
La interfaz ProcessingInstruction
representa una "instrucción de procesamiento", utilizada en XML como medio de mantener información específica del procesador en el texto del documento.
No se realiza una verificación del contenido de la instrucción de procesamiento y por lo tanto es posible tener secuencia de caracteres "?>"
en el documento, los cuales son ilegales en la instrucción de procesamiento por la sección 2.6 de [XML 1.0]. La presencia de esta secuencia de caracteres debe generar un error grave durante la serialización.
interfaz ProcessingInstruction : Node { readonly attribute DOMString target; attribute DOMString data; // raises(DOMException) on setting };
data
of type DOMString
?>
.
NO_MODIFICATION_ALLOWED_ERR: Provocada cuando el nodo es de solo lectura. |
target
of type DOMString
, readonly