- From: Jill Beppu <jbeppu@jps.net>
- Date: Sun, 19 Nov 2000 17:13:48 GMT
- To: "K. Ari Krupnikov" <ari@iln.net>, Ben.Chang@oracle.com, www-dom@w3.org
remove from list >"Benjamin C. Chang" wrote: >> >> "K. Ari Krupnikov" wrote: >> > >> > It seems to me that it could be advantageous to have an option for >> > continuos validation of the document, something like >> > >> > boolean Document.continuosValidation >> > or >> > boolean DOMImplementation.continuosValidation >> > >> > In the optional validating mode I'm talking about, insertBefore() could >> > throw something like a CM_HIERARCHY_REQUEST_ERR if the operation would >> > violate the CM. >> >> You're talking about changing the signature/behavior of insertBefore(), to >> take care of validation, thus breaking compatibility for a DOM CORE >> function. > >G-d forbid! >Neither signature nor behavior of insertBefore() or similar functions >need change. >Signature: insertBefore() already throws DOMException. What I'm >suggesting is a new code (16?) for DOMException. >Behavior: I'm suggesting a switch: if continuosValidation is set, this >new type of DOMException may be thrown. If it is unset, no validation >occurs. Implementations would be free to set the default value for >continuosValidation to false and thus be completely l2 compatible. > >> > Note that this does not create any additional strain on teams developing >> > traditional DOM implementations: the difference between normal and >> > continuos validation mode would be that insertBefore()'s first statement >> > will be canInsertBefore() > >-- >K. Ari Krupnikov > >DBDOM - bridging XML and relational databases >http://www.iter.co.il > > >
Received on Sunday, 19 November 2000 12:14:23 UTC