Document Object Model Core (DOM1)

Ceviz Viki, özgür ansiklopedi

http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html

1. Döküman Nesne Modeli Çekirdeği

Editors
Mike Champion, ArborText (from November 20, 1997)
Steve Byrne, JavaSoft (until November 19, 1997)
Gavin Nicol, Inso EPS
Lauren Wood, SoftQuad, Inc.

İçindekiler tablosu

1. DOM Çekirdek arayüzlerine genel bir bakış
   1. DOM Yapısı
   2. Hafıza yönetimi
   3. İsimlendirme kuralları
   4. Miras & API nin düz görünümleri (not: Flattened views için düz görünümden daha iyi bir ifade bulunmalı)
   5. DOMString tipi
   6. DOM içinde string karşılaştırmaları
2. Temel arayüzler (DOMException, ExceptionCode, DOMImplementation, DocumentFragment, Document, Node, NodeList, NamedNodeMap, CharacterData, Attr, Element, Text, Comment)
   
3. Genişletilmiş arayüzler (CDATASection, DocumentType, Notation, Entity, EntityReference, ProcessingInstruction)

• 1.1. Overview of the DOM Core Interfaces
  o 1.1.1. The DOM Structure Model
  o 1.1.2. Memory Management
  o 1.1.3. Naming Conventions
  o 1.1.4. Inheritance vs. Flattened Views of the API
  o 1.1.5. The DOMString type
  o 1.1.6. String comparisons in the DOM
  * 1.2. Fundamental Interfaces
  o DOMException, ExceptionCode, DOMImplementation, DocumentFragment, Document, Node, NodeList, NamedNodeMap, CharacterData, Attr, Element, Text, Comment
  * 1.3. Extended Interfaces
  o CDATASection, DocumentType, Notation, Entity, EntityReference, ProcessingInstruction

1.1 DOM Çekirdek arayüzlerine genel bir bakış

Bu kısım döküman* nesnelerine ulaşmak ve onları kullanmak için kullanılan nesneleri ve arayüzleri tanımlar. (*Not: Döküman nesnesi ile kastedilen herhangi bir belgenin kökü olan Document nesnesidir.) Bu bölümde belirtilen işlevsellik (çekirdek-temel işlevsellik) yazılım geliştiriciler ve javascript yazarlarının yorumlanmış HTML ve XML içeriğini yorumlaması için yeterlidir. Çekirdek API ayrıca sadece bu API ye yapılan çağrılarla döküman oluşturma ve onların içinin doldurulmasına da izin verir, dökümanı yüklemek ve onu kalıcı bir yere* (*not:diske saklamak veya internet üzerinden stream olarak göndermek) saklamak DOM API sini kullanan ürüne (programa veya scripte) kalmıştır.

1.1. Overview of the DOM Core Interfaces

This section defines a set of objects and interfaces for accessing and manipulating document objects. The functionality specified in this section (the Core functionality) is sufficient to allow software developers and web script authors to access and manipulate parsed HTML and XML content inside conforming products. The DOM Core API also allows creation and population of a Document object using only DOM API calls; loading a Document and saving it persistently is left to the product that implements the DOM API.

1.1.1. DOM Yapısı

DOM dökümanları (document) düğüm (Node) nesnelerinin bir hiyerarşisi şeklinde sunabilir, ayrıca daha özel arayüzler de sunar. Bazı düğümler (Node) çeşitli alt düğümler içerirken, bazıları ise düzdür ve kendi altlarında bir yapı barındıramazlar. XML ve HTML için, alt düğümler içeren düğümler aşağıdaki gibidir :

1.1.1. The DOM Structure Model

The DOM presents documents as a hierarchy of Node objects that also implement other, more specialized interfaces. Some types of nodes may have child 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:

• Document -- Element (maximum of one), ProcessingInstruction, Comment, DocumentType (maximum of one)
  * DocumentFragment -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference
  * DocumentType -- no children
  * EntityReference -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference
  * Element -- Element, Text, Comment, ProcessingInstruction, CDATASection, EntityReference
  * Attr -- Text, EntityReference
  * ProcessingInstruction -- no children
  * Comment -- no children
  * Text -- no children
  * CDATASection -- no children
  * Entity -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference
  * Notation -- no children

The DOM also specifies a NodeList interface to handle ordered lists of Nodes, such as the children of a Node, or the elements returned by the getElementsByTagName method of the Element interface, and also a NamedNodeMap interface to handle unordered sets of nodes referenced by their name attribute, such as the attributes of an Element. NodeList and NamedNodeMap objects in the DOM are live; that is, changes to the underlying document structure are reflected in all relevant NodeList and NamedNodeMap objects. For example, if a DOM user gets a NodeList object containing the children of an Element, then subsequently adds more children to that element (or removes children, or modifies them), those changes are automatically reflected in the NodeList, without further action on the user's part. Likewise, changes to a Node in the tree are reflected in all references to that Node in NodeList and NamedNodeMap objects.

Finally, the interfaces Text, Comment, and CDATASection all inherit from the CharacterData interface.
1.1.2. Memory Management

Most of the APIs defined by this specification are interfaces 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 factory methods that create instances of objects that implement the various interfaces. In the DOM Level 1, objects implementing some interface "X" are created by a "createX()" method on the Document interface; this is because all DOM objects live in the context of a specific Document.

The DOM Level 1 API does not define a standard way to create DOMImplementation or Document objects; DOM implementations must provide some proprietary way of bootstrapping these DOM interfaces, and then all other objects can be built from there.

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 devised by the DOM Working Group (for ECMAScript 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.