W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2003

validateDocument, DOMErrorHandler and continuousValidityChecking

From: Curt Arnold <carnold@houston.rr.com>
Date: Tue, 03 Jun 2003 23:48:37 -0500
Message-ID: <3EDD7A25.8050605@houston.rr.com>
To: www-dom@w3.org

In the discussion of continuousValidityChecking, the "if (sic) free" 
phrase is extremely permissive.  It would be trivially easy to implement 
a comforming implementation by never raising a validation exception.  
The only way to fail would be to raise an exception when the document is 
actually valid.

There needs to be a distinction in the response to an attribute to set 
continuousValidityChecking to true for a invalid document and for an 
implementation that does not support continuous validity checking.

The discussion does not specify the interaction with the return value 
from the handleError method of a registered DOMErrorHandler.  The 
description in Core would suggest that returning true from handleError 
could suppress the throwing an exception on a documentation mutation 
that invalidated the document.

Using setParameter to register one (and unregister any previously) 
DOMErrorHandler seems very primitive compared to the Event model.  Since 
the validation spec only deals with constructed DOM trees, it would seem 
that defining a ValidationEvent and using the event model would be a 
familar and powerful model.  Multiple listeners could co-exist.  
preventDefault on a dispatched event when continuousValidityChecking is 
true could be used to suppress throwing exception when the listener only 
wanted to monitor and not prevent transitions to an invalidate state.  
Calling validateDocument would dispatch the same events but the default 
behavior would not cause an exception to be thrown.  I know it is late, 
but it seems to make a lot of sense.
Received on Wednesday, 4 June 2003 00:48:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT