- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 31 Aug 2011 17:25:09 +0200
- To: public-webapps <public-webapps@w3.org>, "Adrian Bateman" <adrianba@microsoft.com>, "Doug Schepers" <schepers@w3.org>, "Jacob Rossi" <jrossi@microsoft.com>, "Arthur Barstow" <art.barstow@nokia.com>
On Thu, 11 Aug 2011 12:28:56 +0200, Arthur Barstow <art.barstow@nokia.com> wrote: > Before we publish a new WD of Anne's DOM spec, I would like comments on > how the DOM specs should be organized. In particular: a) whether you > prefer the status quo (currently that is DOM Core plus D3E) or if you > want various additional features of DOM e.g. Traversal, Mutation Events, > etc. to be specified in separate specs; and b) why. Additionally, if you > prefer features be spec'ed separately, please indicate your willingness > and availability to contribute as an editor vis-à-vis the editor > requirements above. If you look at the DOM model I think what turns out to be most closely tied are nodes and ranges. On top of that you have the modification model which spans both. Events and nodes are cross-dependent too. Traversal could be done separately, but is so small (and has no other dependencies) that it is not worth it. Given this scope I think we should call it DOM4. I think defining all of these in one specification is fine. Currently the specification is only 37 pages when printed. That will certainly grow once we add ranges, examples, and more introductory text, but will also still be well below the larger specifications. (Jonas' concern is already addressed in the specification with notes that reference the other relevant places in case a feature (so far only some constructor methods on Document) is defined across sections.) I also think it is a good idea as these features have cross-dependencies that are easier spotted and worked out when developed as a single coherent document. Everything else that builds on top of this abstract model (such as parsing and serialization methods, UI events, etc.) can be developed separately. And probably should be as they have a lot of other dependencies that are not needed for the abstract model. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 31 August 2011 15:25:48 UTC