text:
BIND

BIND is a suite of software for interacting with the Domain Name System (DNS). Its most prominent component, named (pronounced name-dee:, short for name daemon), performs both of the main DNS server roles, acting as an authoritative name server for DNS zones and as a recursive resolver in the network. As of 2015, it is the most widely used domain name server software,  and is the de facto standard on Unix-like operating systems. Also contained in the suite are various administration tools such as nsupdate and dig, and a DNS resolver interface library.

The software was originally designed at the University of California, Berkeley (UCB) in the early 1980s. The name originates as an acronym of Berkeley Internet Name Domain, reflecting the application's use within UCB. The current version is BIND 9, first released in 2000 and still actively maintained by the Internet Systems Consortium (ISC) with new releases issued several times a year.

Key features
BIND 9 is intended to be fully compliant with the IETF DNS standards and draft standards. Important features of BIND 9 include: TSIG, nsupdate, IPv6, RNDC (remote name daemon control), views, multiprocessor support, Response Rate Limiting (RRL), DNSSEC, and broad portability. RNDC enables remote configuration updates, using a shared secret to provide encryption for local and remote terminals during each session.

Database support
While earlier versions of BIND offered no mechanism to store and retrieve zone data in anything other than flat text files, in 2007 BIND 9.4 DLZ provided a compile-time option for zone storage in a variety of database formats including LDAP, Berkeley DB, PostgreSQL, MySQL, and ODBC.

BIND 10 planned to make the data store modular, so that a variety of databases may be connected. In 2016 ISC added support for the 'dyndb' interface, contributed by RedHat, with BIND version 9.11.0.

Security
Security issues that are discovered in BIND 9 are patched and publicly disclosed in keeping with common principles of open source software. A complete list of security defects that have been discovered and disclosed in BIND9 is maintained by Internet Systems Consortium, the current authors of the software.

The BIND 4 and BIND 8 releases both had serious security vulnerabilities. Use of these ancient versions, or any un-maintained, non-supported version is strongly discouraged. BIND 9 was a complete rewrite, in part to mitigate these ongoing security issues. The downloads page on the ISC web site clearly shows which versions are currently maintained and which are end of life.

History
BIND was originally written by four graduate students at the Computer Systems Research Group (CSRG) at the University of California, Berkeley, Douglas Terry, Mark Painter, David Riggle and Songnian Zhou, in the early 1980s as a result of a DARPA grant. The acronym BIND is for Berkeley Internet Name Domain, from a technical paper published in 1984. It was first released with Berkeley Software Distribution 4.3BSD.

Versions of BIND through 4.8.3 were maintained by the CSRG.

Paul Vixie of Digital Equipment Corporation (DEC) took over BIND development in 1988, releasing versions 4.9 and 4.9.1. Vixie continued to work on BIND after leaving DEC. BIND Version 4.9.2 was sponsored by Vixie Enterprises. Vixie eventually founded the Internet Software Consortium (ISC), which became the entity responsible for BIND versions starting with 4.9.3.

BIND 8 was released by ISC in May 1997.

Version 9 was developed by Nominum, Inc. under an ISC outsourcing contract, and the first version was released 9 October 2000. It was written from scratch in part to address the architectural difficulties with auditing the earlier BIND code bases, and also to support DNSSEC (DNS Security Extensions). The development of BIND 9 took place under a combination of commercial and military contracts. Most of the features of BIND 9 were funded by UNIX vendors who wanted to ensure that BIND stayed competitive with Microsoft's DNS offerings; the DNSSEC features were funded by the US military, which regarded DNS security as important. BIND 9 was released in September 2000.

In 2009, ISC started an effort to develop a new version of the software suite, initially called BIND10. In addition to DNS service, the BIND10 suite also included IPv4 and IPv6 DHCP server components. In April 2014, with BIND10 release 1.2.0 the ISC concluded its involvement in the project and renamed it to Bundy, moving the source code repository to GitHub for further development by outside public efforts. ISC discontinued its involvement in the project due to cost-cutting measures. The development of DHCP components was split off to become a new Kea project.

title: BIND


text:
Djbdns

The djbdns software package is a DNS implementation. It was created by Daniel J. Bernstein in response to his frustrations with repeated security holes in the widely used BIND DNS software. As a challenge, Bernstein offered a $1000 prize for the first person to find a security hole in djbdns, which was awarded in March 2009 to Matthew Dempsky.

, djbdns's tinydns component was the second most popular DNS server in terms of the number of domains for which it was the authoritative server, and third most popular in terms of the number of DNS hosts running it.

djbdns has never been vulnerable to the widespread cache poisoning vulnerability reported in July 2008, but it has been discovered that it is vulnerable to a related attack.

The source code has not been centrally managed since its release in 2001, and was released into the public domain in 2007. As of March 2009, there are a number of forks, one of which is dbndns (part of the Debian Project), and more than a dozen patches to modify the released version.

While djbdns does not directly support DNSSEC, there are third party patches to add DNSSEC support to djbdns' authoritative-only tinydns component.

Components
The djbdns software consists of servers, clients, and miscellaneous configuration tools.

Servers

 * dnscache — the DNS resolver and cache.
 * tinydns — a database-driven DNS server.
 * walldns — a "reverse DNS wall", providing IP address-to-domain name lookup only.
 * rbldns — a server designed for DNS blacklisting service.
 * pickdns — a database-driven server that chooses from matching records depending on the requestor's location. (This feature is now a standard part of tinydns.)
 * axfrdns — a zone transfer server.

Client tools

 * axfr-get — a zone-transfer client.
 * dnsip — simple address from name lookup.
 * dnsipq — address from name lookup with rewriting rules.
 * dnsname — simple name from address lookup.
 * dnstxt — simple text record from name lookup.
 * dnsmx — mail exchanger lookup.
 * dnsfilter — looks up names for addresses read from stdin, in parallel.
 * dnsqr — recursive general record lookup.
 * dnsq — non-recursive general record lookup, useful for debugging.
 * dnstrace (and dnstracesort) — comprehensive testing of the chains of authority over DNS servers and their names.

Design
In djbdns, different features and services are split off into separate programs. For example, zone transfers, zone file parsing, caching, and recursive resolving are implemented as separate programs. The result of these design decisions is a reduction in code size and complexity of the daemon program that provides the core function of answering lookup requests. Bernstein asserts that this is true to the spirit of the Unix operating system, and makes security verification much simpler.

Copyright status
On December 28, 2007, Bernstein released djbdns into the public domain. Previously the package was distributed free of charge as license-free software. However this did not permit the distribution of modified versions of djbdns, which was one of the core principles of open-source software. Consequently, it was not included in those Linux distributions which required all components to be open-source.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Djbdns


text:
User talk:Ddroar

Welcome to wiki. He/she/it has created a number of stubby articles including Scud, Turboprop, Malaria, Quinine, Quasi-autonomous non-government organisation (not so stubby) and Brick. As well as some other Q's which have been jumped all over by Paul 'Wikipedia is not a dictionary' Drye.

