 |
 |
 |
|
|
|
Esta secci�n define un conjunto m�nimo de objetos e interfaces para acceder y manipular objetos del documento. La funcionalidad especificada en esta secci�n (la funcionalidad del N�cleo) deber�a ser suficiente para permitir a los desarrolladores de programas y a los autores de scripts web acceder y manipular contenido HTML y XML analizado dentro de productos conformes. El API del N�cleo del DOM permite tambi�n poblar un objeto Document usando �nicamente llamadas al API DOM; la creaci�n del esqueleto del documento Document y su almacenamiento persistente se deja al producto que implementa el API DOM.
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 hijos de varios tipos, mientras que otros son nodos hoja que no pueden tener nada bajo ellos en la estructura del documento. Los tipos de nodo, y los tipos de nodo que �stos pueden tener como hijos, son los siguientes:
Document -- Element (uno como m�ximo), ProcessingInstruction, Comment,
DocumentType DocumentFragment -- Element,
ProcessingInstruction, Comment,
Text, CDATASection,
EntityReference DocumentType -- sin hijosEntityReference -- Element,
ProcessingInstruction, Comment,
Text, CDATASection,
EntityReference Element -- Element,
Text, Comment,
ProcessingInstruction, CDATASection,
EntityReferenceAttr -- Text,
EntityReferenceProcessingInstruction -- sin hijosComment -- sin hijosText -- sin hijosCDATASection -- sin hijosEntity -- Element,
ProcessingInstruction, Comment,
Text, CDATASection,
EntityReferenceNotation -- sin hijosEl DOM especifica adem�s una interfaz NodeList para manejar listas ordenadas de Nodes, como los hijos de un Node o los elementos devueltos por el m�todo Element.getElementsByTagName, 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. En el DOM, NodeLists y NamedNodeMaps est�n "vivos", es decir, los cambios en la estructura subyacente del documento se reflejan en todos los NodeLists y NamedNodeMaps 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 elemento (o los elimina, o los 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 del �rbol se reflejan en todas las referencias a ese Node desde los NodeLists y los NamedNodeMaps.
La mayor�a de los APIs definidos en esta especificaci�n son interfaces m�s que clases. Eso significa que una implementaci�n concreta s�lo necesita exponer los m�todos con los nombres definidos y la operaci�n especificada, y 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 nuevas con 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 ("factory" methods) que creen ejemplares de objetos que implementen las diferentes interfaces. En el Nivel 1 del DOM, 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.
El Nivel 1 del API DOM no define una manera est�ndar de crear objetos DOMImplementation ni Document; cada implementaci�n del DOM debe proporcionar alg�n modo propietario de arrancar estas interfaces DOM, y despu�s todos los dem�s objetos pueden construirse con los m�todos Create de Document (o con cualesquiera otros m�todos que resulten convenientes).
Los APIs del N�cleo del DOM est�n dise�ados para ser compatibles con un amplio espectro de lenguajes, incluyendo tanto los lenguajes de scripts de uso general como los lenguajes m�s complejos usados principalmente por programadores profesionales. As�, los 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 memoria en absoluto, a aquellas (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 estas 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 dise�ados por el Grupo de Trabajo DOM para los lenguajes ECMAScript y Java requiere ning�n m�todo de gesti�n de memoria, pero los enlaces con el DOM que se creen para otros lenguajes (especialmente C o C++) probablemente necesitar�n tal soporte. Estas extensiones ser�n responsabilidad de aquellos que adapten el API DOM a un lenguaje espec�fico, no del Grupo de Trabajo 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 OMG como ECMAScript tienen limitaciones significativas a la hora de eliminar las ambig�edades en los nombres provenientes de espacios de nombres 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, nosotros usamos el nombre de m�todo "remove" ("retirar") cuando el m�todo cambia el modelo estructural, y el nombre del m�todo delete ("borrar") cuando el m�todo suprime algo dentro del modelo de estructura. La cosa que se borra no se devuelve. La cosa que se retira puede devolverse, cuando tenga sentido devolverla.
Las APIs del N�cleo del DOM presentan dos conjuntos un tanto diferentes de interfaces para un documento XML/XHTML: uno que 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 necesidad de especificaciones expl�citas de tipo o casts (en Java y otros lenguajes como C), o de llamadas a interfaces de petici�n en entornos COM. Estas operaciones son bastante costosas en Java y COM, y el DOM puede 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 el 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 necesarios en otras interfaces. (Por supuesto, cuando el an�lisis orientado a objetos 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 nodeName (nombre de nodo) en la interfaz Node, sigue habiendo un atributo tagName en la interfaz Element; ambos atributos deben contener el mismo valor, pero el Grupo de Trabajo considera que vale la pena soportar ambos, dadas las diferentes exigencias que debe satisfacer el API DOM.
DOMStringPara asegurar la interoperabilidad, el DOM especifica el tipo DOMString como sigue:
DOMString es una secuencia de unidades de 16 bits. Esto, en los t�rminos del IDL, pueden expresarse como:
typedef sequence<unsigned short> DOMString;
DOMString usando UTF-16 (definido en el Ap�ndice C.3 de [UNICODE] y en la Enmienda 1 de [ISO-10646]). Se ha elegido la codificaci�n UTF-16 por su amplia utilizaci�n en la industria. Obs�rvese que tanto para HTML como para XML, el conjunto de caracteres del documento (y por tanto la notaci�n de las referencias num�ricas de caracteres) est� basado en UCS [ISO-10646]. Una referencia num�rica de caracteres individual en un documento fuente puede por tanto corresponder en algunos casos a dos unidades de 16 bits en un DOMString (un sustituto de mayor peso y un sustituto de menor peso). Nota: Si bien el DOM especifica que el nombre del tipo cadena sea DOMString, los enlaces con los diferentes lenguajes pueden usar nombres diferentes. Por ejemplo, para Java DOMString se transforma al tipo String, ya que tambi�n utiliza UTF-16 como codificaci�n.wstring. Sin embargo, esa definici�n no satisfac�a las exigencias de interoperabilidad del API DOM, ya que para definir la anchura de un car�cter se basaba en una negociaci�n de la codificaci�n.El DOM tiene muchas interfaces que implican un emparejamiento de cadenas. Los procesadores de HTML generalmente asumen una normalizaci�n de nombres en may�sculas (con menor frecuencia en min�sculas) para cosas tales como elementos, mientras que XML distingue expl�citamente entre may�sculas y min�sculas. Para los prop�sitos del DOM, el emparejamiento de cadenas se realiza puramente por comparaci�n binaria entre las unidades de 16 bits de los DOMString. As�, el DOM supone que cualquier normalizaci�n tiene lugar en el procesador antes de que se construyan las estructuras del DOM.
Esto lleva a plantearse la cuesti�n de qu� normalizaciones tienen lugar exactamente. El Grupo de Trabajo I18N del W3C est� actualmente en v�as de definir exactamente qu� normalizaciones son necesarias para las aplicaciones que implementen el DOM.
Las interfaces contenidas en esta secci�n se consideran fundamentales, y deben ser completamente implementadas por todas las implementaciones conformes con el DOM, incluyendo todas las implementaciones del DOM HTML.
Las operaciones del DOM s�lo provocan excepciones en circunstancias "excepcionales", es decir, cuando una operaci�n es imposible de realizar (bien por razones l�gicas, porque se han perdido datos, o porque la implementaci�n se ha vuelto inestable). En general, los m�todos del DOM devuelven c�digos de error espec�ficos en situaciones ordinarias de procesamiento, tales como errores de exceso de rango al usar NodeList.
Las implementaciones pueden provocar otras excepciones en otras circunstancias. Por ejemplo, las implementaciones pueden provocar excepciones dependientes de la implementaci�n si se pasa un argumento null.
Algunos lenguajes y sistemas de objetos no soportan el concepto de excepci�n. Para tales sistemas las condiciones de error pueden indicarse usando mecanismos nativos para la indicaci�n de errores. Por ejemplo, para algunas implementaciones los m�todos pueden devolver c�digos de error similares a los enumerados en las descripciones de los m�todos correspondientes.
exception DOMException {
unsigned short code;
};
// ExceptionCode
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;
Un entero que indica el tipo de error generado.
| INDEX_SIZE_ERR |
Si el �ndice o el tama�o son negativos, o mayores que el valor permitido |
| DOMSTRING_SIZE_ERR |
Si el tama�o del texto especificado no cabe en un DOMString |
| HIERARCHY_REQUEST_ERR |
Si se inserta un nodo en alg�n sitio al que no pertenece |
| WRONG_DOCUMENT_ERR |
Si se usa un nodo en un documento diferente del que lo cre� (que no lo soporte) |
| INVALID_CHARACTER_ERR |
Si se especifica un car�cter inv�lido, como por ejemplo en un nombre. |
| NO_DATA_ALLOWED_ERR |
Si se especifican datos para un nodo que no soporta datos |
| NO_MODIFICATION_ALLOWED_ERR |
Si se intenta modificar un objeto que no admite modificaciones |
| NOT_FOUND_ERR |
Si se intenta hacer referencia a un nodo en un contexto en que no existe |
| NOT_SUPPORTED_ERR |
Si la implementaci�n no soporta el tipo de objeto requerido |
| INUSE_ATTRIBUTE_ERR |
Si se intenta a�adir un atributo que ya est� siendo usado en alg�n otro lugar |
La interfaz DOMImplementation proporciona un conjunto de m�todos para realizar operaciones que son independientes de cualquier ejemplar particular del modelo de objetos del documento.
El Nivel 1 del DOM no especifica ning�n modo de crear un ejemplar de documento, y por tanto la creaci�n de documentos es una operaci�n espec�fica de cada implementaci�n. Se espera que los Niveles futuros del DOM proporcionen m�todos para crear documentos directamente.
interface DOMImplementation {
boolean hasFeature(in DOMString feature,
in DOMString version);
};
hasFeaturefeature |
El nombre del paquete de la caracter�stica a comprobar. En el Nivel 1, los valores legales son "HTML" y "XML" (no se distingue entre may�sculas y min�sculas). | |
version |
Este es el n�mero de versi�n del nombre del paquete a comprobar. En el Nivel 1, versi�n 1.0, es la cadena "1.0". Cuando no se especifica la versi�n, si se soporta cualquier versi�n de la caracter�stica se devolver� el valor |
true si la caracter�stica est� implementada en la versi�n especificada, false en caso contrario.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 por ejemplo 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 puede 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 hijos del DocumentFragment sean movidos a la lista de hijos de este nodo.
Los hijos de un 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 varios nodos superiores). Por ejemplo, un DocumentFragment podr�a tener un �nico hijo y ese nodo hijo podr�a ser un nodo Text. Este modelo de estructura no representar�a ni a un documento HTML ni a un documento XML bien formado.
Cuando se inserta un DocumentFragment dentro de un Document (o en cualquier otro nodo Node que pueda tener hijos), son los hijos del DocumentFragment los que se insertan en el Node, y no el DocumentFragment. 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 insertBefore() ("insertar antes") y appendChild() ("a�adir hijo").
interface 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.
interface Document : Node {
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);
};
doctypeDocumentType) asociada con este documento. Para documentos HTML as� como para documentos XML sin una declaraci�n del tipo de documento esto devuelve null. El Nivel 1 del DOM no soporta la edici�n de la Declaraci�n del Tipo de Documento, y por tanto docType no puede modificarse de ning�n modo.implementationDOMImplementation que manipula este documento. Una aplicaci�n DOM puede usar objetos de varias implementaciones.documentElementcreateElementAttr que los representan se crean y adjuntan autom�ticamente al elemento.
tagName |
El nombre del tipo de elemento a crear. Para XML, se distingue entre may�sculas y min�sculas. Para HTML, se puede dar el |
Element.DOMExceptionINVALID_CHARACTER_ERR: Provocada si el nombre especificado contiene un car�cter inv�lido.
createDocumentFragmentDocumentFragment vac�o.
DocumentFragment.createTextNodecreateCommentcreateCDATASectionCDATASection cuyo valor es la cadena especificada.
data |
Los datos para los contenidos de la secci�n |
CDATASection.DOMExceptionNOT_SUPPORTED_ERR: Provocada si el documento es un documento HTML.
createProcessingInstructionProcessingInstruction al que se le dan las cadenas de nombre y datos especificadas.
target |
La parte destino de la instrucci�n de procesamiento. | |
data |
Los datos para el nodo. |
ProcessingInstruction.DOMExceptionINVALID_CHARACTER_ERR: Provocada si se especifica un car�cter inv�lido.
NOT_SUPPORTED_ERR: Provocada si el documento es un documento HTML.
createAttributeAttr con el nombre dado. Obs�rvese que el ejemplar Attr puede ser establecido a continuaci�n en un Element usando el m�todo setAttribute.
name |
El nombre del atributo. |
Attr.DOMExceptionINVALID_CHARACTER_ERR: Provocada si el nombre especificado contiene un car�cter inv�lido.
createEntityReferenceEntityReference. Adem�s, si la entidad referenciada es conocida, la lista de hijos del nodo EntityReference se hace igual a la del nodo Entity correspondiente.
name |
El nombre de la entidad a referenciar. |
EntityReference.DOMExceptionINVALID_CHARACTER_ERR: Provocada si el nombre especificado contiene un car�cter inv�lido.
NOT_SUPPORTED_ERR: Provocada si el documento es un documento HTML.
getElementsByTagNameNodeList de todos los Elements que tengan un nombre de etiqueta dado en el orden en que se encontrar�an al realizar un recorrido preordenado (preorder traversal) del �rbol del Document.
tagname |
El nombre de la etiqueta a emparejar. El valor especial "*" se empareja con todas las etiquetas. |
La interfaz Node es el tipo de datos primario del Modelo de Objetos del Documento. Representa un nodo individual del �rbol del documento. Si bien 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 estos nodos se provoca una excepci�n DOMException.
Los atributos nodeName, nodeValue y attributes se han incluido como un mecanismo para obtener informaci�n sobre el nodo sin tener que realizar una conversi�n expl�cita a la interfaz espec�fica derivada. En los casos en que no haya una transformaci�n obvia para estos atributos para un tipo de nodo nodeType espec�fico (p.ej., nodeValue para un elemento o attributes para un comentario), se devuelve null. Obs�rvese que las interfaces especializadas pueden contener mecanismos adicionales y m�s convenientes para obtener y establecer la informaci�n relevante.
interface 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;
readonly attribute Document ownerDocument;
Node insertBefore(in Node newChild,
in Node refChild)
raises(DOMException);
Node replaceChild(in Node newChild,
in Node oldChild)
raises(DOMException);
Node removeChild(in Node oldChild)
raises(DOMException);
Node appendChild(in Node newChild)
raises(DOMException);
boolean hasChildNodes();
Node cloneNode(in boolean deep);
};
Un entero que indica qu� tipo de nodo es �ste.
| ELEMENT_NODE |
El nodo es un |
| ATTRIBUTE_NODE |
El nodo es un |
| TEXT_NODE |
El nodo es un nodo |
| CDATA_SECTION_NODE |
El nodo es una secci�n |
| ENTITY_REFERENCE_NODE |
El nodo es una |
| ENTITY_NODE |
El nodo es una |
| PROCESSING_INSTRUCTION_NODE |
El nodo es una |
| COMMENT_NODE |
El nodo es un |
| DOCUMENT_NODE |
El nodo es un |
| DOCUMENT_TYPE_NODE |
El nodo es un |
| DOCUMENT_FRAGMENT_NODE |
El nodo es un |
| NOTATION_NODE |
El nodo es un nodo |
Los valores nodeName, nodeValue y attributes var�an seg�n el tipo de nodo seg�n se especifica a continuaci�n:
| nodeName | nodeValue | attributes | |
| Element | nombre de etiqueta (tagName) | null | NamedNodeMap |
| Attr | nombre del atributo | valor del atributo | null |
| Text | #text | contenido del nodo de texto | null |
| CDATASection | #cdata-section | contenido de la Secci�n CDATA | null |
| EntityReference | nombre de la entidad referenciada | null | null |
| Entity | nombre de la entidad | null | null |
| ProcessingInstruction | destino (target) | contenido completo excluyendo el destino | null |
| Comment | #comment | contenido del comentario | null |
| Document | #document | null | null |
| DocumentType | nombre del tipo de documento | null | null |
| DocumentFragment | #document-fragment | null | null |
| Notation | nombre de la notaci�n | null | null |
nodeNamenodeValueDOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada cuando es de s�lo lectura.
DOMExceptionDOMSTRING_SIZE_ERR: Provocada cuando devolver�a m�s caracteres de los que cabr�an en una variable DOMString de la plataforma de la implementaci�n.
nodeTypeparentNodeDocument, DocumentFragment y Attr, pueden tener un padre. Sin embargo, si un nodo acaba de ser creado y a�n no ha sido a�adido al �rbol, o si ha sido retirado del �rbol, esto es null.childNodesNodeList que contiene todos los hijos de este nodo. Si no hay hijos, esto es un NodeList que no contiene ning�n nodo. El contenido del NodeList devuelto est� "vivo", en el sentido de que, por ejemplo, los cambios en los hijos del objeto nodo a partir del cual se crearon se reflejan inmediatamente en los nodos devueltos por los m�todos de acceso de NodeList; no es una fotograf�a est�tica del contenido del nodo. Esto se cumple para todas las listas NodeList, incluyendo las que devuelve el m�todo getElementsByTagName.firstChildnull.lastChildnull.previousSiblingnull.nextSiblingnull.attributesNamedNodeMap que contiene los atributos de este nodo (si se trata de un Element), o null en cualquier otro caso. ownerDocumentDocument asociado a este nodo. Esto tambi�n es el objeto Document usado para crear nuevos nodos. Cuando este nodo es un Document esto es null.insertBeforenewChild antes del nodo hijo existente refChild. Si refChild es null, newChild se inserta al final de la lista de hijos.
Si newChild es un objeto DocumentFragment, se insertan todos sus hijos, en el mismo orden, antes de refChild. Si newChild ya est� en el �rbol, se retira primero.
newChild |
El nodo a insertar. | |
refChild |
El nodo de referencia, es decir, el nodo antes del cual debe insertarse el nuevo nodo. |
DOMExceptionHIERARCHY_REQUEST_ERR: Provocada si este nodo es de un tipo que no permite hijos del tipo del nodo newChild, o si el nodo a insertar es uno de los ascendientes de este nodo.
WRONG_DOCUMENT_ERR: Provocada si newChild fue creado a partir de un documento diferente del que cre� a este nodo.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
NOT_FOUND_ERR: Provocada si refChild no es un hijo de este nodo.
replaceChildoldChild con newChild en la lista de hijos, y devuelve el nodo oldChild. Si el newChild ya est� en el �rbol, se retira primero.
newChild |
El nuevo nodo a poner en la lista de hijos. | |
oldChild |
El nodo que se va a reemplazar en la lista. |
DOMExceptionHIERARCHY_REQUEST_ERR: Provocada si este nodo es de un tipo que no permite hijos del tipo del nodo newChild, o si el nodo a introducir es uno de los ascendientes de este nodo.
WRONG_DOCUMENT_ERR: Provocada si newChild fue creado a partir de un documento diferente del que cre� a este nodo.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
NOT_FOUND_ERR: Provocada si oldChild no es un hijo de este nodo.
removeChildoldChild de la lista de hijos, y lo devuelve como valor de retorno.
oldChild |
El nodo a retirar. |
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
NOT_FOUND_ERR: Provocada si oldChild no es un hijo de este nodo.
appendChildnewChild al final de la lista de hijos de este nodo. Si el newChild ya est� en el �rbol, se retira primero.
newChild |
El nodo a a�adir. Si es un objeto |
DOMExceptionHIERARCHY_REQUEST_ERR: Provocada si este nodo es de un tipo que no permite hijos del tipo del nodo newChild, o si el nodo a a�adir es uno de los ascendientes de este nodo.
WRONG_DOCUMENT_ERR: Provocada si newChild fue creado a partir de un documento diferente del que cre� a este nodo.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
hasChildNodestrue si el nodo tiene alg�n hijo, false si el nodo no tiene ning�n hijo.cloneNodeparentNode devuelve null).
Cuando se clona un Element se copian todos los atributos y sus valores, incluyendo aqu�llos generados por el procesador XML para representar los atributos con valores por defecto, pero este m�todo no copia ning�n texto de su contenido a menos que se trate de clon profundo, ya que el texto est� contenido en un nodo hijo de tipo Text. La clonaci�n de cualquier otro tipo de nodo devuelve simplemente una copia de este nodo.
deep |
Si es |
La interfaz NodeList proporciona la abstracci�n de un conjunto ordenado de nodos, sin definir o restringir c�mo se implementa este conjunto.
NodeList a trav�s de un �ndice entero que comienza en el 0.
interface NodeList {
Node item(in unsigned long index);
readonly attribute unsigned long length;
};
itemindex. Si index es mayor o igual que el n�mero de nodos de la lista, esto devuelve null.
index |
�ndice dentro del conjunto. |
index de la lista NodeList, o null si aqu�l no es un �ndice v�lido.lengthlength-1, ambos inclusive. Los objetos que implementan la intertaz NamedNodeMap se usan para representar conjuntos de nodos a los que se puede acceder por su nombre. Obs�rvese que NamedNodeMap no se hereda de un NodeList; en efecto, los NamedNodeMaps no se mantienen en ning�n orden particular. Tambi�n se puede acceder a los objetos contenidos en un objeto que implemente NamedNodeMap mediante un �ndice ordinal, pero esto es simplemente para permitir la enumeraci�n conveniente de los contenidos de un NamedNodeMap, y no implica que el DOM especifique un orden para estos nodos.
interface 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;
};
getNamedItemname.
name |
El nombre del nodo a obtener. |
Node (de cualquier tipo) con el nombre especificado, o null si el nombre especificado no identific� a ning�n nodo del conjunto. setNamedItemnodeName.
Como el atributo nodeName se utiliza para determinar el nombre bajo el cual debe almacenarse el nodo, no pueden almacenarse varios nodos de ciertos tipos (aquellos que tengan un valor de cadena "especial") ya que los nombres entrar�an en conflicto. Se considera que esto es preferible a permitir que se pueda dar un alias a los nodos.
arg |
Un nodo a almacenar en un mapa de nodos con nombre. El nodo ser� despu�s accesible usando el valor del atributo |
Node reemplaza a alg�n nodo existente con el mismo nombre, se devuelve el Node existente previamente; en caso contrario se devuelve null.DOMExceptionWRONG_DOCUMENT_ERR: Provocada si arg fue creado a partir de un documento diferente del que cre� al NamedNodeMap.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este NamedNodeMap es de s�lo lectura.
INUSE_ATTRIBUTE_ERR: Provocada si arg es un Attr que ya es un atributo de otro objeto Element. El usuario del DOM debe clonar expl�citamente los nodos Attr para reutilizarlos en otros elementos.
removeNamedItemAttr con un valor por defecto se reemplaza inmediatamente. Cuando este mapa NamedNodeMap contiene los atributos asociados a un elemento, tal y como se devuelve por el atributo attributes de la interfaz Node, si se sabe que el atributo retirado tiene un valor por defecto, inmediatamente aparece un atributo que contiene el valor por defecto.
name |
El nombre del nodo a retirar. |
DOMExceptionNOT_FOUND_ERR: Provocada si no hay ning�n nodo con el nombre name en el mapa.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este NamedNodeMap es de s�lo lectura.
itemindex. Si index es mayor o igual que el n�mero de nodos del mapa, esto devuelve null.
index |
�ndice dentro del mapa. |
index dentro del NamedNodeMap, o null si aqu�l no es un �ndice v�lido.lengthlength-1, ambos inclusive. La interfaz CharacterData extiende a Node con un conjunto de atributos y m�todos para acceder a datos de caracteres en el DOM. Por claridad se define este conjunto aqu� en lugar de hacerlo en cada objeto que utilice estos atributos y m�todos. No hay ning�n objeto del DOM que corresponda directamente a CharacterData, aunque Text y otros heredan su interfaz de �l. Todos los offsets de esta interfaz comienzan desde 0.
interface 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);
};
dataCharacterData. 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 estos casos, el usuario puede llamar a substringData para obtener los datos en bloques de tama�o apropiado.
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada cuando el nodo es de s�lo lectura.
DOMExceptionDOMSTRING_SIZE_ERR: Provocada cuando se devolver�an m�s caracteres de los que caben en una variable DOMString en la plataforma de la implementaci�n.
lengthdata y del m�todo substringData descrito abajo. Esto puede ser el valor cero, es decir, los nodos CharacterData pueden estar vac�os.substringDataoffset |
Offset del inicio de la subcadena a extraer. | |
count |
El n�mero de unidades de 16 bits a extraer. |
offset y count excede de la longitud length, entonces se devuelven todas las unidades de 16 bits hasta el final de los datos.DOMExceptionINDEX_SIZE_ERR: Provocada si el offset especificado es negativo o mayor que el n�mero de unidades de 16 bits de data, o si la cuenta count especificada es negativa.
DOMSTRING_SIZE_ERR: Provocada si la subcadena de texto especificada no cabe en un DOMString.
appendDatadata proporciona acceso a la concatenaci�n de data y el DOMString especificado.
arg |
El |
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
insertDataoffset |
El offset de unidades de 16 bits en el cual insertar la cadena. | |
arg |
El |
DOMExceptionINDEX_SIZE_ERR: Provocada si el offset especificado es negativo o mayor que el n�mero de unidades de 16 bits de data.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
deleteDatadata y length reflejan el cambio.
offset |
El offset a partir del cual borrar las unidades de 16 bits. | |
count |
El n�mero de unidades de 16 bits a borrar. Si la suma de |
DOMExceptionINDEX_SIZE_ERR: Provocada si el offset especificado es negativo o mayor que el n�mero de unidades de 16 bits de data, o si la cuenta count especificada es negativa.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
replaceDataoffset |
El offset a partir del cual comenzar el reemplazamiento. | |
count |
El n�mero de unidades de 16 bits a reemplazar. Si la suma de | |
arg |
El |
DOMExceptionINDEX_SIZE_ERR: Provocada si el offset especificado es negativo o mayor que el n�mero de unidades de 16 bits de data, o si la cuenta count especificada es negativa.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
La interfaz Attr representa un atributo de un objeto Element. Normalmente los valores permitidos para el atributo est�n definidos en la definici�n del tipo de documento.
Los objetos Attr heredan la interfaz Node, pero como en realidad no son nodos hijos del elemento al que describen, el DOM no los considera parte del �rbol del documento. As�, los atributos de Node parentNode, previousSibling y nextSibling tiene un valor null para los objetos Attr. El 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 caracter�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 un valor a este atributo expl�citamente, ese valor es el valor efectivo del atributo; en caso contrario, si hay una declaraci�n para este 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. Obs�rvese que el atributo nodeValue del ejemplar Attr tambi�n puede utilizarse para obtener la versi�n en forma de cadena del valor o valores del atributo.
En XML, en el cual el valor de un atributo puede contener referencias a entidades, los nodos hijos del nodo Attr proporcionan una representaci�n en la cual las referencias a entidades no son expandidas. Estos nodos hijos pueden ser o bien nodos Text o bien nodos EntityReference. Como el tipo de atributo puede ser desconocido, no hay valores de atributos de tipo simb�lico (tokenized attributes).
interface Attr : Node {
readonly attribute DOMString name;
readonly attribute boolean specified;
attribute DOMString value;
// raises(DOMException) on setting
};
namespecifiedtrue; en caso contrario, es false. Obs�rvese que la implementaci�n, y no el usuario, est� al cargo de este atributo. Si el usuario cambia el valor del atributo (incluso si acaba teniendo el mismo valor que el valor por defecto) entonces el indicador specified se conmuta autom�ticamente a true. Para especificar de nuevo que el valor tenga el valor por defecto del DTD, el usuario debe borrar el atributo. La implementaci�n dispondr� entonces un nuevo atributo con specified establecido en false y el valor por defecto (si existe).En resumen:
specified es true, y el valor es el valor asignado.
specified es false, y el valor es el valor por defecto en el DTD.value
Cuando se establece, esto crea un nodo Text con los contenidos no analizados de la cadena.
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada cuando el nodo es de s�lo lectura.
La gran mayor�a de los objetos (aparte del texto) que encuentran los autores cuando recorren un documento son con mucho nodos Element. Imaginemos el siguiente documento XML:
<elementoEjemplo id="demo"> <subelemento1/> <subelemento2><subsubelemento1/></subelemento2> </elementoEjemplo>
Si lo representamos usando el DOM, el nodo superior es un nodo Element para "elementoEjemplo", el cual contiene dos nodos Element hijos, uno para "subelemento1" y otro para "subelemento2". "subelemento1" no contiene nodos hijos.
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.
interface 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);
void normalize();
};
tagName
<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. getAttributename |
El nombre del atributo a obtener. |
Attr en forma de cadena, o la cadena vac�a si el atributo no tiene un valor especificado o por defecto.setAttributevalue. Este valor es una cadena simple, 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) se trata 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 debe crear un nodo Attr y adem�s nodos Text y EntityReference, construir el sub-�rbol apropiado, y usar setAttributeNode para asignarlo como valor del atributo.
name |
El nombre del atributo a crear o modificar. | |
value |
Valor a establecer, en forma de cadena. |
DOMExceptionINVALID_CHARACTER_ERR: Provocada si el nombre especificado contiene un car�cter inv�lido.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
removeAttributename |
El nombre del atributo a retirar. |
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
getAttributeNodesetAttributeNodenewAttr |
El nodo |
newAttr reemplaza a un atributo existente con el mismo nombre, se devuelve el nodo Attr previamente existente. En caso contrario, se devuelve null.DOMExceptionWRONG_DOCUMENT_ERR: Provocada si newAttr fue creado a partir de un documento diferente del cre� al elemento.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
INUSE_ATTRIBUTE_ERR: Provocada si newAttr ya es un atributo de otro objeto Element. El usuario del DOM debe clonar expl�citamente los nodos Attr para reutilizarlos en otros elementos.
removeAttributeNodeoldAttr |
El nodo |
Attr que ha sido retirado.DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
NOT_FOUND_ERR: Provocada si oldAttr no es un atributo del elemento.
getElementsByTagNameNodeList de todos los elementos descendientes con un nombre de etiqueta dado, en el orden en que se encontrar�an normalmente al realizar un recorrido en preorden del �rbol del Element.
name |
El nombre de la etiqueta a emparejar. El valor especial "*" se empareja con todas las etiquetas. |
Element emparejados.normalizeText contenidos en todos los niveles del sub-�rbol que queda por debajo de este Element en forma "normal", en la cual �nicamente el c�digo (p.ej., etiquetas, comentarios, instrucciones de procesamiento, secciones CDATA y referencias a entidades) separa a los nodos Text. Es decir, no hay nodos Text adyacentes. Esto puede utilizarse para asegurarse de que la vista DOM de un documento es la misma que si se guardara y recargara, y es �til cuando deben realizarse operaciones (tales como b�squedas XPointer) que dependen de una estructura de �rbol particular del documento.La interfaz Text 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 y que es el �nico hijo del elemento. Si hay c�digo, se traduce en una lista de hijos del elemento.
Cuando se dispone un documento por primera vez a trav�s del DOM, hay s�lo un nodo Text por 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�an recordar que no hay manera de representar las separaciones entre estos nodos en XML o en HTML, de modo que, en general, no persistir�n entre sesiones de edici�n del DOM. El m�todo normalize() de Element combina estos objetos Text adyacentes en un solo nodo para cada bloque de texto; se recomienda hacer esto antes de emplear operaciones que dependan de una estructura particular del documento, como la navegaci�n con XPointers.
interface Text : CharacterData {
Text splitText(in unsigned long offset)
raises(DOMException);
};
splitTextText en dos nodos Text por el offset especificado, manteniendo a ambos en el �rbol como hermanos. Este nodo contendr� entonces todos los datos hasta el punto offset. Y el nuevo nodo Text, que se inserta como el siguiente hermano de este nodo, contendr� todo el contenido a partir del punto offset incluido.
offset |
El offset de la unidad de 16 bits en el cual se producir� la divisi�n, comenzando en cero. |
Text.DOMExceptionINDEX_SIZE_ERR: Provocada si el offset especificado es negativo o mayor que el n�mero de unidades de 16 bits de data.
NO_MODIFICATION_ALLOWED_ERR: Provocada si este nodo es de s�lo lectura.
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.
interface Comment : CharacterData {
};
Las interfaces aqu� definidas forman parte del N�cleo del Nivel 1 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. Como tales, las implementaciones de DOM s�lo para HTML no necesitan tener objetos que implementen estas interfaces.
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 transformar todos los delimitadores en secuencias de escape.
El atributo DOMString del nodo Text contiene el texto que est� contenido en la secci�n CDATA. Obs�rvese que �sta puede contener caracteres que necesiten ser transformados en secuencias de escape fuera de secciones 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 una 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 Element.normalize().
interface CDATASection : Text {
};
Todo documento Document tiene un atributo doctype cuyo valor es o bien null o bien un objeto DocumentType. La interfaz DocumentType del N�cleo del Nivel 1 del DOM proporciona una interfaz a la lista de entidades definidas para el documento, y poco m�s, debido a que el efecto de los espacios de nombres y de los distintos esfuerzos de esquemas XML en la representaci�n del DTD no se entienden claramente a fecha de la redacci�n de este documento.
El Nivel 1 del DOM no soporta la edici�n de los nodos DocumentType.
interface DocumentType : Node {
readonly attribute DOMString name;
readonly attribute NamedNodeMap entities;
readonly attribute NamedNodeMap notations;
};
nameDOCTYPE.entitiesNamedNodeMap que contiene las entidades generales, tanto externas como internas, declaradas en el DTD. Los duplicados se descartan. Por ejemplo, en:
<!DOCTYPE ex SYSTEM "ex.dtd" [ <!ENTITY foo "foo"> <!ENTITY bar "bar"> <!ENTITY % baz "baz"> ]> <ex/>la interfaz proporciona acceso a
foo y a bar, pero no a baz. Todos los nodos de este mapa implementan adem�s la interfaz Entity.
El Nivel 1 del DOM no soporta la edici�n de entidades, y por tanto las entities no pueden modificarse de ning�n modo.
notationsNamedNodeMap que contiene las notaciones declaradas en el DTD. Los duplicados se descartan. Todos los nodos de este mapa implementan adem�s la interfaz Notation.
El Nivel 1 del DOM no soporta la edici�n de notaciones, y por tanto las notations no pueden modificarse de ning�n modo.
Esta interfaz representa una notaci�n declarada en el DTD. Una notaci�n o bien declara, por el nombre, el formato de una entidad no analizada (ver la secci�n 4.7 de la especificaci�n de XML 1.0), o bien 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). El atributo nodeName heredado de Node se hace igual al nombre declarado de la notaci�n.
El Nivel 1 del DOM no soporta la edici�n de nodos Notation; son por lo tanto de s�lo lectura.
Un nodo Notation no tiene ning�n padre.
interface Notation : Node {
readonly attribute DOMString publicId;
readonly attribute DOMString systemId;
};
publicIdnull.systemIdnull.Esta interfaz representa una entidad, analizada o no analizada, en un documento XML. Obs�rvese que esto modeliza la entidad en s� misma, no la declaraci�n de la entidad. La modelizaci�n de la declaraci�n Entity se ha dejado para un Nivel posterior de la especificaci�n del DOM.
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 de estructura 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 validador 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 valor de reemplazamiento est� disponible, la lista de nodos hijos del nodo Entity correspondiente representa la estructura del texto de reemplazamiento. En caso contrario, la lista de hijos est� vac�a.
La resoluci�n de los hijos de la entidad (el valor de reemplazamiento) puede ser evaluada de manera laxa; se supone que las acciones del usuario (tales como llamar al m�todo childNodes del nodo Entity) activan la evaluaci�n.
El Nivel 1 del DOM no soporta la edici�n de nodos Entity. Si un usuario quiere hacer cambios en los contenidos de un objeto Entity, todos los nodos EntityReference relacionados se deben reemplazar en el modelo de estructura por un clon de los contenidos de la entidad, y los cambios deseados deben realizarse en cada uno de esos clones. Todos los descendientes de un nodo Entity son de s�lo lectura.
Un nodo Entity no tiene ning�n padre.
interface Entity : Node {
readonly attribute DOMString publicId;
readonly attribute DOMString systemId;
readonly attribute DOMString notationName;
};
publicIdnull.systemIdnull.notationNamenull.
Los objetos EntityReference se pueden insertar en el modelo de estructura cuando hay una referencia a una entidad en el documento fuente, o cuando el usuario desea insertar una referencia a una entidad. Obs�rvese que las referencias de caracteres y las referencias a entidades predefinidas se consideran expandidas por el procesador HTML o XML de modo que los caracteres son representados por su equivalente Unicode m�s que por una referencia de entidades. Adem�s, el procesador XML puede expandir completamente las referencias a entidades mientras construye el modelo de estructura, en lugar de proporcionar objetos EntityReference. Si lo que hace es proporcionar estos objetos, entonces, para un nodo EntityReference dado, puede ser que no haya ning�n nodo Entity que represente la entidad referenciada. Pero si existe tal Entity, entoces la lista de hijos del nodo EntityReference es la misma que la del nodo Entity. Como con el nodo Entity, todos los descendientes de EntityReference son de s�lo lectura.
La resoluci�n de los hijos de EntityReference (el valor de reemplazamiento de la entidad Entity referenciada) puede ser evaluada de manera laxa. Se supone que las acciones del usuario (como por ejemplo llamar al m�todo childNodes del nodo EntityReference) activan la evaluaci�n.
interface 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.
interface ProcessingInstruction : Node {
readonly attribute DOMString target;
attribute DOMString data;
// raises(DOMException) on setting
};
targetdata?>.
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: Provocada cuando el nodo es de s�lo lectura.
|
|
|