CM: Re: l3 content model

"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
disable.

>
>
> 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.

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
triggers
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
or
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
will
not mean inclusion since alternate mechanisms do exist.

Ben

>
>
> 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