_[_W_3_C_] ************ DDooccuummeenntt OObbjjeecctt MMooddeell ((DDOOMM)) LLeevveell 33 CCoorree SSppeecciiffiiccaattiioonn ************ ********** VVeerrssiioonn 11..00 ********** ********** WW33CC RReeccoommmmeennddaattiioonn 0077 AApprriill 22000044 ********** This version: _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_T_R_/_2_0_0_4_/_R_E_C_-_D_O_M_-_L_e_v_e_l_-_3_-_C_o_r_e_-_2_0_0_4_0_4_0_7 Latest version: _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_T_R_/_D_O_M_-_L_e_v_e_l_-_3_-_C_o_r_e Previous version: _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_T_R_/_2_0_0_4_/_P_R_-_D_O_M_-_L_e_v_e_l_-_3_-_C_o_r_e_-_2_0_0_4_0_2_0_5_/ Editors: Arnaud Le Hors, IBM Philippe Le Hégaret, W3C Lauren Wood, SoftQuad, Inc. (WG Chair emerita, for DOM Level 1 and 2) Gavin Nicol, Inso EPS (for DOM Level 1) Jonathan Robie, Texcel Research and Software AG (for DOM Level 1 and 2) Mike Champion, Arbortext and Software AG (for DOM Level 1 and 2) Steve Byrne, JavaSoft (for DOM Level 1 until November 19, 1997) Please refer to the _ee_rr_rr_aa_tt_aa for this document, which may include some normative corrections. This document is also available in these non-normative formats: _X_M_L_ _f_i_l_e, _p_l_a_i_n _t_e_x_t, _P_o_s_t_S_c_r_i_p_t_ _f_i_l_e, _P_D_F_ _f_i_l_e, _s_i_n_g_l_e_ _H_T_M_L_ _f_i_l_e, and _Z_I_P_ _f_i_l_e. See also _t_r_a_n_s_l_a_t_i_o_n_s of this document. _C_o_p_y_r_i_g_h_t ©2004 _W_3_C® (_M_I_T, _E_R_C_I_M, _K_e_i_o), All Rights Reserved. W3C _l_i_a_b_i_l_i_t_y, _t_r_a_d_e_m_a_r_k, _d_o_c_u_m_e_n_t_ _u_s_e and _s_o_f_t_w_a_r_e_ _l_i_c_e_n_s_i_n_g rules apply. =============================================================================== ********** AAbbssttrraacctt ********** This specification defines the Document Object Model Core Level 3, a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. The Document Object Model Core Level 3 builds on the Document Object Model Core Level 2 [_D_O_M _L_e_v_e_l_ _2_ _C_o_r_e]. This version enhances DOM Level 2 Core by completing the mapping between DOM and the XML Information Set [_X_M_L_ _I_n_f_o_r_m_a_t_i_o_n_ _S_e_t], including the support for XML Base [_X_M_L_ _B_a_s_e], adding the ability to attach user information to DOM Nodes or to bootstrap a DOM implementation, providing mechanisms to resolve namespace prefixes or to manipulate "ID" attributes, giving to type information, etc. ********** SSttaattuuss ooff tthhiiss ddooccuummeenntt ********** TThhiiss sseeccttiioonn ddeessccrriibbeess tthhee ssttaattuuss ooff tthhiiss ddooccuummeenntt aatt tthhee ttiimmee ooff iittss ppuubblliiccaattiioonn.. OOtthheerr ddooccuummeennttss mmaayy ssuuppeerrsseeddee tthhiiss ddooccuummeenntt.. AA lliisstt ooff ccuurrrreenntt WW33CC ppuubblliiccaattiioonnss aanndd tthhee llaatteesstt rreevviissiioonn ooff tthhiiss tteecchhnniiccaall rreeppoorrtt ccaann bbee ffoouunndd iinn tthhee _WW_33_CC_ _tt_ee_cc_hh_nn_ii_cc_aa_ll_ _rr_ee_pp_oo_rr_tt_ss_ _ii_nn_dd_ee_xx aatt hhttttpp::////wwwwww..ww33..oorrgg//TTRR//.. This document contains the Document Object Model Level 3 Core specification and is a _W_3_C_ _R_e_c_o_m_m_e_n_d_a_t_i_o_n. It has been produced as part of the _W_3_C_ _D_O_M_ _A_c_t_i_v_i_t_y. The authors of this document are the _D_O_M_ _W_o_r_k_i_n_g_ _G_r_o_u_p participants. For more information about DOM, readers can also refer to _D_O_M_ _F_A_Q and _D_O_M_ _C_o_n_f_o_r_m_a_n_c_e _T_e_s_t_ _S_u_i_t_e_s. It is based on the feedback received during the _P_r_o_p_o_s_e_d_ _R_e_c_o_m_m_e_n_d_a_t_i_o_n period. _C_h_a_n_g_e_s_ _s_i_n_c_e_ _t_h_e_ _P_r_o_p_o_s_e_d_ _R_e_c_o_m_m_e_n_d_a_t_i_o_n_ _v_e_r_s_i_o_n and an _i_m_p_l_e_m_e_n_t_a_t_i_o_n_ _r_e_p_o_r_t are available. Please refer to the _e_r_r_a_t_a for this document, which may include some normative corrections. Comments on this document should be sent to the public mailing list _w_w_w_- _d_o_m_@_w_3_._o_r_g (_p_u_b_l_i_c_ _a_r_c_h_i_v_e). This is a stable document and has been endorsed by the W3C Membership and the participants of the DOM working group. The English version of this specification is the only normative version. See also _t_r_a_n_s_l_a_t_i_o_n_s. Patent disclosures relevant to this specification may be found on the Working Group's _p_a_t_e_n_t_ _d_i_s_c_l_o_s_u_r_e_ _p_a_g_e. This document has been produced under the _2_4 _J_a_n_u_a_r_y_ _2_0_0_2_ _C_P_P as amended by the _W_3_C_ _P_a_t_e_n_t_ _P_o_l_i_c_y_ _T_r_a_n_s_i_t_i_o_n_ _P_r_o_c_e_d_u_r_e. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with _s_e_c_t_i_o_n_ _6_ _o_f_ _t_h_e_ _W_3_C_ _P_a_t_e_n_t_ _P_o_l_i_c_y. ********** TTaabbllee ooff ccoonntteennttss ********** * _E_x_p_a_n_d_e_d_ _T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s * _W_3_C_ _C_o_p_y_r_i_g_h_t_ _N_o_t_i_c_e_s_ _a_n_d_ _L_i_c_e_n_s_e_s * _W_h_a_t_ _i_s_ _t_h_e_ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_? * _1_._ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_ _C_o_r_e * _A_p_p_e_n_d_i_x_ _A_:_ _C_h_a_n_g_e_s * _A_p_p_e_n_d_i_x_ _B_:_ _N_a_m_e_s_p_a_c_e_s_ _A_l_g_o_r_i_t_h_m_s * _A_p_p_e_n_d_i_x_ _C_:_ _I_n_f_o_s_e_t_ _M_a_p_p_i_n_g * _A_p_p_e_n_d_i_x_ _D_:_ _C_o_n_f_i_g_u_r_a_t_i_o_n_ _S_e_t_t_i_n_g_s * _A_p_p_e_n_d_i_x_ _E_:_ _A_c_c_e_s_s_i_n_g_ _c_o_d_e_ _p_o_i_n_t_ _b_o_u_n_d_a_r_i_e_s * _A_p_p_e_n_d_i_x_ _F_:_ _I_D_L_ _D_e_f_i_n_i_t_i_o_n_s * _A_p_p_e_n_d_i_x_ _G_:_ _J_a_v_a_ _L_a_n_g_u_a_g_e_ _B_i_n_d_i_n_g * _A_p_p_e_n_d_i_x_ _H_:_ _E_C_M_A_S_c_r_i_p_t_ _L_a_n_g_u_a_g_e_ _B_i_n_d_i_n_g * _A_p_p_e_n_d_i_x_ _I_:_ _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s * _G_l_o_s_s_a_r_y * _R_e_f_e_r_e_n_c_e_s * _I_n_d_e_x 07 April 2004 ************ EExxppaannddeedd TTaabbllee ooff CCoonntteennttss ************ * _E_x_p_a_n_d_e_d_ _T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s * _W_3_C_ _C_o_p_y_r_i_g_h_t_ _N_o_t_i_c_e_s_ _a_n_d_ _L_i_c_e_n_s_e_s o _W_3_C_®_ _D_o_c_u_m_e_n_t_ _C_o_p_y_r_i_g_h_t_ _N_o_t_i_c_e_ _a_n_d_ _L_i_c_e_n_s_e o _W_3_C_®_ _S_o_f_t_w_a_r_e_ _C_o_p_y_r_i_g_h_t_ _N_o_t_i_c_e_ _a_n_d_ _L_i_c_e_n_s_e o _W_3_C_®_ _S_h_o_r_t_ _S_o_f_t_w_a_r_e_ _N_o_t_i_c_e * _W_h_a_t_ _i_s_ _t_h_e_ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_? o _I_n_t_r_o_d_u_c_t_i_o_n o _W_h_a_t_ _t_h_e_ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_ _i_s o _W_h_a_t_ _t_h_e_ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_ _i_s_ _n_o_t o _W_h_e_r_e_ _t_h_e_ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_ _c_a_m_e_ _f_r_o_m o _E_n_t_i_t_i_e_s_ _a_n_d_ _t_h_e_ _D_O_M_ _C_o_r_e o _D_O_M_ _A_r_c_h_i_t_e_c_t_u_r_e o _C_o_n_f_o_r_m_a_n_c_e o _D_O_M_ _I_n_t_e_r_f_a_c_e_s_ _a_n_d_ _D_O_M_ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_s * _1_ _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_ _C_o_r_e o _1_._1_ _O_v_e_r_v_i_e_w_ _o_f_ _t_h_e_ _D_O_M_ _C_o_r_e_ _I_n_t_e_r_f_a_c_e_s # _1_._1_._1_ _T_h_e_ _D_O_M_ _S_t_r_u_c_t_u_r_e_ _M_o_d_e_l # _1_._1_._2_ _M_e_m_o_r_y_ _M_a_n_a_g_e_m_e_n_t # _1_._1_._3_ _N_a_m_i_n_g_ _C_o_n_v_e_n_t_i_o_n_s # _1_._1_._4_ _I_n_h_e_r_i_t_a_n_c_e_ _v_s_._ _F_l_a_t_t_e_n_e_d_ _V_i_e_w_s_ _o_f_ _t_h_e_ _A_P_I o _1_._2_ _B_a_s_i_c_ _T_y_p_e_s # _1_._2_._1_ _T_h_e_ _D_O_M_S_t_r_i_n_g_ _T_y_p_e # _1_._2_._2_ _T_h_e_ _D_O_M_T_i_m_e_S_t_a_m_p_ _T_y_p_e # _1_._2_._3_ _T_h_e_ _D_O_M_U_s_e_r_D_a_t_a_ _T_y_p_e # _1_._2_._4_ _T_h_e_ _D_O_M_O_b_j_e_c_t_ _T_y_p_e o _1_._3_ _G_e_n_e_r_a_l_ _C_o_n_s_i_d_e_r_a_t_i_o_n_s # _1_._3_._1_ _S_t_r_i_n_g_ _C_o_m_p_a_r_i_s_o_n_s_ _i_n_ _t_h_e_ _D_O_M # _1_._3_._2_ _D_O_M_ _U_R_I_s # _1_._3_._3_ _X_M_L_ _N_a_m_e_s_p_a_c_e_s # _1_._3_._4_ _B_a_s_e_ _U_R_I_s # _1_._3_._5_ _M_i_x_e_d_ _D_O_M_ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_s # _1_._3_._6_ _D_O_M_ _F_e_a_t_u_r_e_s # _1_._3_._7_ _B_o_o_t_s_t_r_a_p_p_i_n_g o _1_._4_ _F_u_n_d_a_m_e_n_t_a_l_ _I_n_t_e_r_f_a_c_e_s_:_ _C_o_r_e_ _M_o_d_u_l_e o _1_._5_ _E_x_t_e_n_d_e_d_ _I_n_t_e_r_f_a_c_e_s_:_ _X_M_L_ _M_o_d_u_l_e * _A_p_p_e_n_d_i_x_ _A_:_ _C_h_a_n_g_e_s o _A_._1_ _N_e_w_ _s_e_c_t_i_o_n_s o _A_._2_ _C_h_a_n_g_e_s_ _t_o_ _D_O_M_ _L_e_v_e_l_ _2_ _C_o_r_e_ _i_n_t_e_r_f_a_c_e_s_ _a_n_d_ _e_x_c_e_p_t_i_o_n_s o _A_._3_ _N_e_w_ _D_O_M_ _f_e_a_t_u_r_e_s o _A_._4_ _N_e_w_ _t_y_p_e_s o _A_._5_ _N_e_w_ _i_n_t_e_r_f_a_c_e_s o _A_._6_ _O_b_j_e_c_t_s * _A_p_p_e_n_d_i_x_ _B_:_ _N_a_m_e_s_p_a_c_e_s_ _A_l_g_o_r_i_t_h_m_s o _B_._1_ _N_a_m_e_s_p_a_c_e_ _N_o_r_m_a_l_i_z_a_t_i_o_n # _B_._1_._1_ _S_c_o_p_e_ _o_f_ _a_ _B_i_n_d_i_n_g # _B_._1_._2_ _C_o_n_f_l_i_c_t_i_n_g_ _N_a_m_e_s_p_a_c_e_ _D_e_c_l_a_r_a_t_i_o_n o _B_._2_ _N_a_m_e_s_p_a_c_e_ _P_r_e_f_i_x_ _L_o_o_k_u_p o _B_._3_ _D_e_f_a_u_l_t_ _N_a_m_e_s_p_a_c_e_ _L_o_o_k_u_p o _B_._4_ _N_a_m_e_s_p_a_c_e_ _U_R_I_ _L_o_o_k_u_p * _A_p_p_e_n_d_i_x_ _C_:_ _I_n_f_o_s_e_t_ _M_a_p_p_i_n_g o _C_._1_ _D_o_c_u_m_e_n_t_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._1_._1_ _I_n_f_o_s_e_t_ _t_o_ _D_o_c_u_m_e_n_t_ _N_o_d_e # _C_._1_._2_ _D_o_c_u_m_e_n_t_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._2_ _E_l_e_m_e_n_t_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._2_._1_ _I_n_f_o_s_e_t_ _t_o_ _E_l_e_m_e_n_t_ _N_o_d_e # _C_._2_._2_ _E_l_e_m_e_n_t_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._3_ _A_t_t_r_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._3_._1_ _I_n_f_o_s_e_t_ _t_o_ _A_t_t_r_ _N_o_d_e # _C_._3_._2_ _A_t_t_r_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._4_ _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._4_._1_ _I_n_f_o_s_e_t_ _t_o_ _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n_ _N_o_d_e # _C_._4_._2_ _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._5_ _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._5_._1_ _I_n_f_o_s_e_t_ _t_o_ _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e_ _N_o_d_e # _C_._5_._2_ _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._6_ _T_e_x_t_ _a_n_d_ _C_D_A_T_A_S_e_c_t_i_o_n_ _N_o_d_e_s_ _M_a_p_p_i_n_g # _C_._6_._1_ _I_n_f_o_s_e_t_ _t_o_ _T_e_x_t_ _N_o_d_e # _C_._6_._2_ _T_e_x_t_ _a_n_d_ _C_D_A_T_A_S_e_c_t_i_o_n_ _N_o_d_e_s_ _t_o_ _I_n_f_o_s_e_t o _C_._7_ _C_o_m_m_e_n_t_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._7_._1_ _I_n_f_o_s_e_t_ _t_o_ _C_o_m_m_e_n_t_ _N_o_d_e # _C_._7_._2_ _C_o_m_m_e_n_t_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._8_ _D_o_c_u_m_e_n_t_T_y_p_e_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._8_._1_ _I_n_f_o_s_e_t_ _t_o_ _D_o_c_u_m_e_n_t_T_y_p_e_ _N_o_d_e # _C_._8_._2_ _D_o_c_u_m_e_n_t_T_y_p_e_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._9_ _E_n_t_i_t_y_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._9_._1_ _I_n_f_o_s_e_t_ _t_o_ _E_n_t_i_t_y_ _N_o_d_e # _C_._9_._2_ _E_n_t_i_t_y_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t o _C_._1_0_ _N_o_t_a_t_i_o_n_ _N_o_d_e_ _M_a_p_p_i_n_g # _C_._1_0_._1_ _I_n_f_o_s_e_t_ _t_o_ _N_o_t_a_t_i_o_n_ _N_o_d_e # _C_._1_0_._2_ _N_o_t_a_t_i_o_n_ _N_o_d_e_ _t_o_ _I_n_f_o_s_e_t * _A_p_p_e_n_d_i_x_ _D_:_ _C_o_n_f_i_g_u_r_a_t_i_o_n_ _S_e_t_t_i_n_g_s o _D_._1_ _C_o_n_f_i_g_u_r_a_t_i_o_n_ _S_c_e_n_a_r_i_o_s * _A_p_p_e_n_d_i_x_ _E_:_ _A_c_c_e_s_s_i_n_g_ _c_o_d_e_ _p_o_i_n_t_ _b_o_u_n_d_a_r_i_e_s o _E_._1_ _I_n_t_r_o_d_u_c_t_i_o_n o _E_._2_ _M_e_t_h_o_d_s * _A_p_p_e_n_d_i_x_ _F_:_ _I_D_L_ _D_e_f_i_n_i_t_i_o_n_s * _A_p_p_e_n_d_i_x_ _G_:_ _J_a_v_a_ _L_a_n_g_u_a_g_e_ _B_i_n_d_i_n_g o _G_._1_ _J_a_v_a_ _B_i_n_d_i_n_g_ _E_x_t_e_n_s_i_o_n o _G_._2_ _O_t_h_e_r_ _C_o_r_e_ _i_n_t_e_r_f_a_c_e_s * _A_p_p_e_n_d_i_x_ _H_:_ _E_C_M_A_S_c_r_i_p_t_ _L_a_n_g_u_a_g_e_ _B_i_n_d_i_n_g o _H_._1_ _E_C_M_A_S_c_r_i_p_t_ _B_i_n_d_i_n_g_ _E_x_t_e_n_s_i_o_n o _H_._2_ _O_t_h_e_r_ _C_o_r_e_ _i_n_t_e_r_f_a_c_e_s * _A_p_p_e_n_d_i_x_ _I_:_ _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s o _I_._1_ _P_r_o_d_u_c_t_i_o_n_ _S_y_s_t_e_m_s * _G_l_o_s_s_a_r_y * _R_e_f_e_r_e_n_c_e_s o _1_ _N_o_r_m_a_t_i_v_e_ _R_e_f_e_r_e_n_c_e_s o _2_ _I_n_f_o_r_m_a_t_i_v_e_ _R_e_f_e_r_e_n_c_e_s * _I_n_d_e_x 07 April 2004 ************ WW33CC CCooppyyrriigghhtt NNoottiicceess aanndd LLiicceennsseess ************ CCooppyyrriigghhtt ©© 22000044 _WW_oo_rr_ll_dd_ _WW_ii_dd_ee_ _WW_ee_bb_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm,, ((_MM_aa_ss_ss_aa_cc_hh_uu_ss_ee_tt_tt_ss_ _II_nn_ss_tt_ii_tt_uu_tt_ee_ _oo_ff _TT_ee_cc_hh_nn_oo_ll_oo_gg_yy,, _EE_uu_rr_oo_pp_ee_aa_nn_ _RR_ee_ss_ee_aa_rr_cc_hh_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm_ _ff_oo_rr_ _II_nn_ff_oo_rr_mm_aa_tt_ii_cc_ss_ _aa_nn_dd_ _MM_aa_tt_hh_ee_mm_aa_tt_ii_cc_ss,, _KK_ee_ii_oo _UU_nn_ii_vv_ee_rr_ss_ii_tt_yy)).. AAllll RRiigghhttss RReesseerrvveedd.. This document is published under the _W_3_C_®_ _D_o_c_u_m_e_n_t_ _C_o_p_y_r_i_g_h_t_ _N_o_t_i_c_e_ _a_n_d _L_i_c_e_n_s_e. The bindings within this document are published under the _W_3_C_® _S_o_f_t_w_a_r_e_ _C_o_p_y_r_i_g_h_t_ _N_o_t_i_c_e_ _a_n_d_ _L_i_c_e_n_s_e. The software license requires "Notice of any changes or modifications to the W3C files, including the date changes were made." Consequently, modified versions of the DOM bindings must document that they do not conform to the W3C standard; in the case of the IDL definitions, the pragma prefix can no longer be 'w3c.org'; in the case of the Java language binding, the package names can no longer be in the 'org.w3c' package. =============================================================================== ********** WW33CC®® DDooccuummeenntt CCooppyyrriigghhtt NNoottiiccee aanndd LLiicceennssee ********** NNoottee:: This section is a copy of the W3C® Document Notice and License and could be found at _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_C_o_n_s_o_r_t_i_u_m_/_L_e_g_a_l_/_2_0_0_2_/_c_o_p_y_r_i_g_h_t_-_d_o_c_u_m_e_n_t_s_- _2_0_0_2_1_2_3_1. CCooppyyrriigghhtt ©© 22000044 _WW_oo_rr_ll_dd_ _WW_ii_dd_ee_ _WW_ee_bb_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm,, ((_MM_aa_ss_ss_aa_cc_hh_uu_ss_ee_tt_tt_ss_ _II_nn_ss_tt_ii_tt_uu_tt_ee_ _oo_ff _TT_ee_cc_hh_nn_oo_ll_oo_gg_yy,, _EE_uu_rr_oo_pp_ee_aa_nn_ _RR_ee_ss_ee_aa_rr_cc_hh_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm_ _ff_oo_rr_ _II_nn_ff_oo_rr_mm_aa_tt_ii_cc_ss_ _aa_nn_dd_ _MM_aa_tt_hh_ee_mm_aa_tt_ii_cc_ss,, _KK_ee_ii_oo _UU_nn_ii_vv_ee_rr_ss_ii_tt_yy)).. AAllll RRiigghhttss RReesseerrvveedd.. hhttttpp::////wwwwww..ww33..oorrgg//CCoonnssoorrttiiuumm//LLeeggaall//22000022//ccooppyyrriigghhtt--ddooccuummeennttss--2200002211223311 Public documents on the W3C site are provided by the copyright holders under the following license. By using and/or copying this document, or the W3C document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions: Permission to copy, and distribute the contents of this document, or the W3C document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on AALLLL copies of the document, or portions thereof, that you use: 1. A link or URL to the original W3C document. 2. The pre-existing copyright notice of the original author, or if it doesn't exist, a notice (hypertext is preferred, but a textual representation is permitted) of the form: "Copyright © [$date-of- document] _W_o_r_l_d_ _W_i_d_e_ _W_e_b_ _C_o_n_s_o_r_t_i_u_m, (_M_a_s_s_a_c_h_u_s_e_t_t_s_ _I_n_s_t_i_t_u_t_e_ _o_f _T_e_c_h_n_o_l_o_g_y, _E_u_r_o_p_e_a_n_ _R_e_s_e_a_r_c_h_ _C_o_n_s_o_r_t_i_u_m_ _f_o_r_ _I_n_f_o_r_m_a_t_i_c_s_ _a_n_d_ _M_a_t_h_e_m_a_t_i_c_s, _K_e_i_o_ _U_n_i_v_e_r_s_i_t_y). All Rights Reserved. _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_C_o_n_s_o_r_t_i_u_m_/ _L_e_g_a_l_/_2_0_0_2_/_c_o_p_y_r_i_g_h_t_-_d_o_c_u_m_e_n_t_s_-_2_0_0_2_1_2_3_1" 3. IIff iitt eexxiissttss, the STATUS of the W3C document. When space permits, inclusion of the full text of this NNOOTTIICCEE should be provided. We request that authorship attribution be provided in any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof. No right to create modifications or derivatives of W3C documents is granted pursuant to this license. However, if additional requirements (documented in the _C_o_p_y_r_i_g_h_t_ _F_A_Q) are satisfied, the right to create modifications or derivatives is sometimes granted by the W3C to individuals complying with those requirements. THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON- INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF. The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders. =============================================================================== ********** WW33CC®® SSooffttwwaarree CCooppyyrriigghhtt NNoottiiccee aanndd LLiicceennssee ********** NNoottee:: This section is a copy of the W3C® Software Copyright Notice and License and could be found at _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_C_o_n_s_o_r_t_i_u_m_/_L_e_g_a_l_/_2_0_0_2_/_c_o_p_y_r_i_g_h_t_- _s_o_f_t_w_a_r_e_-_2_0_0_2_1_2_3_1 CCooppyyrriigghhtt ©© 22000044 _WW_oo_rr_ll_dd_ _WW_ii_dd_ee_ _WW_ee_bb_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm,, ((_MM_aa_ss_ss_aa_cc_hh_uu_ss_ee_tt_tt_ss_ _II_nn_ss_tt_ii_tt_uu_tt_ee_ _oo_ff _TT_ee_cc_hh_nn_oo_ll_oo_gg_yy,, _EE_uu_rr_oo_pp_ee_aa_nn_ _RR_ee_ss_ee_aa_rr_cc_hh_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm_ _ff_oo_rr_ _II_nn_ff_oo_rr_mm_aa_tt_ii_cc_ss_ _aa_nn_dd_ _MM_aa_tt_hh_ee_mm_aa_tt_ii_cc_ss,, _KK_ee_ii_oo _UU_nn_ii_vv_ee_rr_ss_ii_tt_yy)).. AAllll RRiigghhttss RReesseerrvveedd.. hhttttpp::////wwwwww..ww33..oorrgg//CCoonnssoorrttiiuumm//LLeeggaall//22000022//ccooppyyrriigghhtt--ssooffttwwaarree--2200002211223311 This work (and included software, documentation such as READMEs, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions. Permission to copy, modify, and distribute this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications: 1. The full text of this NOTICE in a location viewable to users of the redistributed or derivative work. 2. Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the _W_3_C_®_ _S_h_o_r_t_ _S_o_f_t_w_a_r_e_ _N_o_t_i_c_e should be included (hypertext is preferred, text is permitted) within the body of any redistributed or derivative code. 3. Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.) THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENTATION. The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders. ********** WW33CC®® SShhoorrtt SSooffttwwaarree NNoottiiccee ********** NNoottee:: This section is a copy of the W3C® Short Software Notice and could be found at _h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_C_o_n_s_o_r_t_i_u_m_/_L_e_g_a_l_/_2_0_0_2_/_c_o_p_y_r_i_g_h_t_-_s_o_f_t_w_a_r_e_-_s_h_o_r_t_- _n_o_t_i_c_e_-_2_0_0_2_1_2_3_1 CCooppyyrriigghhtt ©© 22000044 _WW_oo_rr_ll_dd_ _WW_ii_dd_ee_ _WW_ee_bb_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm,, ((_MM_aa_ss_ss_aa_cc_hh_uu_ss_ee_tt_tt_ss_ _II_nn_ss_tt_ii_tt_uu_tt_ee_ _oo_ff _TT_ee_cc_hh_nn_oo_ll_oo_gg_yy,, _EE_uu_rr_oo_pp_ee_aa_nn_ _RR_ee_ss_ee_aa_rr_cc_hh_ _CC_oo_nn_ss_oo_rr_tt_ii_uu_mm_ _ff_oo_rr_ _II_nn_ff_oo_rr_mm_aa_tt_ii_cc_ss_ _aa_nn_dd_ _MM_aa_tt_hh_ee_mm_aa_tt_ii_cc_ss,, _KK_ee_ii_oo _UU_nn_ii_vv_ee_rr_ss_ii_tt_yy)).. AAllll RRiigghhttss RReesseerrvveedd.. Copyright © [$date-of-software] _W_o_r_l_d_ _W_i_d_e_ _W_e_b_ _C_o_n_s_o_r_t_i_u_m, (_M_a_s_s_a_c_h_u_s_e_t_t_s _I_n_s_t_i_t_u_t_e_ _o_f_ _T_e_c_h_n_o_l_o_g_y, _E_u_r_o_p_e_a_n_ _R_e_s_e_a_r_c_h_ _C_o_n_s_o_r_t_i_u_m_ _f_o_r_ _I_n_f_o_r_m_a_t_i_c_s_ _a_n_d _M_a_t_h_e_m_a_t_i_c_s, _K_e_i_o_ _U_n_i_v_e_r_s_i_t_y). All Rights Reserved. This work is distributed under the W3C® Software License [1] in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 07 April 2004 ************ WWhhaatt iiss tthhee DDooccuummeenntt OObbjjeecctt MMooddeell?? ************ Editors: Philippe Le Hégaret, W3C Lauren Wood, SoftQuad Software Inc. (for DOM Level 2) Jonathan Robie, Texcel (for DOM Level 1) ********** IInnttrroodduuccttiioonn ********** The Document Object Model (DOM) is an application programming interface (_A_P_I) for valid _H_T_M_L and well-formed _X_M_L documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data. With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM _i_n_t_e_r_f_a_c_e_s for the XML internal and external subsets have not yet been specified. As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and _a_p_p_l_i_c_a_t_i_o_n_s. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [_O_M_G_ _I_D_L], as defined in the CORBA 2.3.1 specification [_C_O_R_B_A]. In addition to the OMG IDL specification, we provide _l_a_n_g_u_a_g_e_ _b_i_n_d_i_n_g_s for Java [_J_a_v_a] and ECMAScript [_E_C_M_A_S_c_r_i_p_t] (an industry-standard scripting language based on JavaScript [_J_a_v_a_S_c_r_i_p_t] and JScript [_J_S_c_r_i_p_t]). Because of language binding restrictions, a mapping has to be applied between the OMG IDL and the programming language in used. For example, while the DOM uses IDL attributes in the definition of interfaces, Java does not allow interfaces to contain attributes: // example 1: removing the first child of an element using ECMAScript mySecondTrElement.removeChild(mySecondTrElement.firstChild); // example 2: removing the first child of an element using Java mySecondTrElement.removeChild(mySecondTrElement.getFirstChild()); NNoottee:: OMG IDL is used only as a language-independent and implementation-neutral way to specify _i_n_t_e_r_f_a_c_e_s. Various other IDLs could have been used ([_C_O_M], [_J_a_v_a_ _I_D_L], [_M_I_D_L], ...). In general, IDLs are designed for specific computing environments. The Document Object Model can be implemented in any computing environment, and does not require the object binding runtimes generally associated with such IDLs. ********** WWhhaatt tthhee DDooccuummeenntt OObbjjeecctt MMooddeell iiss ********** The DOM is a programming _A_P_I for documents. It is based on an object structure that closely resembles the structure of the documents it _m_o_d_e_l_s. For instance, consider this table, taken from an XHTML document:
Shady Grove Aeolian
Over the River, Charlie Dorian
A graphical representation of the DOM of the example table, with whitespaces in element content (often abusively called "ignorable whitespace") removed, is: [graphical representation of the DOM of the example table] Figure: graphical representation of the DOM of the example table [_S_V_G_ _1_._0 _v_e_r_s_i_o_n] An example of DOM manipulation using ECMAScript would be: // access the tbody element from the table element var myTbodyElement = myTableElement.firstChild; // access its second tr element // The list of children starts at 0 (and not 1). var mySecondTrElement = myTbodyElement.childNodes[1]; // remove its first td element mySecondTrElement.removeChild(mySecondTrElement.firstChild); // change the text content of the remaining td element mySecondTrElement.firstChild.firstChild.data = "Peter"; In the DOM, documents have a logical structure which is very much like a tree; to be more precise, which is like a "forest" or "grove", which can contain more than one tree. Each document contains zero or one doctype nodes, one document element node, and zero or more comments or processing instructions; the document element serves as the root of the element tree for the document. However, the DOM does not specify that documents must be iimmpplleemmeenntteedd as a tree or a grove, nor does it specify how the relationships among objects be implemented. The DOM is a logical model that may be implemented in any convenient manner. In this specification, we use the term ssttrruuccttuurree mmooddeell to describe the tree-like representation of a document. We also use the term "tree" when referring to the arrangement of those information items which can be reached by using "tree-walking" methods; (this does not include attributes). One important property of DOM structure models is ssttrruuccttuurraall iissoommoorrpphhiissmm: if any two Document Object Model implementations are used to create a representation of the same document, they will create the same structure model, in accordance with the XML Information Set [_X_M_L_ _I_n_f_o_r_m_a_t_i_o_n_ _S_e_t]. NNoottee:: There may be some variations depending on the parser being used to build the DOM. For instance, the DOM may not contain white spaces in element content if the parser discards them. The name "Document Object Model" was chosen because it is an "_o_b_j_e_c_t_ _m_o_d_e_l" in the traditional object oriented design sense: documents are modeled using objects, and the model encompasses not only the structure of a document, but also the behavior of a document and the objects of which it is composed. In other words, the nodes in the above diagram do not represent a data structure, they represent objects, which have functions and identity. As an object model, the DOM identifies: * the interfaces and objects used to represent and manipulate a document * the semantics of these interfaces and objects - including both behavior and attributes * the relationships and collaborations among these interfaces and objects The structure of SGML documents has traditionally been represented by an abstract _d_a_t_a_ _m_o_d_e_l, not by an object model. In an abstract _d_a_t_a_ _m_o_d_e_l, the model is centered around the data. In object oriented programming languages, the data itself is encapsulated in objects that hide the data, protecting it from direct external manipulation. The functions associated with these objects determine how the objects may be manipulated, and they are part of the object model. ********** WWhhaatt tthhee DDooccuummeenntt OObbjjeecctt MMooddeell iiss nnoott ********** This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it. * The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability. * The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs. * The Document Object Model is not a set of data structures; it is an _o_b_j_e_c_t_ _m_o_d_e_l that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures. * The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [_X_M_L_ _I_n_f_o_r_m_a_t_i_o_n_ _S_e_t]. The DOM is simply an _A_P_I to this information set. * The Document Object Model, despite its name, is not a competitor to the Component Object Model [_C_O_M]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document. ********** WWhheerree tthhee DDooccuummeenntt OObbjjeecctt MMooddeell ccaammee ffrroomm ********** The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM. ********** EEnnttiittiieess aanndd tthhee DDOOMM CCoorree ********** In the fundamental DOM interfaces, there are no objects representing entities. Numeric character references, and references to the pre-defined entities in HTML and XML, are replaced by the single character that makes up the entity's replacement. For example, in:

