- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 6 Jun 2008 13:50:31 -0700
- To: Matt Womer <mdw@w3.org>
- Cc: public-geolocation@w3.org
On Jun 6, 2008, at 12:49 PM, Matt Womer wrote: > Before digging into item 2, I want to mention that on the Web there > seems to be a slang-like usage of the term "DOM interface". As near > as I can tell it is mistakenly used to mean an interface that's > available via a global Object, but isn't necessarily related to the > DOM and it's interfaces. I'd like to suggest that we be careful in > our use of terms like "DOM interface", and restrict it to mean those > interfaces that are related in some way to the DOM. (I realize > that's not a very strict definition, but I think it solves the > issue). Otherwise confusion abounds. In the Web client context, the term DOM is used in many ways. In order of decreasing generality: 1) All APIs offered by the browser hosting environment (thus for example the term "DOM Level 0"). 2) Only the APIs offered by the browser hosting environment defined by W3C standards (so for example DOM2 Core, DOM2 Range and Traversal, the SVG DOM as defined in SVG 1.1, the HTML DOM as defined in HTML5, and Selectors API would all be DOM APIs, but any non-standard browser extensions are not, and things like Window were not DOM APIs until HTML5 defined them). 3) Only the APIs offered by the browser hosting environment that are defined by W3C standards which have DOM in the title or otherwise refer to the interface as a DOM (that would exclude Selectors API from the above list). 4) Only the W3C Standard APIs that have interfaces which inherit from DOM Core interfaces (but that would exclude DOM2 Range & Traversal and DOM2 Style!) 5) Only the W3C Standard APIs that were created by the former DOM Working Group and have DOM in the title (which would confusingly mean that DOM 2 HTML is part of the DOM, but the SVG 1.1 interfaces are not, nor is the HTML DOM as specified by HTML5). 6) Only DOM Core itself. I suggest we stay away from arguing what "DOM" means and use terms that are less ambiguous. For instance, we could say "Web API" for #1, "Standard Web API" for #2, and "DOM tree-based" for #4. So I think your item #2 is about exploring a DOM tree-based interface for geolocation information, while I think most of us would just like to create a Standard Web API for geolocation information and not specifically one that is DOM tree-based. Regards, Maciej
Received on Friday, 6 June 2008 20:51:15 UTC