- From: <keshlam@us.ibm.com>
- Date: Tue, 6 Nov 2007 11:45:55 -0500
- To: Thomas Conway <conway@csse.unimelb.edu.au>
- Cc: www-dom@w3.org
- Message-ID: <OF81EF00E8.F36AEE41-ON8525738B.005B5EAA-8525738B.005C1889@lotus.com>
Back when the DOM was being designed, we debated how much content checking was appropriate. More robustness generally means worse performance, and in many cases the DOM content is being generated programmatically in a way that prevents the errors from arising in the first place so rechecking would be pure wasted cycles. I believe this particular example falls in the class of errors that we decided to leave as quality-of-implementation issues. That is, it's up to each implementation to decide whether to guard the DOM application from making this mistake at the time it is done, or to detect it at serialization time, or to make it entirely the user's responsibility... and it's the app author's responsiblity to select an implementation which picks the trade-off which suits their needs, and/or to code appropriately to prevent the problem from arising. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Received on Tuesday, 6 November 2007 16:47:17 UTC