This is a dog & a cat

the "&" will be replaced by the character "&", and the text in the P element will form a single continuous sequence of characters. Since numeric character references and pre-defined entities are not recognized as such in CDATA sections, or in the SCRIPT and STYLE elements in HTML, they are not replaced by the single character they appear to refer to. If the example above were enclosed in a CDATA section, the "&" would not be replaced by "&"; neither would the

be recognized as a start tag. The representation of general entities, both internal and external, are defined within the extended (XML) interfaces of _D_o_c_u_m_e_n_t_ _O_b_j_e_c_t_ _M_o_d_e_l_ _C_o_r_e. Note: When a DOM representation of a document is serialized as XML or HTML text, applications will need to check each character in text data to see if it needs to be escaped using a numeric or pre-defined entity. Failing to do so could result in invalid HTML or XML. Also, _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s should be aware of the fact that serialization into a character encoding ("charset") that does not fully cover ISO 10646 may fail if there are characters in markup or CDATA sections that are not present in the encoding. ********** DDOOMM AArrcchhiitteeccttuurree ********** The DOM specifications provide a set of APIs that forms the DOM API. Each DOM specification defines one or more modules and each module is associated with one feature name. For example, the DOM Core specification (this specification) defines two modules: * The Core module, which contains the fundamental interfaces that must be implemented by all DOM conformant implementations, is associated with the feature name "Core"; * The XML module, which contains the interfaces that must be implemented by all conformant XML 1.0 [_X_M_L_ _1_._0] (and higher) DOM implementations, is associated with the feature name "XML". The following representation contains all DOM modules, represented using their feature names, defined along the DOM specifications: [A view of the DOM Architecture] Figure: A view of the DOM Architecture [_S_V_G_ _1_._0_ _v_e_r_s_i_o_n] A DOM implementation can then implement one (i.e. only the Core module) or more modules depending on the host application. A Web user agent is very likely to implement the "MouseEvents" module, while a server-side application will have no use of this module and will probably not implement it. ********** CCoonnffoorrmmaannccee ********** This section explains the different levels of conformance to DOM Level 3. DOM Level 3 consists of 16 modules. It is possible to conform to DOM Level 3, or to a DOM Level 3 module. An implementation is DOM Level 3 conformant if it supports the Core module defined in this document (see _F_u_n_d_a_m_e_n_t_a_l_ _I_n_t_e_r_f_a_c_e_s_:_ _C_o_r_e_ _M_o_d_u_l_e). An implementation conforms to a DOM Level 3 module if it supports all the interfaces for that module and the associated semantics. Here is the complete list of DOM Level 3.0 modules and the features used by them. Feature names are case-insensitive. Core module defines the feature _""_CC_oo_rr_ee_"". XML module Defines the feature _""_XX_MM_LL_"". Events module defines the feature _""_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. User interface Events module defines the feature _""_UU_II_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. Mouse Events module defines the feature _""_MM_oo_uu_ss_ee_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. Text Events module defines the feature _""_TT_ee_xx_tt_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. Keyboard Events module defines the feature _""_KK_ee_yy_bb_oo_aa_rr_dd_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. Mutation Events module defines the feature _""_MM_uu_tt_aa_tt_ii_oo_nn_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. Mutation name Events module defines the feature _""_MM_uu_tt_aa_tt_ii_oo_nn_NN_aa_mm_ee_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. HTML Events module defines the feature _""_HH_TT_MM_LL_EE_vv_ee_nn_tt_ss_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _E_v_e_n_t_s]. Load and Save module defines the feature _""_LL_SS_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _L_o_a_d_ _a_n_d_ _S_a_v_e]. Asynchronous load module defines the feature _""_LL_SS_--_AA_ss_yy_nn_cc_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _L_o_a_d_ _a_n_d_ _S_a_v_e]. Validation module defines the feature _""_VV_aa_ll_ii_dd_aa_tt_ii_oo_nn_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _V_a_l_i_d_a_t_i_o_n]. XPath module defines the feature _""_XX_PP_aa_tt_hh_"" in [_D_O_M_ _L_e_v_e_l_ _3_ _X_P_a_t_h]. A DOM implementation must not return true to the _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._h_a_s_F_e_a_t_u_r_e _(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_) _m_e_t_h_o_d of the _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n interface for that feature unless the implementation conforms to that module. The version number for all features used in DOM Level 3.0 is "3.0". ********** DDOOMM IInntteerrffaacceess aanndd DDOOMM IImmpplleemmeennttaattiioonnss ********** The DOM specifies interfaces which may be used to manage XML or HTML documents. It is important to realize that these interfaces are an abstraction - much like "abstract base classes" in C++, they are a means of specifying a way to access and manipulate an application's internal representation of a document. Interfaces do not imply a particular concrete implementation. Each DOM application is free to maintain documents in any convenient representation, as long as the interfaces shown in this specification are supported. Some DOM implementations will be existing programs that use the DOM interfaces to access software written long before the DOM specification existed. Therefore, the DOM is designed to avoid implementation dependencies; in particular, 1. Attributes defined in the IDL do not imply concrete objects which must have specific data members - in the language bindings, they are translated to a pair of get()/set() functions, not to a data member. Read-only attributes have only a get() function in the language bindings. 2. DOM applications may provide additional interfaces and objects not found in this specification and still be considered DOM conformant. 3. Because we specify interfaces and not the actual objects that are to be created, the DOM cannot know what constructors to call for an implementation. In general, DOM users call the createX() methods on the Document class to create document structures, and DOM implementations create their own internal representations of these structures in their implementations of the createX() functions. The Level 2 interfaces were extended to provide both Level 2 and Level 3 functionality. DOM implementations in languages other than Java or ECMAScript may choose bindings that are appropriate and natural for their language and run time environment. For example, some systems may need to create a Document3 class which inherits from a Document class and contains the new methods and attributes. DOM Level 3 does not specify multithreading mechanisms. 07 April 2004 ************ 11.. DDooccuummeenntt OObbjjeecctt MMooddeell CCoorree ************ Editors: Arnaud Le Hors, IBM Philippe Le Hégaret, W3C Gavin Nicol, Inso EPS (for DOM Level 1) Lauren Wood, SoftQuad, Inc. (for DOM Level 1) Mike Champion, Arbortext and Software AG (for DOM Level 1 from November 20, 1997) Steve Byrne, JavaSoft (for DOM Level 1 until November 19, 1997) ********** TTaabbllee ooff ccoonntteennttss ********** * _1_._1_ _O_v_e_r_v_i_e_w_ _o_f_ _t_h_e_ _D_O_M_ _C_o_r_e_ _I_n_t_e_r_f_a_c_e_s o _1_._1_._1_ _T_h_e_ _D_O_M_ _S_t_r_u_c_t_u_r_e_ _M_o_d_e_l o _1_._1_._2_ _M_e_m_o_r_y_ _M_a_n_a_g_e_m_e_n_t o _1_._1_._3_ _N_a_m_i_n_g_ _C_o_n_v_e_n_t_i_o_n_s o _1_._1_._4_ _I_n_h_e_r_i_t_a_n_c_e_ _v_s_._ _F_l_a_t_t_e_n_e_d_ _V_i_e_w_s_ _o_f_ _t_h_e_ _A_P_I * _1_._2_ _B_a_s_i_c_ _T_y_p_e_s o _1_._2_._1_ _T_h_e_ _D_O_M_S_t_r_i_n_g_ _T_y_p_e # _D_O_M_S_t_r_i_n_g o _1_._2_._2_ _T_h_e_ _D_O_M_T_i_m_e_S_t_a_m_p_ _T_y_p_e # _D_O_M_T_i_m_e_S_t_a_m_p o _1_._2_._3_ _T_h_e_ _D_O_M_U_s_e_r_D_a_t_a_ _T_y_p_e # _D_O_M_U_s_e_r_D_a_t_a o _1_._2_._4_ _T_h_e_ _D_O_M_O_b_j_e_c_t_ _T_y_p_e # _D_O_M_O_b_j_e_c_t * _1_._3_ _G_e_n_e_r_a_l_ _C_o_n_s_i_d_e_r_a_t_i_o_n_s o _1_._3_._1_ _S_t_r_i_n_g_ _C_o_m_p_a_r_i_s_o_n_s_ _i_n_ _t_h_e_ _D_O_M o _1_._3_._2_ _D_O_M_ _U_R_I_s o _1_._3_._3_ _X_M_L_ _N_a_m_e_s_p_a_c_e_s o _1_._3_._4_ _B_a_s_e_ _U_R_I_s o _1_._3_._5_ _M_i_x_e_d_ _D_O_M_ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_s o _1_._3_._6_ _D_O_M_ _F_e_a_t_u_r_e_s o _1_._3_._7_ _B_o_o_t_s_t_r_a_p_p_i_n_g * _1_._4_ _F_u_n_d_a_m_e_n_t_a_l_ _I_n_t_e_r_f_a_c_e_s_:_ _C_o_r_e_ _M_o_d_u_l_e o _D_O_M_E_x_c_e_p_t_i_o_n, _E_x_c_e_p_t_i_o_n_C_o_d_e, _D_O_M_S_t_r_i_n_g_L_i_s_t, _N_a_m_e_L_i_s_t, _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_L_i_s_t, _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e, _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n, _D_o_c_u_m_e_n_t_F_r_a_g_m_e_n_t, _D_o_c_u_m_e_n_t, _N_o_d_e, _N_o_d_e_L_i_s_t, _N_a_m_e_d_N_o_d_e_M_a_p, _C_h_a_r_a_c_t_e_r_D_a_t_a, _A_t_t_r, _E_l_e_m_e_n_t, _T_e_x_t, _C_o_m_m_e_n_t, _T_y_p_e_I_n_f_o, _U_s_e_r_D_a_t_a_H_a_n_d_l_e_r, _D_O_M_E_r_r_o_r, _D_O_M_E_r_r_o_r_H_a_n_d_l_e_r, _D_O_M_L_o_c_a_t_o_r, _D_O_M_C_o_n_f_i_g_u_r_a_t_i_o_n * _1_._5_ _E_x_t_e_n_d_e_d_ _I_n_t_e_r_f_a_c_e_s_:_ _X_M_L_ _M_o_d_u_l_e o _C_D_A_T_A_S_e_c_t_i_o_n, _D_o_c_u_m_e_n_t_T_y_p_e, _N_o_t_a_t_i_o_n, _E_n_t_i_t_y, _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e, _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n This specification defines a set of objects and interfaces for accessing and manipulating document objects. The functionality specified (the CCoorree functionality) is sufficient to allow software developers and Web script authors to access and manipulate parsed HTML [_H_T_M_L_ _4_._0_1] and XML [_X_M_L_ _1_._0] content inside conforming products. The DOM Core _A_P_I also allows creation and population of a _D_o_c_u_m_e_n_t object using only DOM API calls. A solution for loading a _D_o_c_u_m_e_n_t and saving it persistently is proposed in [_D_O_M_ _L_e_v_e_l_ _3_ _L_o_a_d _a_n_d_ _S_a_v_e]. ********** 11..11 OOvveerrvviieeww ooff tthhee DDOOMM CCoorree IInntteerrffaacceess ********** ******** 11..11..11 TThhee DDOOMM SSttrruuccttuurree MMooddeell ******** The DOM presents documents as a hierarchy of _N_o_d_e objects that also implement other, more specialized interfaces. Some types of nodes may have _c_h_i_l_d nodes of various types, and others are leaf nodes that cannot have anything below them in the document structure. For XML and HTML, the node types, and which node types they may have as children, are as follows: * _D_o_c_u_m_e_n_t -- _E_l_e_m_e_n_t (maximum of one), _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n, _C_o_m_m_e_n_t, _D_o_c_u_m_e_n_t_T_y_p_e (maximum of one) * _D_o_c_u_m_e_n_t_F_r_a_g_m_e_n_t -- _E_l_e_m_e_n_t, _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n, _C_o_m_m_e_n_t, _T_e_x_t, _C_D_A_T_A_S_e_c_t_i_o_n, _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e * _D_o_c_u_m_e_n_t_T_y_p_e -- no children * _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e -- _E_l_e_m_e_n_t, _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n, _C_o_m_m_e_n_t, _T_e_x_t, _C_D_A_T_A_S_e_c_t_i_o_n, _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e * _E_l_e_m_e_n_t -- _E_l_e_m_e_n_t, _T_e_x_t, _C_o_m_m_e_n_t, _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n, _C_D_A_T_A_S_e_c_t_i_o_n, _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e * _A_t_t_r -- _T_e_x_t, _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e * _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n -- no children * _C_o_m_m_e_n_t -- no children * _T_e_x_t -- no children * _C_D_A_T_A_S_e_c_t_i_o_n -- no children * _E_n_t_i_t_y -- _E_l_e_m_e_n_t, _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n, _C_o_m_m_e_n_t, _T_e_x_t, _C_D_A_T_A_S_e_c_t_i_o_n, _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e * _N_o_t_a_t_i_o_n -- no children The DOM also specifies a _N_o_d_e_L_i_s_t interface to handle ordered lists of _N_o_d_e_s, such as the children of a _N_o_d_e, or the _e_l_e_m_e_n_t_s returned by the _E_l_e_m_e_n_t_._g_e_t_E_l_e_m_e_n_t_s_B_y_T_a_g_N_a_m_e_N_S_(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _l_o_c_a_l_N_a_m_e_) method, and also a _N_a_m_e_d_N_o_d_e_M_a_p interface to handle unordered sets of nodes referenced by their name attribute, such as the attributes of an _E_l_e_m_e_n_t. _N_o_d_e_L_i_s_t and _N_a_m_e_d_N_o_d_e_M_a_p objects in the DOM are live; that is, changes to the underlying document structure are reflected in all relevant _N_o_d_e_L_i_s_t and _N_a_m_e_d_N_o_d_e_M_a_p objects. For example, if a DOM user gets a _N_o_d_e_L_i_s_t object containing the children of an _E_l_e_m_e_n_t, then subsequently adds more children to that _e_l_e_m_e_n_t (or removes children, or modifies them), those changes are automatically reflected in the _N_o_d_e_L_i_s_t, without further action on the user's part. Likewise, changes to a _N_o_d_e in the tree are reflected in all references to that _N_o_d_e in _N_o_d_e_L_i_s_t and _N_a_m_e_d_N_o_d_e_M_a_p objects. Finally, the interfaces _T_e_x_t, _C_o_m_m_e_n_t, and _C_D_A_T_A_S_e_c_t_i_o_n all inherit from the _C_h_a_r_a_c_t_e_r_D_a_t_a interface. ******** 11..11..22 MMeemmoorryy MMaannaaggeemmeenntt ******** Most of the APIs defined by this specification are iinntteerrffaacceess rather than classes. That means that an implementation need only expose methods with the defined names and specified operation, not implement classes that correspond directly to the interfaces. This allows the DOM APIs to be implemented as a thin veneer on top of legacy applications with their own data structures, or on top of newer applications with different class hierarchies. This also means that ordinary constructors (in the Java or C++ sense) cannot be used to create DOM objects, since the underlying objects to be constructed may have little relationship to the DOM interfaces. The conventional solution to this in object-oriented design is to define ffaaccttoorryy methods that create instances of objects that implement the various interfaces. Objects implementing some interface "X" are created by a "createX()" method on the _D_o_c_u_m_e_n_t interface; this is because all DOM objects live in the context of a specific Document. The Core DOM APIs are designed to be compatible with a wide range of languages, including both general-user scripting languages and the more challenging languages used mostly by professional programmers. Thus, the DOM APIs need to operate across a variety of memory management philosophies, from language bindings that do not expose memory management to the user at all, through those (notably Java) that provide explicit constructors but provide an automatic garbage collection mechanism to automatically reclaim unused memory, to those (especially C/C++) that generally require the programmer to explicitly allocate object memory, track where it is used, and explicitly free it for re-use. To ensure a consistent API across these platforms, the DOM does not address memory management issues at all, but instead leaves these for the implementation. Neither of the explicit language bindings defined by the DOM API (for _E_C_M_A_S_c_r_i_p_t and Java) require any memory management methods, but DOM bindings for other languages (especially C or C++) may require such support. These extensions will be the responsibility of those adapting the DOM API to a specific language, not the DOM Working Group. ******** 11..11..33 NNaammiinngg CCoonnvveennttiioonnss ******** While it would be nice to have attribute and method names that are short, informative, internally consistent, and familiar to users of similar APIs, the names also should not clash with the names in legacy APIs supported by DOM implementations. Furthermore, both OMG IDL [_O_M_G_ _I_D_L] and ECMAScript [_E_C_M_A_S_c_r_i_p_t] have significant limitations in their ability to disambiguate names from different namespaces that make it difficult to avoid naming conflicts with short, familiar names. So, DOM names tend to be long and descriptive in order to be unique across all environments. The Working Group has also attempted to be internally consistent in its use of various terms, even though these may not be common distinctions in other APIs. For example, the DOM API uses the method name "remove" when the method changes the structural model, and the method name "delete" when the method gets rid of something inside the structure model. The thing that is deleted is not returned. The thing that is removed may be returned, when it makes sense to return it. ******** 11..11..44 IInnhheerriittaannccee vvss.. FFllaatttteenneedd VViieewwss ooff tthhee AAPPII ******** The DOM Core _A_P_I_s present two somewhat different sets of interfaces to an XML/ HTML document: one presenting an "object oriented" approach with a hierarchy of _i_n_h_e_r_i_t_a_n_c_e, and a "simplified" view that allows all manipulation to be done via the _N_o_d_e interface without requiring casts (in Java and other C-like languages) or query interface calls in _C_O_M environments. These operations are fairly expensive in Java and COM, and the DOM may be used in performance- critical environments, so we allow significant functionality using just the _N_o_d_e interface. Because many other users will find the _i_n_h_e_r_i_t_a_n_c_e hierarchy easier to understand than the "everything is a _N_o_d_e" approach to the DOM, we also support the full higher-level interfaces for those who prefer a more object-oriented _A_P_I. In practice, this means that there is a certain amount of redundancy in the _A_P_I. The Working Group considers the "_i_n_h_e_r_i_t_a_n_c_e" approach the primary view of the API, and the full set of functionality on _N_o_d_e to be "extra" functionality that users may employ, but that does not eliminate the need for methods on other interfaces that an object-oriented analysis would dictate. (Of course, when the O-O analysis yields an attribute or method that is identical to one on the _N_o_d_e interface, we don't specify a completely redundant one.) Thus, even though there is a generic _N_o_d_e_._n_o_d_e_N_a_m_e attribute on the _N_o_d_e interface, there is still a _E_l_e_m_e_n_t_._t_a_g_N_a_m_e attribute on the _E_l_e_m_e_n_t interface; these two attributes must contain the same value, but the it is worthwhile to support both, given the different constituencies the DOM _A_P_I must satisfy. ********** 11..22 BBaassiicc TTyyppeess ********** To ensure interoperability, this specification specifies the following basic types used in various DOM modules. Even though the DOM uses the basic types in the interfaces, bindings may use different types and normative bindings are only given for Java and ECMAScript in this specification. ******** 11..22..11 TThhee _DD_OO_MM_SS_tt_rr_ii_nn_gg TTyyppee ******** The _D_O_M_S_t_r_i_n_g type is used to store [_U_n_i_c_o_d_e] characters as a sequence of _1_6_- _b_i_t_ _u_n_i_t_s using UTF-16 as defined in [_U_n_i_c_o_d_e] and Amendment 1 of [_I_S_O_/_I_E_C _1_0_6_4_6]. Characters are _f_u_l_l_y_ _n_o_r_m_a_l_i_z_e_d as defined in appendix B of [_X_M_L_ _1_._1] if: * the parameter "_n_o_r_m_a_l_i_z_e_-_c_h_a_r_a_c_t_e_r_s" was set to true while loading the document or the document was certified as defined in [_X_M_L_ _1_._1]; * the parameter "_n_o_r_m_a_l_i_z_e_-_c_h_a_r_a_c_t_e_r_s" was set to true while using the method _D_o_c_u_m_e_n_t_._n_o_r_m_a_l_i_z_e_D_o_c_u_m_e_n_t_(_), or while using the method _N_o_d_e_._n_o_r_m_a_l_i_z_e_(_); Note that, with the exceptions of _D_o_c_u_m_e_n_t_._n_o_r_m_a_l_i_z_e_D_o_c_u_m_e_n_t_(_) and _N_o_d_e_._n_o_r_m_a_l_i_z_e_(_), manipulating characters using DOM methods does not guarantee to preserve a fully-normalized text. TTyyppee DDeeffiinniittiioonn DDOOMMSSttrriinngg A _D_O_M_S_t_r_i_n_g is a sequence of _1_6_-_b_i_t_ _u_n_i_t_s. IIDDLL DDeeffiinniittiioonn valuetype _D_O_M_S_t_r_i_n_g sequence; The UTF-16 encoding was chosen because of its widespread industry practice. Note that for both HTML and XML, the document character set (and therefore the notation of numeric character references) is based on UCS [_I_S_O_/_I_E_C_ _1_0_6_4_6]. A single numeric character reference in a source document may therefore in some cases correspond to two 16-bit units in a _D_O_M_S_t_r_i_n_g (a high surrogate and a low surrogate). For issues related to string comparisons, refer to _S_t_r_i_n_g _C_o_m_p_a_r_i_s_o_n_s_ _i_n_ _t_h_e_ _D_O_M. For Java and ECMAScript, _D_O_M_S_t_r_i_n_g is bound to the String type because both languages also use UTF-16 as their encoding. NNoottee:: As of August 2000, the OMG IDL specification ([_O_M_G_ _I_D_L]) included a wstring type. However, that definition did not meet the interoperability criteria of the DOM _A_P_I since it relied on negotiation to decide the width and encoding of a character. ******** 11..22..22 TThhee _DD_OO_MM_TT_ii_mm_ee_SS_tt_aa_mm_pp TTyyppee ******** The _D_O_M_T_i_m_e_S_t_a_m_p type is used to store an absolute or relative time. TTyyppee DDeeffiinniittiioonn DDOOMMTTiimmeeSSttaammpp A _D_O_M_T_i_m_e_S_t_a_m_p represents a number of milliseconds. IIDDLL DDeeffiinniittiioonn typedef unsigned long long _D_O_M_T_i_m_e_S_t_a_m_p; For Java, _D_O_M_T_i_m_e_S_t_a_m_p is bound to the long type. For ECMAScript, _D_O_M_T_i_m_e_S_t_a_m_p is bound to the Date type because the range of the integer type is too small. ******** 11..22..33 TThhee _DD_OO_MM_UU_ss_ee_rr_DD_aa_tt_aa TTyyppee ******** The _D_O_M_U_s_e_r_D_a_t_a type is used to store application data. TTyyppee DDeeffiinniittiioonn DDOOMMUUsseerrDDaattaa A _D_O_M_U_s_e_r_D_a_t_a represents a reference to application data. IIDDLL DDeeffiinniittiioonn typedef any _D_O_M_U_s_e_r_D_a_t_a; For Java, _D_O_M_U_s_e_r_D_a_t_a is bound to the Object type. For ECMAScript, _D_O_M_U_s_e_r_D_a_t_a is bound to any type. ******** 11..22..44 TThhee _DD_OO_MM_OO_bb_jj_ee_cc_tt TTyyppee ******** The _D_O_M_O_b_j_e_c_t type is used to represent an object. TTyyppee DDeeffiinniittiioonn DDOOMMOObbjjeecctt A _D_O_M_O_b_j_e_c_t represents an object reference. IIDDLL DDeeffiinniittiioonn typedef Object _D_O_M_O_b_j_e_c_t; For Java and ECMAScript, _D_O_M_O_b_j_e_c_t is bound to the Object type. ********** 11..33 GGeenneerraall CCoonnssiiddeerraattiioonnss ********** ******** 11..33..11 SSttrriinngg CCoommppaarriissoonnss iinn tthhee DDOOMM ******** The DOM has many interfaces that imply string matching. For XML, string comparisons are case-sensitive and performed with a binary _c_o_m_p_a_r_i_s_o_n of the _1_6_-_b_i_t_ _u_n_i_t_s of the _D_O_M_S_t_r_i_n_g_s. However, for case-insensitive markup languages, such as HTML 4.01 or earlier, these comparisons are case-insensitive where appropriate. Note that HTML processors often perform specific case normalizations (canonicalization) of the markup before the DOM structures are built. This is typically using uppercase for _e_l_e_m_e_n_t names and lowercase for attribute names. For this reason, applications should also compare element and attribute names returned by the DOM implementation in a case-insensitive manner. The character normalization, i.e. transforming into their _f_u_l_l_y_ _n_o_r_m_a_l_i_z_e_d form as as defined in [_X_M_L_ _1_._1], is assumed to happen at serialization time. The DOM Level 3 Load and Save module [_D_O_M_ _L_e_v_e_l_ _3_ _L_o_a_d_ _a_n_d_ _S_a_v_e] provides a serialization mechanism (see the DOMSerializer interface, section 2.3.1) and uses the _D_O_M_C_o_n_f_i_g_u_r_a_t_i_o_n parameters "_n_o_r_m_a_l_i_z_e_-_c_h_a_r_a_c_t_e_r_s" and "_c_h_e_c_k_- _c_h_a_r_a_c_t_e_r_-_n_o_r_m_a_l_i_z_a_t_i_o_n" to assure that text is _f_u_l_l_y_ _n_o_r_m_a_l_i_z_e_d [_X_M_L_ _1_._1]. Other serialization mechanisms built on top of the DOM Level 3 Core also have to assure that text is fully normalized. ******** 11..33..22 DDOOMM UURRIIss ******** The DOM specification relies on _D_O_M_S_t_r_i_n_g values as resource identifiers, such that the following conditions are met: 1. An absolute identifier absolutely identifies a resource on the Web; 2. Simple string equality establishes equality of absolute resource identifiers, and no other equivalence of resource identifiers is considered significant to the DOM specification; 3. A relative identifier is easily detected and made absolute relative to an absolute identifier; 4. Retrieval of content of a resource may be accomplished where required. The term "absolute URI" refers to a complete resource identifier and the term "relative URI" refers to an incomplete resource identifier. Within the DOM specifications, these identifiers are called URIs, "Uniform Resource Identifiers", but this is meant abstractly. The DOM implementation does not necessarily process its URIs according to the URI specification [_I_E_T_F _R_F_C_ _2_3_9_6]. Generally the particular form of these identifiers must be ignored. When is not possible to completely ignore the type of a DOM URI, either because a relative identifier must be made absolute or because content must be retrieved, the DOM implementation must at least support identifier types appropriate to the content being processed. [_H_T_M_L_ _4_._0_1], [_X_M_L_ _1_._0], and associated namespace specification [_X_M_L_ _N_a_m_e_s_p_a_c_e_s] rely on [_I_E_T_F_ _R_F_C_ _2_3_9_6] to determine permissible characters and resolving relative URIs. Other specifications such as namespaces in XML 1.1 [_X_M_L_ _N_a_m_e_s_p_a_c_e_s_ _1_._1] may rely on alternative resource identifier types that may, for example, include non-ASCII characters, necessitating support for alternative resource identifier types where required by applicable specifications. ******** 11..33..33 XXMMLL NNaammeessppaacceess ******** DOM Level 2 and 3 support XML namespaces [_X_M_L_ _N_a_m_e_s_p_a_c_e_s] by augmenting several interfaces of the DOM Level 1 Core to allow creating and manipulating _e_l_e_m_e_n_t_s and attributes associated to a namespace. When [_X_M_L_ _1_._1] is in use (see _D_o_c_u_m_e_n_t_._x_m_l_V_e_r_s_i_o_n), DOM Level 3 also supports [_X_M_L_ _N_a_m_e_s_p_a_c_e_s_ _1_._1]. As far as the DOM is concerned, special attributes used for declaring XML namespaces are still exposed and can be manipulated just like any other attribute. However, nodes are permanently bound to _n_a_m_e_s_p_a_c_e_ _U_R_I_s as they get created. Consequently, moving a node within a document, using the DOM, in no case results in a change of its _n_a_m_e_s_p_a_c_e_ _p_r_e_f_i_x or namespace URI. Similarly, creating a node with a namespace prefix and namespace URI, or changing the namespace prefix of a node, does not result in any addition, removal, or modification of any special attributes for declaring the appropriate XML namespaces. Namespace validation is not enforced; the DOM application is responsible. In particular, since the mapping between prefixes and namespace URIs is not enforced, in general, the resulting document cannot be serialized naively. For example, applications may have to declare every namespace in use when serializing a document. In general, the DOM implementation (and higher) doesn't perform any URI normalization or canonicalization. The URIs given to the DOM are assumed to be valid (e.g., characters such as white spaces are properly escaped), and no lexical checking is performed. Absolute URI references are treated as strings and _c_o_m_p_a_r_e_d_ _l_i_t_e_r_a_l_l_y. How relative namespace URI references are treated is undefined. To ensure interoperability only absolute namespace URI references (i.e., URI references beginning with a scheme name and a colon) should be used. Applications should use the value null as the namespaceURI parameter for methods if they wish to have no namespace. In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null. This is true even though the DOM does no lexical checking of URIs. NNoottee:: _E_l_e_m_e_n_t_._s_e_t_A_t_t_r_i_b_u_t_e_N_S_(_n_u_l_l_,_ _._._._) puts the attribute in the per-element- type partitions as defined in _XX_MM_LL_ _NN_aa_mm_ee_ss_pp_aa_cc_ee_ _PP_aa_rr_tt_ii_tt_ii_oo_nn_ss in [_X_M_L_ _N_a_m_e_s_p_a_c_e_s]. NNoottee:: In the DOM, all namespace declaration attributes are bbyy ddeeffiinniittiioonn bound to the namespace URI: "_h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_2_0_0_0_/_x_m_l_n_s_/". These are the attributes whose _n_a_m_e_s_p_a_c_e_ _p_r_e_f_i_x or _q_u_a_l_i_f_i_e_d_ _n_a_m_e is "xmlns" as introduced in [_X_M_L _N_a_m_e_s_p_a_c_e_s_ _1_._1]. In a document with no namespaces, the _c_h_i_l_d list of an _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e node is always the same as that of the corresponding _E_n_t_i_t_y. This is not true in a document where an entity contains unbound _n_a_m_e_s_p_a_c_e_ _p_r_e_f_i_x_e_s. In such a case, the _d_e_s_c_e_n_d_a_n_t_s of the corresponding _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e nodes may be bound to different _n_a_m_e_s_p_a_c_e_ _U_R_I_s, depending on where the entity references are. Also, because, in the DOM, nodes always remain bound to the same namespace URI, moving such _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e nodes can lead to documents that cannot be serialized. This is also true when the DOM Level 1 method _D_o_c_u_m_e_n_t_._c_r_e_a_t_e_E_n_t_i_t_y_R_e_f_e_r_e_n_c_e_(_n_a_m_e_) is used to create entity references that correspond to such entities, since the _d_e_s_c_e_n_d_a_n_t_s of the returned _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e are unbound. While DOM Level 3 does have support for the resolution of namespace prefixes, use of such entities and entity references should be avoided or used with extreme care. The "NS" methods, such as _D_o_c_u_m_e_n_t_._c_r_e_a_t_e_E_l_e_m_e_n_t_N_S_(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _q_u_a_l_i_f_i_e_d_N_a_m_e_) and _D_o_c_u_m_e_n_t_._c_r_e_a_t_e_A_t_t_r_i_b_u_t_e_N_S_(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _q_u_a_l_i_f_i_e_d_N_a_m_e_), are meant to be used by namespace aware applications. Simple applications that do not use namespaces can use the DOM Level 1 methods, such as _D_o_c_u_m_e_n_t_._c_r_e_a_t_e_E_l_e_m_e_n_t _(_t_a_g_N_a_m_e_) and _D_o_c_u_m_e_n_t_._c_r_e_a_t_e_A_t_t_r_i_b_u_t_e_(_n_a_m_e_). Elements and attributes created in this way do not have any namespace prefix, namespace URI, or local name. NNoottee:: DOM Level 1 methods are namespace ignorant. Therefore, while it is safe to use these methods when not dealing with namespaces, using them and the new ones at the same time should be avoided. DOM Level 1 methods solely identify attribute nodes by their _N_o_d_e_._n_o_d_e_N_a_m_e. On the contrary, the DOM Level 2 methods related to namespaces, identify attribute nodes by their _N_o_d_e_._n_a_m_e_s_p_a_c_e_U_R_I and _N_o_d_e_._l_o_c_a_l_N_a_m_e. Because of this fundamental difference, mixing both sets of methods can lead to unpredictable results. In particular, using _E_l_e_m_e_n_t_._s_e_t_A_t_t_r_i_b_u_t_e_N_S_(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _q_u_a_l_i_f_i_e_d_N_a_m_e_,_ _v_a_l_u_e_), an _e_l_e_m_e_n_t may have two attributes (or more) that have the same _N_o_d_e_._n_o_d_e_N_a_m_e, but different _N_o_d_e_._n_a_m_e_s_p_a_c_e_U_R_Is. Calling _E_l_e_m_e_n_t_._g_e_t_A_t_t_r_i_b_u_t_e_(_n_a_m_e_) with that nodeName could then return any of those attributes. The result depends on the implementation. Similarly, using _E_l_e_m_e_n_t_._s_e_t_A_t_t_r_i_b_u_t_e_N_o_d_e_(_n_e_w_A_t_t_r_), one can set two attributes (or more) that have different _N_o_d_e_._n_o_d_e_N_a_m_es but the same _N_o_d_e_._p_r_e_f_i_x and _N_o_d_e_._n_a_m_e_s_p_a_c_e_U_R_I. In this case _E_l_e_m_e_n_t_._g_e_t_A_t_t_r_i_b_u_t_e_N_o_d_e_N_S _(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _l_o_c_a_l_N_a_m_e_) will return either attribute, in an implementation dependent manner. The only guarantee in such cases is that all methods that access a named item by its nodeName will access the same item, and all methods which access a node by its URI and local name will access the same node. For instance, _E_l_e_m_e_n_t_._s_e_t_A_t_t_r_i_b_u_t_e_(_n_a_m_e_,_ _v_a_l_u_e_) and _E_l_e_m_e_n_t_._s_e_t_A_t_t_r_i_b_u_t_e_N_S _(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _q_u_a_l_i_f_i_e_d_N_a_m_e_,_ _v_a_l_u_e_) affect the node that _E_l_e_m_e_n_t_._g_e_t_A_t_t_r_i_b_u_t_e _(_n_a_m_e_) and _E_l_e_m_e_n_t_._g_e_t_A_t_t_r_i_b_u_t_e_N_S_(_n_a_m_e_s_p_a_c_e_U_R_I_,_ _l_o_c_a_l_N_a_m_e_), respectively, return. ******** 11..33..44 BBaassee UURRIIss ******** The DOM Level 3 adds support for the [[bbaassee UURRII]] property defined in [_X_M_L _I_n_f_o_r_m_a_t_i_o_n_ _S_e_t] by providing a new attribute on the _N_o_d_e interface that exposes this information. However, unlike the _N_o_d_e_._n_a_m_e_s_p_a_c_e_U_R_I attribute, the _N_o_d_e_._b_a_s_e_U_R_I attribute is not a static piece of information that every node carries. Instead, it is a value that is dynamically computed according to [_X_M_L _B_a_s_e]. This means its value depends on the location of the node in the tree and moving the node from one place to another in the tree may affect its value. Other changes, such as adding or changing an xml:base attribute on the node being queried or one of its ancestors may also affect its value. One consequence of this it that when external entity references are expanded while building a _D_o_c_u_m_e_n_t one may need to add, or change, an xml:base attribute to the _E_l_e_m_e_n_t nodes originally contained in the entity being expanded so that the _N_o_d_e_._b_a_s_e_U_R_I returns the correct value. In the case of _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n nodes originally contained in the entity being expanded the information is lost. [_D_O_M_ _L_e_v_e_l_ _3_ _L_o_a_d_ _a_n_d_ _S_a_v_e] handles elements as described here and generates a warning in the latter case. ******** 11..33..55 MMiixxeedd DDOOMM IImmpplleemmeennttaattiioonnss ******** As new XML vocabularies are developed, those defining the vocabularies are also beginning to define specialized APIs for manipulating XML instances of those vocabularies. This is usually done by extending the DOM to provide interfaces and methods that perform operations frequently needed by their users. For example, the MathML [_M_a_t_h_M_L_ _2_._0] and SVG [_S_V_G_ _1_._1] specifications have developed DOM extensions to allow users to manipulate instances of these vocabularies using semantics appropriate to images and mathematics, respectively, as well as the generic DOM XML semantics. Instances of SVG or MathML are often embedded in XML documents conforming to a different schema such as XHTML. While the Namespaces in XML specification [_X_M_L_ _N_a_m_e_s_p_a_c_e_s] provides a mechanism for integrating these documents at the syntax level, it has become clear that the DOM Level 2 Recommendation [_D_O_M_ _L_e_v_e_l_ _2_ _C_o_r_e] is not rich enough to cover all the issues that have been encountered in having these different DOM implementations be used together in a single application. DOM Level 3 deals with the requirements brought about by embedding fragments written according to a specific markup language (the embedded component) in a document where the rest of the markup is not written according to that specific markup language (the host document). It does not deal with fragments embedded by reference or linking. A DOM implementation supporting DOM Level 3 Core should be able to collaborate with subcomponents implementing specific DOMs to assemble a compound document that can be traversed and manipulated via DOM interfaces as if it were a seamless whole. The normal typecast operation on an object should support the interfaces expected by legacy code for a given document type. Typecasting techniques may not be adequate for selecting between multiple DOM specializations of an object which were combined at run time, because they may not all be part of the same object as defined by the binding's object model. Conflicts are most obvious with the _D_o_c_u_m_e_n_t object, since it is shared as owner by the rest of the document. In a homogeneous document, elements rely on the Document for specialized services and construction of specialized nodes. In a heterogeneous document, elements from different modules expect different services and APIs from the same _D_o_c_u_m_e_n_t object, since there can only be one owner and root of the document hierarchy. ******** 11..33..66 DDOOMM FFeeaattuurreess ******** Each DOM module defines one or more features, as listed in the conformance section (_C_o_n_f_o_r_m_a_n_c_e). Features are case-insensitive and are also defined for a specific set of versions. For example, this specification defines the features "Core" and "XML", for the version "3.0". Versions "1.0" and "2.0" can also be used for features defined in the corresponding DOM Levels. To avoid possible conflicts, as a convention, names referring to features defined outside the DOM specification should be made unique. Applications could then request for features to be supported by a DOM implementation using the methods _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e_._g_e_t_D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_(_f_e_a_t_u_r_e_s_) or _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e_._g_e_t_D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_L_i_s_t_(_f_e_a_t_u_r_e_s_), check the features supported by a DOM implementation using the method _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._h_a_s_F_e_a_t_u_r_e _(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_), or by a specific node using _N_o_d_e_._i_s_S_u_p_p_o_r_t_e_d_(_f_e_a_t_u_r_e_, _v_e_r_s_i_o_n_). Note that when using the methods that take a feature and a version as parameters, applications can use null or empty string for the version parameter if they don't wish to specify a particular version for the specified feature. Up to the DOM Level 2 modules, all interfaces, that were an extension of existing ones, were accessible using binding-specific casting mechanisms if the feature associated to the extension was supported. For example, an instance of the EventTarget interface could be obtained from an instance of the _N_o_d_e interface if the feature "Events" was supported by the node. As discussed _M_i_x_e_d_ _D_O_M_ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_s, DOM Level 3 Core should be able to collaborate with subcomponents implementing specific DOMs. For that effect, the methods _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._g_e_t_F_e_a_t_u_r_e_(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_) and _N_o_d_e_._g_e_t_F_e_a_t_u_r_e _(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_) were introduced. In the case of _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._h_a_s_F_e_a_t_u_r_e _(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_) and _N_o_d_e_._i_s_S_u_p_p_o_r_t_e_d_(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_), if a plus sign "+" is prepended to any feature name, implementations are considered in which the specified feature may not be directly castable but would require discovery through _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._g_e_t_F_e_a_t_u_r_e_(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_) and _N_o_d_e_._g_e_t_F_e_a_t_u_r_e _(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_). Without a plus, only features whose interfaces are directly castable are considered. // example 1, without prepending the "+" if (myNode.isSupported("Events", "3.0")) { EventTarget evt = (EventTarget) myNode; // ... } // example 2, with the "+" if (myNode.isSupported("+Events", "3.0")) { // (the plus sign "+" is irrelevant for the getFeature method itself // and is ignored by this method anyway) EventTarget evt = (EventTarget) myNode.getFeature("Events", "3.0"); // ... } ******** 11..33..77 BBoooottssttrraappppiinngg ******** Because previous versions of the DOM specification only defined a set of interfaces, applications had to rely on some implementation dependent code to start from. However, hard-coding the application to a specific implementation prevents the application from running on other implementations and from using the most-suitable implementation of the environment. At the same time, implementations may also need to load modules or perform other setup to efficiently adapt to different and sometimes mutually-exclusive feature sets. To solve these problems this specification introduces a DOMImplementationRegistry object with a function that lets an application find implementations, based on the specific features it requires. How this object is found and what it exactly looks like is not defined here, because this cannot be done in a language-independent manner. Instead, each language binding defines its own way of doing this. See _J_a_v_a_ _L_a_n_g_u_a_g_e_ _B_i_n_d_i_n_g and _E_C_M_A_S_c_r_i_p_t _L_a_n_g_u_a_g_e_ _B_i_n_d_i_n_g for specifics. In all cases, though, the DOMImplementationRegistry provides a getDOMImplementation method accepting a features string, which is passed to every known _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e until a suitable _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n is found and returned. The DOMImplementationRegistry also provides a getDOMImplementationList method accepting a features string, which is passed to every known _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e, and returns a list of suitable _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_s. Those two methods are the same as the ones found on the _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e interface. Any number of _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e objects can be registered. A source may return one or more _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n singletons or construct new _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n objects, depending upon whether the requested features require specialized state in the _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n object. ********** 11..44 FFuunnddaammeennttaall IInntteerrffaacceess:: CCoorree MMoodduullee ********** The interfaces within this section are considered ffuunnddaammeennttaall, and must be fully implemented by all conforming implementations of the DOM, including all HTML DOM implementations [_D_O_M_ _L_e_v_e_l_ _2_ _H_T_M_L], unless otherwise specified. A DOM application may use the _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._h_a_s_F_e_a_t_u_r_e_(_f_e_a_t_u_r_e_,_ _v_e_r_s_i_o_n_) method with parameter values "Core" and "3.0" (respectively) to determine whether or not this module is supported by the implementation. Any implementation that conforms to DOM Level 3 or a DOM Level 3 module must conform to the Core module. Please refer to additional information about _cc_oo_nn_ff_oo_rr_mm_aa_nn_cc_ee in this specification. The DOM Level 3 Core module is backward compatible with the DOM Level 2 Core [_D_O_M_ _L_e_v_e_l_ _2_ _C_o_r_e] module, i.e. a DOM Level 3 Core implementation who returns true for "Core" with the version number "3.0" must also return true for this feature when the version number is "2.0", "" or, null. EExxcceeppttiioonn DDOOMMEExxcceeppttiioonn DOM operations only raise exceptions in "exceptional" circumstances, i.e., when an operation is impossible to perform (either for logical reasons, because data is lost, or because the implementation has become unstable). In general, DOM methods return specific error values in ordinary processing situations, such as out-of-bound errors when using _N_o_d_e_L_i_s_t. Implementations should raise other exceptions under other circumstances. For example, implementations should raise an implementation-dependent exception if a null argument is passed when null was not expected. Some languages and object systems do not support the concept of exceptions. For such systems, error conditions may be indicated using native error reporting mechanisms. For some bindings, for example, methods may return error codes similar to those listed in the corresponding method descriptions. IIDDLL DDeeffiinniittiioonn exception _D_O_M_E_x_c_e_p_t_i_o_n { unsigned short code; }; // ExceptionCode const unsigned short _I_N_D_E_X___S_I_Z_E___E_R_R = 1; const unsigned short _D_O_M_S_T_R_I_N_G___S_I_Z_E___E_R_R = 2; const unsigned short _H_I_E_R_A_R_C_H_Y___R_E_Q_U_E_S_T___E_R_R = 3; const unsigned short _W_R_O_N_G___D_O_C_U_M_E_N_T___E_R_R = 4; const unsigned short _I_N_V_A_L_I_D___C_H_A_R_A_C_T_E_R___E_R_R = 5; const unsigned short _N_O___D_A_T_A___A_L_L_O_W_E_D___E_R_R = 6; const unsigned short _N_O___M_O_D_I_F_I_C_A_T_I_O_N___A_L_L_O_W_E_D___E_R_R = 7; const unsigned short _N_O_T___F_O_U_N_D___E_R_R = 8; const unsigned short _N_O_T___S_U_P_P_O_R_T_E_D___E_R_R = 9; const unsigned short _I_N_U_S_E___A_T_T_R_I_B_U_T_E___E_R_R = 10; // Introduced in DOM Level 2: const unsigned short _I_N_V_A_L_I_D___S_T_A_T_E___E_R_R = 11; // Introduced in DOM Level 2: const unsigned short _S_Y_N_T_A_X___E_R_R = 12; // Introduced in DOM Level 2: const unsigned short _I_N_V_A_L_I_D___M_O_D_I_F_I_C_A_T_I_O_N___E_R_R = 13; // Introduced in DOM Level 2: const unsigned short _N_A_M_E_S_P_A_C_E___E_R_R = 14; // Introduced in DOM Level 2: const unsigned short _I_N_V_A_L_I_D___A_C_C_E_S_S___E_R_R = 15; // Introduced in DOM Level 3: const unsigned short _V_A_L_I_D_A_T_I_O_N___E_R_R = 16; // Introduced in DOM Level 3: const unsigned short _T_Y_P_E___M_I_S_M_A_T_C_H___E_R_R = 17; DDeeffiinniittiioonn ggrroouupp EExxcceeppttiioonnCCooddee An integer indicating the type of error generated. NNoottee:: Other numeric codes are reserved for W3C for possible future use. DDeeffiinneedd CCoonnssttaannttss DOMSTRING_SIZE_ERR If the specified range of text does not fit into a _D_O_M_S_t_r_i_n_g. HIERARCHY_REQUEST_ERR If any _N_o_d_e is inserted somewhere it doesn't belong. INDEX_SIZE_ERR If index or size is negative, or greater than the allowed value. INUSE_ATTRIBUTE_ERR If an attempt is made to add an attribute that is already in use elsewhere. INVALID_ACCESS_ERR, introduced in DDOOMM LLeevveell 22. If a parameter or an operation is not supported by the underlying object. INVALID_CHARACTER_ERR If an invalid or illegal character is specified, such as in an XML name. INVALID_MODIFICATION_ERR, introduced in DDOOMM LLeevveell 22. If an attempt is made to modify the type of the underlying object. INVALID_STATE_ERR, introduced in DDOOMM LLeevveell 22. If an attempt is made to use an object that is not, or is no longer, usable. NAMESPACE_ERR, introduced in DDOOMM LLeevveell 22. If an attempt is made to create or change an object in a way which is incorrect with regard to namespaces. NOT_FOUND_ERR If an attempt is made to reference a _N_o_d_e in a context where it does not exist. NOT_SUPPORTED_ERR If the implementation does not support the requested type of object or operation. NO_DATA_ALLOWED_ERR If data is specified for a _N_o_d_e which does not support data. NO_MODIFICATION_ALLOWED_ERR If an attempt is made to modify an object where modifications are not allowed. SYNTAX_ERR, introduced in DDOOMM LLeevveell 22. If an invalid or illegal string is specified. TYPE_MISMATCH_ERR, introduced in DDOOMM LLeevveell 33. If the type of an object is incompatible with the expected type of the parameter associated to the object. VALIDATION_ERR, introduced in DDOOMM LLeevveell 33. If a call to a method such as insertBefore or removeChild would make the _N_o_d_e invalid with respect to _"_p_a_r_t_i_a_l_ _v_a_l_i_d_i_t_y_", this exception would be raised and the operation would not be done. This code is used in [_D_O_M_ _L_e_v_e_l_ _3_ _V_a_l_i_d_a_t_i_o_n]. Refer to this specification for further information. WRONG_DOCUMENT_ERR If a _N_o_d_e is used in a different document than the one that created it (that doesn't support it). IInntteerrffaaccee DDOOMMSSttrriinnggLLiisstt (introduced in DDOOMM LLeevveell 33) The DOMStringList interface provides the abstraction of an ordered collection of _D_O_M_S_t_r_i_n_g values, without defining or constraining how this collection is implemented. The items in the DOMStringList are accessible via an integral index, starting from 0. IIDDLL DDeeffiinniittiioonn // Introduced in DOM Level 3: interface _D_O_M_S_t_r_i_n_g_L_i_s_t { _D_O_M_S_t_r_i_n_g _i_t_e_m(in unsigned long index); readonly attribute unsigned long _l_e_n_g_t_h; boolean _c_o_n_t_a_i_n_s(in _D_O_M_S_t_r_i_n_g str); }; AAttttrriibbuutteess length of type unsigned long, readonly The number of _D_O_M_S_t_r_i_n_gs in the list. The range of valid child node indices is 0 to length-1 inclusive. MMeetthhooddss contains Test if a string is part of this DOMStringList. PPaarraammeetteerrss str of type _D_O_M_S_t_r_i_n_g The string to look for. RReettuurrnn VVaalluuee boolean true if the string has been found, false otherwise. NNoo EExxcceeppttiioonnss item Returns the indexth item in the collection. If index is greater than or equal to the number of _D_O_M_S_t_r_i_n_gs in the list, this returns null. PPaarraammeetteerrss index of type unsigned long Index into the collection. RReettuurrnn VVaalluuee _D_O_M_S_t_r_i_n_g The _D_O_M_S_t_r_i_n_g at the indexth position in the DOMStringList, or null if that is not a valid index. NNoo EExxcceeppttiioonnss IInntteerrffaaccee NNaammeeLLiisstt (introduced in DDOOMM LLeevveell 33) The NameList interface provides the abstraction of an ordered collection of parallel pairs of name and namespace values (which could be null values), without defining or constraining how this collection is implemented. The items in the NameList are accessible via an integral index, starting from 0. IIDDLL DDeeffiinniittiioonn // Introduced in DOM Level 3: interface _N_a_m_e_L_i_s_t { _D_O_M_S_t_r_i_n_g _g_e_t_N_a_m_e(in unsigned long index); _D_O_M_S_t_r_i_n_g _g_e_t_N_a_m_e_s_p_a_c_e_U_R_I(in unsigned long index); readonly attribute unsigned long _l_e_n_g_t_h; boolean _c_o_n_t_a_i_n_s(in _D_O_M_S_t_r_i_n_g str); boolean _c_o_n_t_a_i_n_s_N_S(in _D_O_M_S_t_r_i_n_g namespaceURI, in _D_O_M_S_t_r_i_n_g name); }; AAttttrriibbuutteess length of type unsigned long, readonly The number of pairs (name and namespaceURI) in the list. The range of valid child node indices is 0 to length-1 inclusive. MMeetthhooddss contains Test if a name is part of this NameList. PPaarraammeetteerrss str of type _D_O_M_S_t_r_i_n_g The name to look for. RReettuurrnn VVaalluuee boolean true if the name has been found, false otherwise. NNoo EExxcceeppttiioonnss containsNS Test if the pair namespaceURI/name is part of this NameList. PPaarraammeetteerrss namespaceURI of type _D_O_M_S_t_r_i_n_g The namespace URI to look for. name of type _D_O_M_S_t_r_i_n_g The name to look for. RReettuurrnn VVaalluuee boolean true if the pair namespaceURI/name has been found, false otherwise. NNoo EExxcceeppttiioonnss getName Returns the indexth name item in the collection. PPaarraammeetteerrss index of type unsigned long Index into the collection. RReettuurrnn VVaalluuee _D_O_M_S_t_r_i_n_g The name at the indexth position in the NameList, or null if there is no name for the specified index or if the index is out of range. NNoo EExxcceeppttiioonnss getNamespaceURI Returns the indexth namespaceURI item in the collection. PPaarraammeetteerrss index of type unsigned long Index into the collection. RReettuurrnn VVaalluuee _D_O_M_S_t_r_i_n_g The namespace URI at the indexth position in the NameList, or null if there is no name for the specified index or if the index is out of range. NNoo EExxcceeppttiioonnss IInntteerrffaaccee DDOOMMIImmpplleemmeennttaattiioonnLLiisstt (introduced in DDOOMM LLeevveell 33) The DOMImplementationList interface provides the abstraction of an ordered collection of DOM implementations, without defining or constraining how this collection is implemented. The items in the DOMImplementationList are accessible via an integral index, starting from 0. IIDDLL DDeeffiinniittiioonn // Introduced in DOM Level 3: interface _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_L_i_s_t { _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n _i_t_e_m(in unsigned long index); readonly attribute unsigned long _l_e_n_g_t_h; }; AAttttrriibbuutteess length of type unsigned long, readonly The number of _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_ns in the list. The range of valid child node indices is 0 to length-1 inclusive. MMeetthhooddss item Returns the indexth item in the collection. If index is greater than or equal to the number of _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_ns in the list, this returns null. PPaarraammeetteerrss index of type unsigned long Index into the collection. RReettuurrnn VVaalluuee _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n The _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n at the indexth position in the DOMImplementationList, or null if that is not a valid index. NNoo EExxcceeppttiioonnss IInntteerrffaaccee DDOOMMIImmpplleemmeennttaattiioonnSSoouurrccee (introduced in DDOOMM LLeevveell 33) This interface permits a DOM implementer to supply one or more implementations, based upon requested features and versions, as specified in _D_O_M_ _F_e_a_t_u_r_e_s. Each implemented DOMImplementationSource object is listed in the binding-specific list of available sources so that its _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n objects are made available. IIDDLL DDeeffiinniittiioonn // Introduced in DOM Level 3: interface _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_S_o_u_r_c_e { _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n _g_e_t_D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n(in _D_O_M_S_t_r_i_n_g features); _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_L_i_s_t _g_e_t_D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_L_i_s_t(in _D_O_M_S_t_r_i_n_g features); }; MMeetthhooddss getDOMImplementation A method to request the first DOM implementation that supports the specified features. PPaarraammeetteerrss features of type _D_O_M_S_t_r_i_n_g A string that specifies which features and versions are required. This is a space separated list in which each feature is specified by its name optionally followed by a space and a version number. This method returns the first item of the list returned by getDOMImplementationList. As an example, the string "XML 3.0 Traversal +Events 2.0" will request a DOM implementation that supports the module "XML" for its 3.0 version, a module that support of the "Traversal" module for any version, and the module "Events" for its 2.0 version. The module "Events" must be accessible using the method _N_o_d_e_._g_e_t_F_e_a_t_u_r_e_(_) and _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._g_e_t_F_e_a_t_u_r_e_(_). RReettuurrnn VVaalluuee _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n The first DOM implementation that support the desired features, or null if this source has none. NNoo EExxcceeppttiioonnss getDOMImplementationList A method to request a list of DOM implementations that support the specified features and versions, as specified in _D_O_M_ _F_e_a_t_u_r_e_s. PPaarraammeetteerrss features of type _D_O_M_S_t_r_i_n_g A string that specifies which features and versions are required. This is a space separated list in which each feature is specified by its name optionally followed by a space and a version number. This is something like: "XML 3.0 Traversal +Events 2.0" RReettuurrnn VVaalluuee _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_L_i_s_t A list of DOM implementations that support the desired features. NNoo EExxcceeppttiioonnss IInntteerrffaaccee DDOOMMIImmpplleemmeennttaattiioonn The DOMImplementation interface provides a number of methods for performing operations that are independent of any particular instance of the document object model. IIDDLL DDeeffiinniittiioonn interface _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n { boolean _h_a_s_F_e_a_t_u_r_e(in _D_O_M_S_t_r_i_n_g feature, in _D_O_M_S_t_r_i_n_g version); // Introduced in DOM Level 2: _D_o_c_u_m_e_n_t_T_y_p_e _c_r_e_a_t_e_D_o_c_u_m_e_n_t_T_y_p_e(in _D_O_M_S_t_r_i_n_g qualifiedName, in _D_O_M_S_t_r_i_n_g publicId, in _D_O_M_S_t_r_i_n_g systemId) raises(_D_O_M_E_x_c_e_p_t_i_o_n); // Introduced in DOM Level 2: _D_o_c_u_m_e_n_t _c_r_e_a_t_e_D_o_c_u_m_e_n_t(in _D_O_M_S_t_r_i_n_g namespaceURI, in _D_O_M_S_t_r_i_n_g qualifiedName, in _D_o_c_u_m_e_n_t_T_y_p_e doctype) raises(_D_O_M_E_x_c_e_p_t_i_o_n); // Introduced in DOM Level 3: _D_O_M_O_b_j_e_c_t _g_e_t_F_e_a_t_u_r_e(in _D_O_M_S_t_r_i_n_g feature, in _D_O_M_S_t_r_i_n_g version); }; MMeetthhooddss createDocument introduced in DDOOMM LLeevveell 22 Creates a DOM Document object of the specified type with its document element. Note that based on the _D_o_c_u_m_e_n_t_T_y_p_e given to create the document, the implementation may instantiate specialized _D_o_c_u_m_e_n_t objects that support additional features than the "Core", such as "HTML" [_D_O_M_ _L_e_v_e_l_ _2_ _H_T_M_L]. On the other hand, setting the _D_o_c_u_m_e_n_t_T_y_p_e after the document was created makes this very unlikely to happen. Alternatively, specialized _D_o_c_u_m_e_n_t creation methods, such as createHTMLDocument [_D_O_M _L_e_v_e_l_ _2_ _H_T_M_L], can be used to obtain specific types of _D_o_c_u_m_e_n_t objects. PPaarraammeetteerrss namespaceURI of type _D_O_M_S_t_r_i_n_g The _n_a_m_e_s_p_a_c_e_ _U_R_I of the document element to create or null. qualifiedName of type _D_O_M_S_t_r_i_n_g The _q_u_a_l_i_f_i_e_d_ _n_a_m_e of the document element to be created or null. doctype of type _D_o_c_u_m_e_n_t_T_y_p_e The type of document to be created or null. When doctype is not null, its _N_o_d_e_._o_w_n_e_r_D_o_c_u_m_e_n_t attribute is set to the document being created. RReettuurrnn VVaalluuee _D_o_c_u_m_e_n_t A new _D_o_c_u_m_e_n_t object with its document element. If the NamespaceURI, qualifiedName, and doctype are null, the returned _D_o_c_u_m_e_n_t is empty with no document element. EExxcceeppttiioonnss _D_O_M_E_x_c_e_p_t_i_o_n INVALID_CHARACTER_ERR: Raised if the specified qualified name is not an XML name according to [_X_M_L_ _1_._0]. NAMESPACE_ERR: Raised if the qualifiedName is malformed, if the qualifiedName has a prefix and the namespaceURI is null, or if the qualifiedName is null and the namespaceURI is different from null, or if the qualifiedName has a prefix that is "xml" and the namespaceURI is different from "_h_t_t_p_:_/_/_w_w_w_._w_3_._o_r_g_/_X_M_L_/_1_9_9_8_/ _n_a_m_e_s_p_a_c_e" [_X_M_L_ _N_a_m_e_s_p_a_c_e_s], or if the DOM implementation does not support the "XML" feature but a non-null namespace URI was provided, since namespaces were defined by XML. WRONG_DOCUMENT_ERR: Raised if doctype has already been used with a different document or was created from a different implementation. NOT_SUPPORTED_ERR: May be raised if the implementation does not support the feature "XML" and the language exposed through the Document does not support XML Namespaces (such as [_H_T_M_L_ _4_._0_1]). createDocumentType introduced in DDOOMM LLeevveell 22 Creates an empty _D_o_c_u_m_e_n_t_T_y_p_e node. Entity declarations and notations are not made available. Entity reference expansions and default attribute additions do not occur.. PPaarraammeetteerrss qualifiedName of type _D_O_M_S_t_r_i_n_g The _q_u_a_l_i_f_i_e_d_ _n_a_m_e of the document type to be created. publicId of type _D_O_M_S_t_r_i_n_g The external subset public identifier. systemId of type _D_O_M_S_t_r_i_n_g The external subset system identifier. RReettuurrnn VVaalluuee _D_o_c_u_m_e_n_t_T_y_p_e A new _D_o_c_u_m_e_n_t_T_y_p_e node with _N_o_d_e_._o_w_n_e_r_D_o_c_u_m_e_n_t set to null. EExxcceeppttiioonnss _D_O_M_E_x_c_e_p_t_i_o_n INVALID_CHARACTER_ERR: Raised if the specified qualified name is not an XML name according to [_X_M_L_ _1_._0]. NAMESPACE_ERR: Raised if the qualifiedName is malformed. NOT_SUPPORTED_ERR: May be raised if the implementation does not support the feature "XML" and the language exposed through the Document does not support XML Namespaces (such as [_H_T_M_L_ _4_._0_1]). getFeature introduced in DDOOMM LLeevveell 33 This method returns a specialized object which implements the specialized APIs of the specified feature and version, as specified in _D_O_M_ _F_e_a_t_u_r_e_s. The specialized object may also be obtained by using binding-specific casting methods but is not necessarily expected to, as discussed in _M_i_x_e_d_ _D_O_M _I_m_p_l_e_m_e_n_t_a_t_i_o_n_s. This method also allow the implementation to provide specialized objects which do not support the DOMImplementation interface. PPaarraammeetteerrss feature of type _D_O_M_S_t_r_i_n_g The name of the feature requested. Note that any plus sign "+" prepended to the name of the feature will be ignored since it is not significant in the context of this method. version of type _D_O_M_S_t_r_i_n_g This is the version number of the feature to test. RReettuurrnn VVaalluuee _D_O_M_O_b_j_e_c_t Returns an object which implements the specialized APIs of the specified feature and version, if any, or null if there is no object which implements interfaces associated with that feature. If the _D_O_M_O_b_j_e_c_t returned by this method implements the DOMImplementation interface, it must delegate to the primary core DOMImplementation and not return results inconsistent with the primary core DOMImplementation such as hasFeature, getFeature, etc. NNoo EExxcceeppttiioonnss hasFeature Test if the DOM implementation implements a specific feature and version, as specified in _D_O_M_ _F_e_a_t_u_r_e_s. PPaarraammeetteerrss feature of type _D_O_M_S_t_r_i_n_g The name of the feature to test. version of type _D_O_M_S_t_r_i_n_g This is the version number of the feature to test. RReettuurrnn VVaalluuee boolean true if the feature is implemented in the specified version, false otherwise. NNoo EExxcceeppttiioonnss IInntteerrffaaccee DDooccuummeennttFFrraaggmmeenntt DocumentFragment is a "lightweight" or "minimal" _D_o_c_u_m_e_n_t object. It is very common to want to be able to extract a portion of a document's tree or to create a new fragment of a document. Imagine implementing a user command like cut or rearranging a document by moving fragments around. It is desirable to have an object which can hold such fragments and it is quite natural to use a Node for this purpose. While it is true that a _D_o_c_u_m_e_n_t object could fulfill this role, a _D_o_c_u_m_e_n_t object can potentially be a heavyweight object, depending on the underlying implementation. What is really needed for this is a very lightweight object. DocumentFragment is such an object. Furthermore, various operations -- such as inserting nodes as children of another _N_o_d_e -- may take DocumentFragment objects as arguments; this results in all the child nodes of the DocumentFragment being moved to the child list of this node. The children of a DocumentFragment node are zero or more nodes representing the tops of any sub-trees defining the structure of the document. DocumentFragment nodes do not need to be _w_e_l_l_-_f_o_r_m_e_d_ _X_M_L _d_o_c_u_m_e_n_t_s (although they do need to follow the rules imposed upon well- formed XML parsed entities, which can have multiple top nodes). For example, a DocumentFragment might have only one child and that child node could be a _T_e_x_t node. Such a structure model represents neither an HTML document nor a well-formed XML document. When a DocumentFragment is inserted into a _D_o_c_u_m_e_n_t (or indeed any other _N_o_d_e that may take children) the children of the DocumentFragment and not the DocumentFragment itself are inserted into the _N_o_d_e. This makes the DocumentFragment very useful when the user wishes to create nodes that are _s_i_b_l_i_n_g_s; the DocumentFragment acts as the parent of these nodes so that the user can use the standard methods from the _N_o_d_e interface, such as _N_o_d_e_._i_n_s_e_r_t_B_e_f_o_r_e and _N_o_d_e_._a_p_p_e_n_d_C_h_i_l_d. IIDDLL DDeeffiinniittiioonn interface _D_o_c_u_m_e_n_t_F_r_a_g_m_e_n_t : _N_o_d_e { }; IInntteerrffaaccee DDooccuummeenntt The Document interface represents the entire HTML or XML document. Conceptually, it is the _r_o_o_t of the document tree, and provides the primary access to the document's data. Since elements, text nodes, comments, processing instructions, etc. cannot exist outside the context of a Document, the Document interface also contains the factory methods needed to create these objects. The _N_o_d_e objects created have a ownerDocument attribute which associates them with the Document within whose context they were created. IIDDLL DDeeffiinniittiioonn interface _D_o_c_u_m_e_n_t : _N_o_d_e { // Modified in DOM Level 3: readonly attribute _D_o_c_u_m_e_n_t_T_y_p_e _d_o_c_t_y_p_e; readonly attribute _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n _i_m_p_l_e_m_e_n_t_a_t_i_o_n; readonly attribute _E_l_e_m_e_n_t _d_o_c_u_m_e_n_t_E_l_e_m_e_n_t; _E_l_e_m_e_n_t _c_r_e_a_t_e_E_l_e_m_e_n_t(in _D_O_M_S_t_r_i_n_g tagName) raises(_D_O_M_E_x_c_e_p_t_i_o_n); _D_o_c_u_m_e_n_t_F_r_a_g_m_e_n_t _c_r_e_a_t_e_D_o_c_u_m_e_n_t_F_r_a_g_m_e_n_t(); _T_e_x_t _c_r_e_a_t_e_T_e_x_t_N_o_d_e(in _D_O_M_S_t_r_i_n_g data); _C_o_m_m_e_n_t _c_r_e_a_t_e_C_o_m_m_e_n_t(in _D_O_M_S_t_r_i_n_g data); _C_D_A_T_A_S_e_c_t_i_o_n _c_r_e_a_t_e_C_D_A_T_A_S_e_c_t_i_o_n(in _D_O_M_S_t_r_i_n_g data) raises(_D_O_M_E_x_c_e_p_t_i_o_n); _P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n _c_r_e_a_t_e_P_r_o_c_e_s_s_i_n_g_I_n_s_t_r_u_c_t_i_o_n(in _D_O_M_S_t_r_i_n_g target, in _D_O_M_S_t_r_i_n_g data) raises(_D_O_M_E_x_c_e_p_t_i_o_n); _A_t_t_r _c_r_e_a_t_e_A_t_t_r_i_b_u_t_e(in _D_O_M_S_t_r_i_n_g name) raises(_D_O_M_E_x_c_e_p_t_i_o_n); _E_n_t_i_t_y_R_e_f_e_r_e_n_c_e _c_r_e_a_t_e_E_n_t_i_t_y_R_e_f_e_r_e_n_c_e(in _D_O_M_S_t_r_i_n_g name) raises(_D_O_M_E_x_c_e_p_t_i_o_n); _N_o_d_e_L_i_s_t _g_e_t_E_l_e_m_e_n_t_s_B_y_T_a_g_N_a_m_e(in _D_O_M_S_t_r_i_n_g tagname); // Introduced in DOM Level 2: _N_o_d_e _i_m_p_o_r_t_N_o_d_e(in _N_o_d_e importedNode, in boolean deep) raises(_D_O_M_E_x_c_e_p_t_i_o_n); // Introduced in DOM Level 2: _E_l_e_m_e_n_t _c_r_e_a_t_e_E_l_e_m_e_n_t_N_S(in _D_O_M_S_t_r_i_n_g namespaceURI, in _D_O_M_S_t_r_i_n_g qualifiedName) raises(_D_O_M_E_x_c_e_p_t_i_o_n); // Introduced in DOM Level 2: _A_t_t_r _c_r_e_a_t_e_A_t_t_r_i_b_u_t_e_N_S(in _D_O_M_S_t_r_i_n_g namespaceURI, in _D_O_M_S_t_r_i_n_g qualifiedName) raises(_D_O_M_E_x_c_e_p_t_i_o_n); // Introduced in DOM Level 2: _N_o_d_e_L_i_s_t _g_e_t_E_l_e_m_e_n_t_s_B_y_T_a_g_N_a_m_e_N_S(in _D_O_M_S_t_r_i_n_g namespaceURI, in _D_O_M_S_t_r_i_n_g localName); // Introduced in DOM Level 2: _E_l_e_m_e_n_t _g_e_t_E_l_e_m_e_n_t_B_y_I_d(in _D_O_M_S_t_r_i_n_g elementId); // Introduced in DOM Level 3: readonly attribute _D_O_M_S_t_r_i_n_g _i_n_p_u_t_E_n_c_o_d_i_n_g; // Introduced in DOM Level 3: readonly attribute _D_O_M_S_t_r_i_n_g _x_m_l_E_n_c_o_d_i_n_g; // Introduced in DOM Level 3: attribute boolean _x_m_l_S_t_a_n_d_a_l_o_n_e; // raises(_D_O_M_E_x_c_e_p_t_i_o_n) on setting // Introduced in DOM Level 3: attribute _D_O_M_S_t_r_i_n_g _x_m_l_V_e_r_s_i_o_n; // raises(_D_O_M_E_x_c_e_p_t_i_o_n) on setting // Introduced in DOM Level 3: attribute boolean _s_t_r_i_c_t_E_r_r_o_r_C_h_e_c_k_i_n_g; // Introduced in DOM Level 3: attribute _D_O_M_S_t_r_i_n_g _d_o_c_u_m_e_n_t_U_R_I; // Introduced in DOM Level 3: _N_o_d_e _a_d_o_p_t_N_o_d_e(in _N_o_d_e source) raises(_D_O_M_E_x_c_e_p_t_i_o_n); // Introduced in DOM Level 3: readonly attribute _D_O_M_C_o_n_f_i_g_u_r_a_t_i_o_n _d_o_m_C_o_n_f_i_g; // Introduced in DOM Level 3: void _n_o_r_m_a_l_i_z_e_D_o_c_u_m_e_n_t(); // Introduced in DOM Level 3: _N_o_d_e _r_e_n_a_m_e_N_o_d_e(in _N_o_d_e n, in _D_O_M_S_t_r_i_n_g namespaceURI, in _D_O_M_S_t_r_i_n_g qualifiedName) raises(_D_O_M_E_x_c_e_p_t_i_o_n); }; AAttttrriibbuutteess doctype of type _D_o_c_u_m_e_n_t_T_y_p_e, readonly, modified in DDOOMM LLeevveell 33 The Document Type Declaration (see _D_o_c_u_m_e_n_t_T_y_p_e) associated with this document. For XML documents without a document type declaration this returns null. For HTML documents, a _D_o_c_u_m_e_n_t_T_y_p_e object may be returned, independently of the presence or absence of document type declaration in the HTML document. This provides direct access to the _D_o_c_u_m_e_n_t_T_y_p_e node, child node of this Document. This node can be set at document creation time and later changed through the use of child nodes manipulation methods, such as _N_o_d_e_._i_n_s_e_r_t_B_e_f_o_r_e, or _N_o_d_e_._r_e_p_l_a_c_e_C_h_i_l_d. Note, however, that while some implementations may instantiate different types of Document objects supporting additional features than the "Core", such as "HTML" [_D_O_M_ _L_e_v_e_l_ _2_ _H_T_M_L], based on the _D_o_c_u_m_e_n_t_T_y_p_e specified at creation time, changing it afterwards is very unlikely to result in a change of the features supported. documentElement of type _E_l_e_m_e_n_t, readonly This is a _c_o_n_v_e_n_i_e_n_c_e attribute that allows direct access to the child node that is the _d_o_c_u_m_e_n_t_ _e_l_e_m_e_n_t of the document. documentURI of type _D_O_M_S_t_r_i_n_g, introduced in DDOOMM LLeevveell 33 The location of the document or null if undefined or if the Document was created using _D_O_M_I_m_p_l_e_m_e_n_t_a_t_i_o_n_._c_r_e_a_t_e_D_o_c_u_m_e_n_t. No lexical checking is performed when setting this attribute; this could result in a null value returned when using _N_o_d_e_._b_a_s_e_U_R_I. Beware that when the Document supports the feature "HTML" [_D_O_M_ _L_e_v_e_l_ _2_ _H_T_M_L], the href attribute of the HTML BASE element takes precedence over this attribute whe