- From: Curt Arnold <carnold@houston.rr.com>
- Date: Tue, 03 Jun 2003 23:48:37 -0500
- 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 UTC