The other commenter is right, but I'll break it down a bit further. There are actually two related ways of using the word DOM.
Usage 1: the set of rules (API) for manipulating a document
HTML is a way of writing down a webpage so you can send it over the internet to the browser. The browser then reads in the HTML and uses it to build the "actual" webpage in memory. Different browsers may represent the webpage in different ways internally, but they try to provide a common set of rules and methods for interacting with and manipulating it. That common set of rules and methods is the Document Object Model. These rules include things like the way forms work or the kinds of properties input boxes are allowed to have (such as placeholder text, a current state, etc.).
Well, a "common set of rules and methods for interacting with something" is exactly what an API is. This is why the other commenter can correctly say that the DOM is "an API ... that allows you to read and modify a markup document."
Usage 2: the document itself
HOWEVER, while "DOM" technically refers to the API for manipulating a thing (the markup document), people most often use the word to refer to the document itself. This makes sense, since you never interact with the browser's internal representation of the document, you only interact with its public interface, and so gradually you come to think of the interface as the thing itself.
This double usage is why it's confusing to put the DOM on the same level as HTML, CSS, and JS. Technically it may be true that it's a separate and parallel technology, but since the document itself is built by reading in HTML and CSS, and then can be modified through JS, it's probably easier to think of it as one level above them (or below or whatever).
Edit: to reply to your questions more specifically:
- SAX/DOM: ignore this, it's arcane and not relevant
- schema for data exchange: no, that's exactly what HTML is — a format for sending data between computers. the DOM has more to do with how they represent that data to themselves after they receive it
- web tech vs. native UI: if you're trying to understand the DOM, don't worry about the UI of the browser, just worry about the web page itself
Usage 1: the set of rules (API) for manipulating a document
HTML is a way of writing down a webpage so you can send it over the internet to the browser. The browser then reads in the HTML and uses it to build the "actual" webpage in memory. Different browsers may represent the webpage in different ways internally, but they try to provide a common set of rules and methods for interacting with and manipulating it. That common set of rules and methods is the Document Object Model. These rules include things like the way forms work or the kinds of properties input boxes are allowed to have (such as placeholder text, a current state, etc.).
Well, a "common set of rules and methods for interacting with something" is exactly what an API is. This is why the other commenter can correctly say that the DOM is "an API ... that allows you to read and modify a markup document."
Usage 2: the document itself
HOWEVER, while "DOM" technically refers to the API for manipulating a thing (the markup document), people most often use the word to refer to the document itself. This makes sense, since you never interact with the browser's internal representation of the document, you only interact with its public interface, and so gradually you come to think of the interface as the thing itself.
This double usage is why it's confusing to put the DOM on the same level as HTML, CSS, and JS. Technically it may be true that it's a separate and parallel technology, but since the document itself is built by reading in HTML and CSS, and then can be modified through JS, it's probably easier to think of it as one level above them (or below or whatever).
Edit: to reply to your questions more specifically:
- SAX/DOM: ignore this, it's arcane and not relevant
- schema for data exchange: no, that's exactly what HTML is — a format for sending data between computers. the DOM has more to do with how they represent that data to themselves after they receive it
- web tech vs. native UI: if you're trying to understand the DOM, don't worry about the UI of the browser, just worry about the web page itself