W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

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>
Message-ID: <op.v023r7s364w2qv@annevk-macbookpro.local>
On Thu, 11 Aug 2011 12:28:56 +0200, Arthur Barstow <art.barstow@nokia.com>  
> 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  

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
Received on Wednesday, 31 August 2011 15:25:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC