W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2000

CM: Re: l3 content model

From: Benjamin C. Chang <Ben.Chang@oracle.com>
Date: Thu, 16 Nov 2000 23:24:14 -0800
Message-ID: <3A14DD1E.E84D44A0@oracle.com>
To: "K. Ari Krupnikov" <ari@iln.net>
CC: www-dom@w3.org
"K. Ari Krupnikov" wrote:

> It is my understanding that L3 CM is not going to continuously monitor
> the validity of a DOM tree, but is instead going to perform checks when
> explicitly asked to.
> 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
> It is true that in some implementations such continuos monitoring will
> be expensive, and it is also true that those who need such continuos
> monitoring could use
> if ( canInsertBefore (newChild, refChild) ) then
>     insertBefore (newChild, refchild )

> However, in some implementations, continuos validation will be cheaper
> than incremental. I am building a DOM wrapper on top of a relational
> database. Every time a node is deleted, created, moved ot whatever, a
> trigger is fired by the database engine, which effectively performs the
> validation. If, before every insert, I were to ask if it can be
> completed, the same validation code would be executed twice!

You can disable your db triggers to prevent this from happening.

> Note that
> some database engines fire implicit triggers even if no triggers have
> been defined for a particular operation.

For the DML-type operations that you're talking about and actions you
want performed, these would be explicit triggers, which again you can

> 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
care of validation, thus breaking compatibility for a DOM CORE function.

However, if enough people in the developer community desire this type of
functionality (you're the first) -- and I can see the merits of validation
firing based on these events if you're mapping some of the DOM functions to

DML operations -- then this would be done by introducing a method to set
continuous validation mode for these DML-type DOM operations and then
changing their function signatures to account for validation type of errors
introducing a new return code for validation errors.    More users
requiring this type
of functionality need to speak up though, as a 1 person use case scenario
not mean inclusion since alternate mechanisms do exist.


> 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 Friday, 17 November 2000 02:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:07 UTC