I recommend that you write your stubs in Wikipedia style, not dictionary style. e.g. see my super-minor edit of quintuplet to make it more Wikipediesque. It makes adding to the article easier for others, and is less jarring. --TheCunctator

Thanks. Much appreciated input, as was making the big mistake of feeling my way, and not reading all the how to type documents. I promise that I have become much more detailed in my posts, and the dictionary definitions are dead and buried. Ddroar

Welcome Dave! I hope your first experiences here aren't too discouraging. There's no problem with contributing stub articles (our name for very small new pages); check out Larry Sanger/The Perfect Stub Article for some suggestions (pretty good ones, IMHO) on creating stubs. --Stephen Gilbert

Hello, Dave. Nothing personal about the entries I removed, I hope you realize. Some of them I did leave in as stubs that may grow one day, but the others didn't strike me as having much hope of being expanded in the manner of an encyclopedia article. Quail stayed, Quiver didn't. Bear in mind that's there's nothing stopping you from changing them back, or adding more to them to show one and all that I'm out to lunch.

Welcome to Wikipedia -- Paul Drye

Olive branch accepted gratefully, as is advice and help. I stand by my 'offend the experts theory', though, as hopefully the flurry of activity on quiver has demonstrated. I am of the (perhaps naive) opinion that some info is better than none, and it appears that stubby info offends so many people, that they feel obliged to fill it in! Either way I can see this as a win-win for Wikipedia and people on both sides of the stubs debate.

This is a fascinating and stimulating community and project, you have a new member hooked! Ddroar

I wouldn't trust me on this. I suggest asking drBob, who usually goes around correcting my mistakes. Also, you appear to be vastly more qualified than me. However I would have thought that geometric isomerism would be independent of the isotopic mass - the properties would be very similar (identical?).

Heh, Sodium does me way to much credit. I've not actually used much chemistry since my A-levels, but as I understand it, it doesn't matter what the two functional groups are (so they can be the same (e.g. two chlorines) or totally different (e.g. chlorine and an OH). It's only their positions that matter - if they are on the same side, is a cis, and if they are on opposite sides, it's a trans. Hope that answers your question. -- DrBob

title: User talk:Ddroar


text:
Dylan (programming language)

Dylan is a multi-paradigm programming language that includes support for functional and object-oriented programming (OOP), and is dynamic and reflective while providing a programming model designed to support generating efficient machine code, including fine-grained control over dynamic and static behaviors. It was created in the early 1990s by a group led by Apple Computer.

Dylan derives from Scheme and Common Lisp and adds an integrated object system derived from the Common Lisp Object System (CLOS). In Dylan, all values (including numbers, characters, functions, and classes) are first-class objects. Dylan supports multiple inheritance, polymorphism, multiple dispatch, keyword arguments, object introspection, pattern-based syntax extension macros, and many other advanced features. Programs can express fine-grained control over dynamism, admitting programs that occupy a continuum between dynamic and static programming and supporting evolutionary development (allowing for rapid prototyping followed by incremental refinement and optimization).

Dylan's main design goal is to be a dynamic language well-suited for developing commercial software. Dylan attempts to address potential performance issues by introducing "natural" limits to the full flexibility of Lisp systems, allowing the compiler to clearly understand compilable units, such as libraries.

Dylan derives much of its semantics from Scheme and other Lisps; some Dylan implementations were initially built within extant Lisp systems. However, Dylan has an ALGOL-like syntax instead of a Lisp-like prefix syntax.

History
Dylan was created in the early 1990s by a group led by Apple Computer. At one time in its development, it was intended for use with the Apple Newton computer, but the Dylan implementation did not reach sufficient maturity in time, and Newton instead used a mix of C and the NewtonScript developed by Walter Smith. Apple ended their Dylan development effort in 1995, though they made a "technology release" version available (Apple Dylan TR1) that included an advanced integrated development environment (IDE).

Two other groups contributed to the design of the language and developed implementations: Harlequin released a commercial IDE for Microsoft Windows and Carnegie Mellon University released an open source compiler for Unix systems called Gwydion Dylan. Both of these implementations are now open source. The Harlequin implementation is now named Open Dylan and is maintained by a group of volunteers, the Dylan Hackers.

The Dylan language was code-named Ralph. James Joaquin chose the name Dylan for "DYnamic LANguage."

Syntax
Many of Dylan's syntax features come from its Lisp heritage. Originally, Dylan used a Lisp-like prefix syntax, which was based on s-expressions. By the time the language design was completed, the syntax was changed to an ALGOL-like syntax, with the expectation that it would be more familiar to a wider audience of programmers. The syntax was designed by Michael Kahl. It is described in great detail in the Dylan Reference Manual.

Lexical syntax
Dylan is not case sensitive. Dylan's lexical syntax allows the use of a naming convention where hyphen (minus) signs are used to connect the parts of multiple-word identifiers (sometimes called "lisp-case" or "kebab case"). This convention is common in Lisp languages.

Besides alphanumeric characters and hyphen-minus signs, Dylan allows a variety of non-alphanumeric characters as part of identifiers. Identifiers may not consist of these non-alphanumeric characters alone. If there is any ambiguity, whitespace is used.

Example code
A simple class with several slots:

By convention, classes are named with less-than and greater-than signs used as angle brackets, e.g. the class named  in the code example.

In  both   and   are optional. This is true for all  clauses. For example, you may write  or just   to terminate an   statement.

To make an instance of :

The same class, rewritten in the most minimal way possible:

The slots are now both typed as. The slots must be initialized manually:

By convention, constant names begin with "$":

A factorial function:

Here,  and   are just normal identifiers.

There is no explicit return statement. The result of a method or function is the last expression evaluated. It is a common style to leave off the semicolon after an expression in return position.

Modules vs. namespace
In many object-oriented languages, classes are the main means of encapsulation and modularity; each class defines a namespace and controls which definitions are externally visible. Further, classes in many languages define an indivisible unit that must be used as a whole. For example, using a  concatenation function requires importing and compiling against all of.

Some languages, including Dylan, also include a separate, explicit namespace or module system that performs encapsulation in a more general way.

In Dylan, the concepts of compile-unit and import-unit are separated, and classes have nothing specifically to do with either. A library defines items that should be compiled and handled together, while a module defines a namespace. Classes can be placed together in modules, or cut across them, as the programmer wishes. Often the complete definition for a class does not exist in a single module, but is spread across several that are optionally collected together. Different programs can have different definitions of the same class, including only what they need.

For example, consider an add-on library for regex support on. In some languages, for the functionality to be included in strings, the functionality must be added to the  namespace. As soon as this occurs, the  class becomes larger, and functions that don't need to use regex still must "pay" for it in increased library size. For this reason, these sorts of add-ons are typically placed in their own namespaces and objects. The downside to this approach is that the new functions are no longer a part of ; instead, it is isolated in its own set of functions that must be called separately. Instead of, which would be the natural organization from an OO viewpoint,  something like   is used, which effectively reverses the ordering.

Under Dylan, many interfaces can be defined for the same code, for instance the String concatenation method could be placed in both the String interface, and the "concat" interface which collects together all of the different concatenation functions from various classes. This is more commonly used in math libraries, where functions tend to be applicable to widely differing object types.

A more practical use of the interface construct is to build public and private versions of a module, something that other languages include as a bolt on feature that invariably causes problems and adds syntax. Under Dylan, every function call can be simply placed in the "Private" or "Development" interface, and collect up publicly accessible functions in. Under Java or C++ the visibility of an object is defined in the code, meaning that to support a similar change, a programmer would be forced to rewrite the definitions fully, and could not have two versions at the same time.

Classes
Classes in Dylan describe  (data members, fields, ivars, etc.) of objects in a fashion similar to most OO languages. All access to slots is via methods, as in Smalltalk. Default getter and setter methods are automatically generated based on the slot names. In contrast with most other OO languages, other methods applicable to the class are often defined outside of the class, and thus class definitions in Dylan typically include the definition of the storage only. For instance:

In this example, the class " " is defined. The <class name> syntax is convention only, to make the class names stand out—the angle brackets are merely part of the class name. In contrast, in some languages the convention is to capitalize the first letter of the class name or to prefix the name with a C or T (for example). inherits from a single class,, and contains two slots,   holding a string for the window title, and   holding an X-Y point for a corner of the window. In this example, the title has been given a default value, while the position has not. The optional init-keyword syntax allows the programmer to specify the initial value of the slot when instantiating an object of the class.

In languages such as C++ or Java, the class would also define its interface. In this case the definition above has no explicit instructions, so in both languages access to the slots and methods is considered, meaning they can be used only by subclasses. To allow unrelated code to use the window instances, they must be declared.

In Dylan, these sorts of visibility rules are not considered part of the code, but of the module/interface system. This adds considerable flexibility. For instance, one interface used during early development could declare everything public, whereas one used in testing and deployment could limit this. With C++ or Java these changes would require changes to the source code, so people won't do it, whereas in Dylan this is a fully unrelated concept.

Although this example does not use it, Dylan also supports multiple inheritance.

Methods and generic functions
In Dylan, methods are not intrinsically associated with any specific class; methods can be thought of as existing outside of classes. Like CLOS, Dylan is based on multiple dispatch (multimethods), where the specific method to be called is chosen based on the types of all its arguments. The method need not be known at compile time, the understanding being that the required function may be available, or not, based on a user's preferences.

Under Java the same methods would be isolated in a specific class. To use that functionality the programmer is forced to import that class and refer to it explicitly to call the method. If that class is unavailable, or unknown at compile time, the application simply won't compile.

In Dylan, code is isolated from storage in functions. Many classes have methods that call their own functions, thereby looking and feeling like most other OO languages. However code may also be located in generic functions, meaning they are not attached to a specific class, and can be called natively by anyone. Linking a specific generic function to a method in a class is accomplished thusly:

This definition is similar to those in other languages, and would likely be encapsulated within the  class. Note the := setter call, which is syntactic sugar for.

The utility of generic methods comes into its own when you consider more "generic" examples. For instance, one common function in most languages is the, which returns some human-readable form for the object. For instance, a window might return its title and its position in parens, while a string would return itself. In Dylan these methods could all be collected into a single module called " ", thereby removing this code from the definition of the class itself. If a specific object did not support a, it could be easily added in the   module.

Extensibility
This whole concept might strike some readers as very odd. The code to handle  for a window isn't defined in  ? This might not make any sense until you consider how Dylan handles the call of the. In most languages when the program is compiled the  for   is looked up and replaced with a pointer (more or less) to the method. In Dylan this occurs when the program is first run; the runtime builds a table of method-name/parameters details and looks up methods dynamically via this table. That means that a function for a specific method can be located anywhere, not just in the compile-time unit. In the end the programmer is given considerable flexibility in terms of where to place their code, collecting it along class lines where appropriate, and functional lines where it's not.

The implication here is that a programmer can add functionality to existing classes by defining functions in a separate file. For instance, you might wish to add spell checking to all s, which in C++ or Java would require access to the source code of the string class—and such basic classes are rarely given out in source form. In Dylan (and other "extensible languages") the spell checking method could be added in the  module, defining all of the classes on which it can be applied via the   construct. In this case the actual functionality might be defined in a single generic function, which takes a string and returns the errors. When the  module is compiled into your program, all strings (and other objects) will get the added functionality.

Apple Dylan
Apple Dylan is the implementation of Dylan produced by Apple Computer. It was originally developed for the Apple Newton product.

title: Dylan (programming language)


text:
Dublin Core

The Dublin Core vocabulary, also known as the Dublin Core Metadata Terms (DCMT), is a general purpose metadata vocabulary for describing resources of any type. It was first developed for describing web content in the early days of the World Wide Web. The Dublin Core Metadata Initiative (DCMI) is responsible for maintaining the Dublin Core vocabulary.

Initially developed as fifteen terms in 1998 the set of elements has grown over time and in 2008 was redefined as an Resource Description Framework (RDF) vocabulary.

Designed with minimal constraints, each Dublin Core element is optional and may be repeated. There is no prescribed order in Dublin Core for presenting or using the elements.

Milestones

 * 1995 - In 1995 an invitational meeting hosted by the Ohio College Library Center (OCLC) and the National Center for Supercomputing Applications (NCSA) takes place at Dublin, Ohio, the headquarters of OCLC.
 * 1998, September - RFC 2413 "Dublin Core Metadata for Resource Discovery" details the original 15-element vocabulary.
 * 2000 - Issuance of Qualified Dublin Core.
 * 2001 - Publication of the Dublin Core Metadata Element Set as ANSI/NISO Z39.85.
 * 2008 - Publication of Dublin Core Metadata Initiative Terms in RDF.

Evolution of the Dublin Core vocabulary
The Dublin Core Element Set was a response to concern about accurate finding of resources on the Web, with some early assumptions that this would be a library function. In particular it anticipated a future in which scholarly materials would be searchable on the World Wide Web. Whereas HTML was being used to mark-up the structure of documents, metadata was needed to mark-up the contents of documents. Given the great number of documents on, and soon to be on, the World Wide Web, it was proposed that "self-identifying" documents would be necessary.

To this end, the Dublin Core Metadata Workshop met beginning in 1995 to develop a vocabulary that could be used to insert consistent metadata into Web documents. Originally defined as 15 metadata elements, the Dublin Core Element Set allowed authors of web pages a vocabulary and method for creating simple metadata for their works. It provided a simple, flat element set that could be used

Qualified Dublin Core was developed in the late 1990's to provide an extension mechanism to the vocabulary of 15 elements. This was a response to communities whose metadata needs required additional detail.

In 2012, the DCMI Metadata Terms was created using a RDF data model. This expanded element set incorporates the original 15 elements and many of the qualifiers of the qualified Dublin Core as RDF properties. The full set of elements is found under the namespace http://purl.org/dc/terms/. There is a separate namespace for the original 15 elements as previously defined: http://purl.org/dc/elements/1.1/.

Dublin Core Metadata Element Set, 1995
The Dublin Core vocabulary published in 1999 consisted of 15 terms:

• contributor

• coverage

• creator

• date

• description

• format

• identifier

• language

• publisher

• relation

• rights

• source

• subject

• title

• type

The vocabulary was commonly expressed in HTML 'meta' tagging in the " " section of an HTML-encoded page.   The vocabulary could be used in any metadata serialization including key/value pairs and XML.

Qualified Dublin Core, 2000
Subsequent to the specification of the original 15 elements, Qualified Dublin Core was developed to provide an extension mechanism to be used when the primary 15 terms were not sufficient. A set of common refinements was provided in the documentation. These schemes include controlled vocabularies and formal notations or parsing rules. Qualified Dublin Core was not limited to these specific refinements, allowing communities to create extended metadata terms to meet their needs.

The guiding principle for the qualification of Dublin Core elements, colloquially known as the Dumb-Down Principle, states that an application that does not understand a specific element refinement term should be able to ignore the qualifier and treat the metadata value as if it were an unqualified (broader) element. While this may result in some loss of specificity, the remaining element value (without the qualifier) should continue to be generally correct and useful for discovery.

Qualified Dublin Core added qualifiers to these elements:

And added three elements not in the base 15:
 * Audience
 * Provenance
 * RightsHolder

Qualified Dublin Core is often used with a "dot syntax", with a period separating the element and the qualifier(s). This is shown in this excerpted example provided by Chan and Hodges:

Title: D-Lib Magazine

Title.alternative: Digital Library Magazine

Identifier.ISSN: 1082-9873

Publisher: Corporation for National Research Initiatives

Publisher.place: Reston, VA.

Subject.topical.LCSH: Digital libraries - Periodicals

DCMI Metadata Terms, 2008
The DCMI Metadata Terms lists the current set of the Dublin Core vocabulary. This set includes the fifteen terms of the DCMES (in italic), as well as many of the qualified terms. Each term has a unique URI in the namespace http://purl.org/dc/terms, and all are defined as RDF properties.

• abstract

• accessRights

• accrualMethod

• accrualPeriodicity

• accrualPolicy

• alternative

• audience

• available

• bibliographicCitation

• conformsTo

• contributor

• coverage

• created

• creator

• date

• dateAccepted

• dateCopyrighted

• dateSubmitted

• description

• educationLevel

• extent

• format

• hasFormat

• hasPart

• hasVersion

• identifier

• instructionalMethod

• isFormatOf

• isPartOf

• isReferencedBy

• isReplacedBy

• isRequiredBy

• issued

• isVersionOf

• language

• license

• mediator

• medium

• modified

• provenance

• publisher

• references

• relation

• replaces

• requires

• rights

• rightsHolder

• source

• spatial

• subject

• tableOfContents

• temporal

• title

• type

• valid

It also includes these RDF classes which are used as domains and ranges of some properties:

• Agent

• AgentClass

• BibliographicResource

• FileFormat

• Frequency

• Jurisdiction

• LicenseDocument

• LinguisticSystem

• Location

• LocationPeriod/OrJurisdiction

• MediaType

• MediaTypeOrExtent

• MethodOfAccrual

• MethodOfInstruction

• PeriodOfTime

• PhysicalMedium

• PhysicalResource

• Policy

• ProvenanceStatement

• RightsStatement

• SizeOrDuration

• Standard

Maintenance of the standard
Changes that are made to the Dublin Core standard are reviewed by a DCMI Usage Board within the context of a DCMI Namespace Policy. This policy describes how terms are assigned and also sets limits on the amount of editorial changes allowed to the labels, definitions, and usage comments.

Dublin Core as standards
The Dublin Core Metadata Terms vocabulary has been formally standardized internationally as ISO 15836 by the International Organization for Standardization (ISO) and as IETF RFC 5013 by the Internet Engineering Task Force (IETF), as well as in the U.S. as ANSI/NISO Z39.85 by the National Information Standards Organization (NISO).

Syntax
Syntax choices for metadata expressed with the Dublin Core elements depend on context. Dublin Core concepts and semantics are designed to be syntax independent and apply to a variety of contexts, as long as the metadata is in a form suitable for interpretation by both machines and people.

Notable applications
One Document Type Definition based on Dublin Core is the Open Source Metadata Framework (OMF) specification. OMF is in turn used by Rarian (superseding ScrollKeeper), which is used by the GNOME desktop and KDE help browsers and the ScrollServer documentation server.

PBCore is also based on Dublin Core. The Zope CMF's Metadata products, used by the Plone, ERP5, the Nuxeo CPS Content management systems, SimpleDL, and Fedora Commons also implement Dublin Core. The EPUB e-book format uses Dublin Core metadata in the OPF file. Qualified Dublin Core is used in the DSpace archival management software.

The Australian Government Locator Service (AGLS) metadata standard is an application profile of Dublin Core.

title: Dublin Core


text:
Document Object Model

The Document Object Model (DOM) is a cross-platform and language-independent interface that treats an HTML or XML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree. Each branch of the tree ends in a node, and each node contains objects. DOM methods allow programmatic access to the tree; with them one can change the structure, style or content of a document. Nodes can have event handlers (also known as event listeners) attached to them. Once an event is triggered, the event handlers get executed.

The principal standardization of the DOM was handled by the World Wide Web Consortium (W3C), which last developed a recommendation in 2004. WHATWG took over the development of the standard, publishing it as a living document. The W3C now publishes stable snapshots of the WHATWG standard.

In HTML DOM (Document Object Model), every element is a node:

 * A document is a document node.
 * All HTML elements are element nodes.
 * All HTML attributes are attribute nodes.
 * Text inserted into HTML elements are text nodes.
 * Comments are comment nodes.

History
The history of the Document Object Model is intertwined with the history of the "browser wars" of the late 1990s between Netscape Navigator and Microsoft Internet Explorer, as well as with that of JavaScript and JScript, the first scripting languages to be widely implemented in the JavaScript engines of web browsers.

JavaScript was released by Netscape Communications in 1995 within Netscape Navigator 2.0. Netscape's competitor, Microsoft, released Internet Explorer 3.0 the following year with a reimplementation of JavaScript called JScript. JavaScript and JScript let web developers create web pages with client-side interactivity. The limited facilities for detecting user-generated events and modifying the HTML document in the first generation of these languages eventually became known as "DOM Level 0" or "Legacy DOM." No independent standard was developed for DOM Level 0, but it was partly described in the specifications for HTML 4.

Legacy DOM was limited in the kinds of elements that could be accessed. Form, link and image elements could be referenced with a hierarchical name that began with the root document object. A hierarchical name could make use of either the names or the sequential index of the traversed elements. For example, a form input element could be accessed as either  or.

The Legacy DOM enabled client-side form validation and simple interface interactivity like creating tooltips.

In 1997, Netscape and Microsoft released version 4.0 of Netscape Navigator and Internet Explorer respectively, adding support for Dynamic HTML (DHTML) functionality enabling changes to a loaded HTML document. DHTML required extensions to the rudimentary document object that was available in the Legacy DOM implementations. Although the Legacy DOM implementations were largely compatible since JScript was based on JavaScript, the DHTML DOM extensions were developed in parallel by each browser maker and remained incompatible. These versions of the DOM became known as the "Intermediate DOM".

After the standardization of ECMAScript, the W3C DOM Working Group began drafting a standard DOM specification. The completed specification, known as "DOM Level 1", became a W3C Recommendation in late 1998. By 2005, large parts of W3C DOM were well-supported by common ECMAScript-enabled browsers, including Internet Explorer 6 (from 2001), Opera, Safari and Gecko-based browsers (like Mozilla, Firefox, SeaMonkey and Camino).

Standards
The W3C DOM Working Group published its final recommendation and subsequently disbanded in 2004. Development efforts migrated to the WHATWG, which continues to maintain a living standard. In 2009, the Web Applications group reorganized DOM activities at the W3C. In 2013, due to a lack of progress and the impending release of HTML5, the DOM Level 4 specification was reassigned to the HTML Working Group to expedite its completion. Meanwhile, in 2015, the Web Applications group was disbanded and DOM stewardship passed to the Web Platform group. Beginning with the publication of DOM Level 4 in 2015, the W3C creates new recommendations based on snapshots of the WHATWG standard.

 * DOM Level 1 provided a complete model for an entire HTML or XML document, including the means to change any portion of the document.
 * DOM Level 2 was published in late 2000. It introduced the  function as well as an event model and support for XML namespaces and CSS.
 * DOM Level 3, published in April 2004, added support for XPath and keyboard event handling, as well as an interface for serializing documents as XML.
 * HTML5 was published in October 2014. Part of HTML5 had replaced DOM Level 2 HTML module.
 * DOM Level 4 was published in 2015. It is a snapshot of the WHATWG living standard.

Web browsers
To render a document such as a HTML page, most web browsers use an internal model similar to the DOM. The nodes of every document are organized in a tree structure, called the DOM tree, with the topmost node named as "Document object". When an HTML page is rendered in browsers, the browser downloads the HTML into local memory and automatically parses it to display the page on screen. However, the DOM does not necessarily need to be represented as a tree, and some browsers have used other internal models.

JavaScript
When a web page is loaded, the browser creates a Document Object Model of the page, which is an object oriented representation of an HTML document that acts as an interface between JavaScript and the document itself. This allows the creation of dynamic web pages, because within a page JavaScript can:

 * add, change, and remove any of the HTML elements and attributes
 * change any of the CSS styles
 * react to all the existing events
 * create new events

DOM tree structure
A Document Object Model (DOM) tree is a hierarchical representation of an HTML or XML document. It consists of a root node, which is the document itself, and a series of child nodes that represent the elements, attributes, and text content of the document. Each node in the tree has a parent node, except for the root node, and can have multiple child nodes.

Elements as nodes
Elements in an HTML or XML document are represented as nodes in the DOM tree. Each element node has a tag name, attributes, and can contain other element nodes or text nodes as children. For example, an HTML document with the following structure: will be represented in the DOM tree as:

Text nodes
Text content within an element is represented as a text node in the DOM tree. Text nodes do not have attributes or child nodes, and are always leaf nodes in the tree. For example, the text content "My Website" in the title element and "Welcome" in the h1 element in the above example are both represented as text nodes.

Attributes as properties
Attributes of an element are represented as properties of the element node in the DOM tree. For example, an element with the following HTML: will be represented in the DOM tree as:

Manipulating the DOM tree
The DOM tree can be manipulated using JavaScript or other programming languages. Common tasks include navigating the tree, adding, removing, and modifying nodes, and getting and setting the properties of nodes. The DOM API provides a set of methods and properties to perform these operations, such as,  ,  , and. Another way to create a DOM structure is using the innerHTML property to insert HTML code as a string, creating the elements and children in the process. For example: Another method is to use a JavaScript library or framework such as jQuery, AngularJS, React, Vue.js, etc. These libraries provide a more convenient and efficient way to create, manipulate and interact with the DOM.

It is also possible to create a DOM structure from an XML or JSON data, using JavaScript methods to parse the data and create the nodes accordingly.

Creating a DOM structure does not necessarily mean that it will be displayed in the web page, it only exists in memory and should be appended to the document body or a specific container to be rendered.

In summary, creating a DOM structure involves creating individual nodes and organizing them in a hierarchical structure using JavaScript or other programming languages, and it can be done using several methods depending on the use case and the developer's preference.

Implementations
Because the DOM supports navigation in any direction (e.g., parent and previous sibling) and allows for arbitrary modifications, an implementation must at least buffer the document that has been read so far (or some parsed form of it).

Layout engines
Web browsers rely on layout engines to parse HTML into a DOM. Some layout engines, such as Trident/MSHTML, are associated primarily or exclusively with a particular browser, such as Internet Explorer. Others, including Blink, WebKit, and Gecko, are shared by a number of browsers, such as Google Chrome, Opera, Safari, and Firefox. The different layout engines implement the DOM standards to varying degrees of compliance.

Libraries
DOM implementations:

 * libxml2
 * MSXML
 * Xerces is a collection of DOM implementations written in C++, Java and Perl
 * xml.dom for Python
 * XML for <SCRIPT> is a JavaScript-based DOM implementation
 * PHP.Gt DOM is a server-side DOM implementation based on libxml2 and brings DOM level 4 compatibility to the PHP programming language
 * Domino is a Server-side (Node.js) DOM implementation based on Mozilla's dom.js. Domino is used in the MediaWiki stack with Visual Editor.
 * SimpleHtmlDom is a simple HTML document object model in C#, which can generate HTML string programmatically.

APIs that expose DOM implementations:

 * JAXP (Java API for XML Processing) is an API for accessing DOM providers
 * Lazarus (Free Pascal IDE) contains two variants of the DOM - with UTF-8 and ANSI format

Inspection tools:

 * DOM Inspector is a web developer tool

title: Document Object Model


text:
Talk:Document Object Model

VTD-XML is not spam
VTD-XML is an emerging XML processing model that combines the best of both DOM and SAX. Putting it in the description gives people more choices to meet their development needs. —Preceding unsigned comment added by Jzhang2007 (talk • contribs) 07:52, 31 October 2006 (UTC)

Information Not Current
It would be helpful if this page would discuss current implementation of DOM2/3 in the latest round of Web Browsers. Presently the article is two versions behind for IE, making it seriously outdated.

It would also be helpful if the article would update the progress of the DOM WG since the 2004 release of DOM3. Has the DOM working group continued its work, or is the standard essentially finished and stable? Cadwallader 13:40, 18 July 2007 (UTC)

Article Quality
I think the quality of this article is seriously lacking. There is very little information actually regarding the concept of the DOM, and not some tangent.

Also the firt subsection, "Levels", is completely without context: There is no explanation of what a DOM level even is.

I am going to put the cleanup boilerplate on the top of the page. Andy 17:53, 16 November 2005 (UTC)

 * I think I have copyedited the article enough to justify the removal of the cleanup message. Anyone disagreeing should feel free to add the cleanup message back. Aapo Laitinen 18:10, 19 December 2005 (UTC)

I’d have to agree with Andy that this article has some problems. I made some minor fixes but I think that it needs a significant re‐write as it seems like not much consideration has been put into the flow of the article. Unfortunately, I don’t know enough about the DOM and its history to do that. JustSomeGuy 01:35, 21 November 2006 (UTC)

The implementations section suggests that Konqueror, Opera, and Safari are Gecko based like Mozilla and Camino; when in fact Konqueror / Safari are based on WebKit/KHTML and Opera on it's own Presto layout engine. 65.13.19.19 (talk) 17:50, 5 January 2008 (UTC)

Title Letter Case
Should this article's title be lowercased to Document object model? Yes, I know it's a moot point once Wikipedia implements case-insensitivity, but until then... --Damian Yerrick

I don't think so, the W3.org on DOM page has Document Object Model. -- HJH

Some more things concerning the DOM can probably be mentioned in the article, for instance the fact that it is not only used in web-browsers but also for xml processing in other applications. A summary about the different levels of the DOM and what purpose they serve could also be helpful in my opinion. Also some links to implementations and libraries that are based on the DOM could be a good entry point for people reading this and being more interested in practical DOM. I never contributed to Wiki projects due to general lack of time, maybe I'll eventually get it going here. -- _tc

W3C Recommendations
Could anybody explain what is "W3C Recommendation"? Is there any difference between some Level 3 specification which is included in W3C Recommendation and which is not?

Answer
The entire W3C Process is described on the W3 site. Basically, working groups are created to make up working drafts, which pass through a series of revisions until they are finally released as recommendations. The recommendations are the 'standards'.

The various levels show major revisions - DOM 0 is essentially everything before W3C, DOM 1 was the first W3 standard, etc. DOM 2 is pretty well supported by nearly all browsers, DOM 3 is quite extensive and as yet its extensions to DOM 2 are not fully or widely supported (but it's getting there).

OzFred 07:19, 25 October 2005 (UTC)

W3C DOM
The article so far discouraged the use of the DOM giving the reason that browser support is not sufficient (including some Microsoft bashing). However nowadays the situation is fairly stable and many methods of the W3CDOM may be used without problems in a cross-browser way. I have added thow that it is a good practice to test first for the availabilty certain DOM-API functions. Hirzel 09:31, 20 August 2005 (UTC)

More W3C DOM
The discussion on feature detection is somewhat misleading and seems to suggest something only marginally better than good 'ol browser sniffing. The idea of feature detection is to test every feature that either may not be supported or may be supported differently on various browsers. The classic are of course  and , but there are many, many others such as   and   etc.

The outcome of feature detection is that either the appropriate code is offered for the environment, or nothing at all. There should be no errors shown to the user - the user should not even be aware that something has not happened.

Feature detection becomes even more important as use of XHLHttpRequest and parsing of XML becomes more prevelant - there are many differences even between versions of the same browser.

comp.lang.javascript FAQ #4.26 OzFred 07:09, 25 October 2005 (UTC)

Using the DOM
From my perspective as a University Javascript tutor, there is little information on this page that is practically relevant for doing DOM scripting. Only the graphic helps somewhat (but could be improved). This page could really use some examples and explanations for how the DOM is accessed from a coder's point of view. I would add some myself if I had more time. — SimonEast 23:13, 13 September 2007 (UTC)

Examples needed
This article could use a textual example of how a sample document (such as the one shown in graphical form) would be represented by the model. Some code or pseudocode showing how the model might be accessed would also be helpful to give a flavor of what the DOM actually is for someone who knows nothing about it. These examples would help improve accessibility of this article to a wider audience. -- Beland (talk) 20:20, 2 January 2008 (UTC)

Need some simple examples, like "here is a nutcracker, see how it cracks a nut", etc. Jidanni (talk) 20:43, 20 January 2009 (UTC)

♥...tEiNkZ..xAh uuLyTiN pOh...♥ —Preceding unsigned comment added by Yamdahc (talk • contribs) 05:42, 8 October 2009 (UTC)
 * that would define original interpretation of what u searching and would help users to d copies. you cand do that in foirums but i order to read it u must do screen captures.

can someone guide next an wp editor proceed & upload printscreens?paul80

Google Patent: Enhanced document browsing with automatically generated links to relevant information
Hi all, this is miles outside of my own subject knowledge area, but apparantly google have filed a patent to automatically place links on a webpage specific to each user, using the DOM.... thought it might be relevant (but may not be).
 * Patent: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20100153422.PGNR.&OS=DN/20100153422RS=DN/20100153422
 * Article: http://www.free-seo-news.com/newsletter432.htm#facts (I know, the link looks a bit sale-sy, but I think their content is normally pretty good

EMCAScript Confusion
I may be wrong, but ECMA International created ECMAScript; W3C simply described an API for interacting with the DOM via ECMAScript along with ECMAScript "types" associated with the DOM. 108.28.51.60 (talk) 06:15, 12 November 2010 (UTC)
 * I agree, and the article begins, "The Document Object Model (DOM) is a cross-platform and language-independent convention ...". Where in the article are you seeing this confusion? --Nigelj (talk) 17:50, 12 November 2010 (UTC)
 * Here: "The World Wide Web Consortium (W3C), founded in 1994 to promote open standards for the World Wide Web, brought Netscape Communications and Microsoft together with other companies to develop a standard for browser scripting languages, called "ECMAScript"." The way it's worded it sounds to me like the article is suggesting that W3C created ECMAScript the language. 108.28.51.60 (talk) 02:35, 18 November 2010 (UTC)
 * Ah, I see. Are you saying that that sentence should end, "...a standard for browser scripting languages, which is now called "ECMAScript""? Or should the surgery go deeper, to completely separate the development of the DOM from that of the language? What do others think? --Nigelj (talk) 08:58, 18 November 2010 (UTC)
 * I think it's even worse than that. This section implies the W3C was invested in the ECMAScript standard, which (according to Doug Crockford - yuiblog.com/crockford/ - Lecture 1), is entirely untrue. In fact, Crockford claims that the W3C did not standardization of JavaScript by Netscape at all, which led to Netscape's odd choice of ECMA for the JavaScript standardization body. The idea the the W3C (a standards body itself) would coordinate with other entities to have a third party standardize a web technology is absurd on its face. It would be like Toyota bringing together a group of companies to design a car for Honda. -plamoni (talk) 21:14, 21 August 2012 (UTC) — Preceding unsigned comment added by 167.80.246.204 (talk)

Layout Engines
"Web browsers rely on layout engines to parse HTML into a DOM" - this sounds incorrect (or possibly incorrect, depending on browser). Most modern browsers rely on a specific HTML parser to parse HTML into a DOM; the "layout engine" then creates the render tree from the DOM (to style/position elements for on-screen painting), but it doesn't parse the HTML into the DOM (or may not, depending on the browser). — Preceding unsigned comment added by Spxdcz (talk • contribs) 03:28, 24 February 2011 (UTC)

Dom means Stupid in norwegian.
funfact: dom literally means stupid in norwegian. — Preceding unsigned comment added by Divinity76 (talk • contribs) 20:15, 6 November 2011 (UTC)

Explaining what the DOM is without being vague
Hello, I thought I'd come here to ask permission to add a clarifying section before "History" explaining what "the DOM" usually refers to. I literally spent years not knowing what people were talking about when they kept referring to "the DOM," mainly because every time I came here I found plenty more talk about this "DOM" but no explanation of what it is.

So I'd like to add a straightforward explanation, but I'd also like feedback about what it should say. I now have a good conception of what the DOM is, but I'd rather be corrected here, now, than on the actual article, later. Please let me know if you think it needs to be more accurate or precise, but hopefully we can keep it simple and straightforward: "The DOM is a representation of the tree of elements in a page. These elements are what HTML tags are marking in an HTML document. When a web browser reads the markup (HTML, XHTML, etc) in a webpage, it builds a DOM for the page, usually in memory, from its tag structure. As an example of how the DOM is distinct from the HTML it is based on, the elements of a DOM may not correspond one-to-one to the tags in a page. This is due to irregularities such as invalid HTML and omitted optional tags. In the former case, web browsers attempt to build a DOM out of ambiguous markup. In the latter case, a browser will still add elements to the DOM which were not represented by tags. The DOM that the browser constructs is what it then uses to render the page for display to the user." "Another factor distinguishing the DOM of a webpage from its markup is the effect of client-side scripting (usually JavaScript). The initial DOM constructed from the markup can serve as the target of scripts. The elements of the DOM are what JavaScript manipulates. After each manipulation, the DOM has been further altered from its initial representation of the markup. At each step, the page is re-rendered to the user." "Another language that targets the DOM is Cascading Style Sheets or CSS. CSS can change the display of a webpage by naming elements in its DOM and specifying how they are rendered." --Qwerty0 (talk) 09:31, 8 December 2011 (UTC)

Oh, forgot to mention: There's a good explanation of the intricacies of HTML, browser parsing, DOM's, tags, and elements in this video (the real DOM talk starts at 8:39). It includes great things like this explanation of the difference between HTML tags and DOM elements. I'm aiming to have something in this article equally clarifying.

--Qwerty0 (talk) 09:54, 8 December 2011 (UTC)
 * That looks like a very good idea to me. Your explanation is good, but I thought of a few things that I would change as I read it. rather than mess with your original, I'll copy it below and mark my suggested changes in bold. Lastly, of course, references would make this much better. are there any books or authoritative webpages that give this level of explanation that you know of? WP:V says that "any material challenged or likely to be challenged must be attributed to a reliable, published source using an inline citation". I don't have any challenge, and I doubt that anyone else would, but good references are much better than none. Also, I find that comparing article text with a good reference often improves it by suggesting better words or phrases in crucial places.

"The DOM is a representation of the tree of elements in a page. These elements are what the HTML tags represent in an HTML document. When a web browser reads the markup (HTML, XHTML, etc) in a webpage it builds an object model of the document, a DOM for the page, usually in memory from its tag structure. As an example of how the DOM is distinct from the HTML it is based on, the elements of a DOM may not correspond one-to-one to the tags in a page. This may be due to irregularities such as invalid HTML and omitted optional tags. In the former case, web browsers attempt to build a DOM out of ambiguous markup. In the latter case, a browser may add elements to the DOM which were not represented by tags. The DOM that the browser constructs is what it then uses to render the page for display to the user." "The DOM of a webpage needs to be distinguished from its markup because of client-side scripting (usually JavaScript). The initial DOM constructed from the markup can serve as the target of scripts. The elements of the DOM can be manipulated by JavaScript. After each manipulation, the DOM has been further altered from its initial representation of the markup. At each step, the page is re-rendered to the user." "The DOM is also accessed by Cascading Style Sheets or CSS. CSS can change the display of a webpage by addressing elements in its DOM and altering how they are rendered." --Nigelj (talk) 12:39, 8 December 2011 (UTC)
 * Awesome, thanks for the feedback! Yeah, sorry, I should've mentioned that I was intentionally leaving out the citations; just trying to get the wording right. I'm still working on that part. I don't have extremely official sources yet, but most of what I said is contained in the talk I mentioned above (by a member of Google Developer Relations), and this article (on a Google-produced site about HTML5).
 * As for the edits, they mostly sound good, though there are a few places where I'd ask for rewording:
 * "..elements are what the HTML tags represent.." I'd actually prefer the original phrasing of "..elements are what HTML tags are marking..". To me, at least, it's a little more straightforward. Plus, I think the former is a bit less accurate. I know you didn't mean this, but I think your version is too easy to mistake for "the tags are the elements" rather than "the tags mark where to make a DOM element and what information to add to it." Of course, according to the very explanation I'm taking this from, I should get punched in the face for correcting someone on this minutiae.
 * "..in a webpage it builds an object model of the document, a DOM for the page, usually in memory from its tag structure." Could I rearrange this to keep it less unwieldy? Perhaps "..in a webpage it builds a DOM for the page in memory from its tag structure: an object model of the document." in fact, I didn't know about the idea of generic object models. I think this could be worth expanding in a later section.
 * "The DOM of a webpage needs to be distinguished from its markup because of client-side scripting.." What I was trying to get at was that the effect of Javascript altering the DOM is another reason the DOM ends up usually being different from the plain HTML. But I don't think I phrased it well. How about "The DOM of a webpage is often distanced further from its markup by the effect of client-side scripting.."?
 * --Qwerty0 (talk) 08:06, 11 December 2011 (UTC)
 * Woh. This is going to be hard. Especially if there's just the two of us. I've just had a read through the talk sections above, and a look at the article. There's a lot to be done here, and I can't find any decent references for the level of detail that's needed. I found this, http://www.w3.org/TR/DOM-Level-2-Core/introduction.html, and some other less useful stuff.
 * I think there are many levels to get in order.
 * The DOM defines an Interface (computing), through which Client-side scripting can access and manipulate HTML and XML documents
 * In an HTML DOM, the document is represented as a Tree (data structure) comprising the HTML elements, HTML attributes, text and other aspects of the HTML text document
 * Although the DOM defines an object model of the document, there is no requirement that the DOM implementation (in the web browser or wherever) uses this object model to represent the document, just that it fulfils the interface as if it did.
 * If scripts alter or manipulate the DOM 'objects' via the provided interface, then a web browser should alter the displayed representation appropriately.
 * DOM Level 3 provides for XML DOM structures to be serialised back into markup text. There are many reasons and ways that the output document may differ from original markup:
 * The DOM may have been manipulated by scripting since it was loaded
 * The serialisation mode may have been set to alter XML entitys
 * the serialisation mode may alter whitespace, namespaces, etc
 * I had some of that wrong in my version above, but I think it's better here. I left most of the links un-piped for now. Once we (and whoever else may show up to help) agree what the points are, we can re-write the prose, I hope. --Nigelj (talk) 17:47, 30 December 2011 (UTC)
 * Yeah, it seems like a somewhat neglected article. But I do agree, it's a quite important and often-referenced concept. Which is what got me interested in at least an introductory explanation. Unfortunately I don't have time to devote to a full fix-up. I think the details you outlined are very good to note lower down in the article. At the moment it doesn't even have a section on those topics.
 * But if you're alright with my latest revision of the introductory section, I'll go ahead and add it once I've found some references? The w3c document you linked might be useful for some of it, but unfortunately until HTML5 the specification didn't even address the inner workings I refer to.
 * --Qwerty0 (talk) 06:01, 31 December 2011 (UTC)

I've just found this again, having forgotten it for a few months. I see neither of us actually did much in the end at the time. I've just reverted an edit by. I'll explain why in steps as it's all pretty relevant to what we were saying above. I hope this will be clearer when somebody has a good go at writing a proper clear explanation. --Nigelj (talk) 00:15, 18 March 2012 (UTC)
 * 'Web browsers usually use an internal model similar to the DOM' - there is no reason why they have to, internally, as long as they fulfil the DOM's interface when scripts make calls on it.
 * '...and to inspect or modify a Web page using JavaScript code' Browsers don't 'inspect or modify' a Web page using JavaScript. The JavaScript is external to the browser, written by a web developer as part of some webpage, and it may (depending on the developer's intentions) inspect (or query, or read, or search) or modify (or alter, or add to, or delete part of) the page's DOM.
 * When we say 'JavaScript sees...', that isn't sloppy English for 'JavaScript inspects...'. The script 'sees' the page via its interface (computing); that is good technical grammar, whether it is querying the page structure, or altering it. It is not, per se an inspector of things.

I just watched this video, linked by above. In that the speaker is pretty definite that the DOM is the data structure produced by the browser's parser. He's talking about HTML5, and there are now reference implementations of the perfect parser getting released, open source. These are written in Python, Java etc and are pretty certainly object oriented in their implementations. So what is the point in me trying to maintain some subtle distinction in my first bullet point just above, and the third bullet in my list above that one. So, I re-read this DOM Level 2 spec. In that the authors are pretty clear that the parser may not even be written in an OO language (guess, e.g. C), and so there is no way it can create the objects specified by the DOM spec: "The structure of SGML documents has traditionally been represented by an abstract data model, not by an object model." Therefore there is no necessary link between the internal data structure and the DOM, only a requirement to behave properly to incoming, valid, DOM-based, OO, script code: "The Document Object Model is not a set of data structures; it is an object model that specifies interfaces." Now, this article is about DOMs in general, not just the HTML5 DOM, so we need to maintain the distinctions required by other DOM specs, I think, at least until they are deprecated, or have really fallen out of use just about everywhere. That said, with free open-source, perfect, HTML5 parsers available, no one but an idiot would write their own - especially in a non-OO language - these days (and have to simulate all that OO DOM stuff from some other data structure). So, maybe there is no need to harp on about the older distinctions. Comments welcome. --Nigelj (talk) 01:28, 18 March 2012 (UTC)

Right now, the opening paragraph of the article is pretty much junk. One should never, ever load up an introduction with technical jiberish and word after word of linked explanations. That just turns off the reader. Please put something like Qwerty0's simple explanation in place of it. It just makes more sense. - KitchM (talk) 18:51, 15 April 2014 (UTC)

Shadow DOM?
Should there be a section of the article on the Shadow DOM (and related topics such as the "twilight DOM")? See http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ Strugee (talk) 01:50, 22 April 2012 (UTC)

DOM is API itself according to W3C specification
So the sentence "The public interface of a DOM is specified in its application programming interface (API)" assumes that there is also a non-public one. Since DOM is an API and and any API is a "public interface" by definition the wording "public interface of a DOM" is misleading. --Smbat.petrosyan (talk) 03:45, 26 June 2012 (UTC)

you could say DOM Level 0 coprises part of html4 that way users would use _full html_ in version4, and even more programmers would migrate tro hyml4 and html5 — Preceding unsigned comment added by 188.25.110.232 (talk) 02:42, 30 October 2012 (UTC)

this article can use LEVEL-1, LEVEL-2, LEVEL-3 as sections
why not?

DOM for SGML?
The article mentions that the Document Object Model (DOM) "treats an HTML, XHTML, or XML document as a tree structure." What about SGML? Doesn't the DOM treats SGML documents? Since both HTML and XML are extended from SGML, and XHTML is extended from XML and HTML, perhaps we should mention SGML in the article and – if it isn't treated by the DOM – explain why it isn't. —Kri (talk) 07:18, 2 July 2018 (UTC)

title: Talk:Document Object Model


text:
Design pattern

A design pattern is the re-usable form of a solution to a design problem. The idea was introduced by the architect Christopher Alexander and has been adapted for various other disciplines, particularly software engineering.

Details
An organized collection of design patterns that relate to a particular field is called a pattern language. This language gives a common terminology for discussing the situations designers are faced with.

"The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Documenting a pattern requires explaining why a particular situation causes problems, and how the components of the pattern relate to each other to give the solution. Christopher Alexander describes common design problems as arising from "conflicting forces"—such as the conflict between wanting a room to be sunny and wanting it not to overheat on summer afternoons. A pattern would not tell the designer how many windows to put in the room; instead, it would propose a set of values to guide the designer toward a decision that is best for their particular application. Alexander, for example, suggests that enough windows should be included to direct light all around the room. He considers this a good solution because he believes it increases the enjoyment of the room by its occupants. Other authors might come to different conclusions, if they place higher value on heating costs, or material costs. These values, used by the pattern's author to determine which solution is "best", must also be documented within the pattern.

Pattern documentation should also explain when it is applicable. Since two houses may be very different from one another, a design pattern for houses must be broad enough to apply to both of them, but not so vague that it doesn't help the designer make decisions. The range of situations in which a pattern can be used is called its context. Some examples might be "all houses", "all two-story houses", or "all places where people spend time".

For instance, in Christopher Alexander's work, bus stops and waiting rooms in a surgery center are both within the context for the pattern "A PLACE TO WAIT".

Examples

 * Software design pattern, in software design
 * Architectural pattern, for software architecture
 * Interaction design pattern, used in interaction design / human–computer interaction
 * Pedagogical patterns, in teaching
 * Pattern gardening, in gardening

Business models also have design patterns. See.

title: Design pattern