Re: Design of a validating configuration server

[Elena Litani <el...@ca.ibm.com>]

Hi Petr,

My understanding is that you don't want to modify the original document if
the modification to the configuration is incorrect.
If this is the case, I am not sure that Validation spec would help you
either. Here is an example: assume schema allows the "root" element to have
element "foo" with two children "a" and "b".  If user creates "foo" element
and attempts insert it in the tree, you can using canAppendChild("foo") [1]
check if the document remain valid after this insertion. But if you use
strict validation (VAL_SCHEMA), this check will fail since "foo" does not
have children. If you choose "VAL_INCOMPLETE" then canAppendChild(foo) will
succeed but you can't guarantee that user will go on and insert the right
children for this element, so in the end you document may still be invalid.
Probably, the best approach is to keep track of all modification to the
tree (you can use mutational events [2]), and if the modification were not
correct undo all modifications done by the user.
What is the general trend - do users do lots of modifications to the same
configuration file? how often would you expect users to make mistakes? If
you don't expect users to make many mistakes, maybe you should choose to go
fast for people who don't do any mistakes, and slow in the case a mistake
was made. For example,  before the request to modification serialize the
DOM tree and if modification does not succeeds de-serialize back the
original the DOM tree (I am talking about Java
serialization/de-serialization).

Anybody else has any suggestions?

[1]
http://www.w3.org/TR/2003/CR-DOM-Level-3-Val-20030730/validation.html#VAL-Interfaces-NodeEditVAL
[2] http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/

Thank you,
--
Elena Litani/ IBM Toronto


-----Original Message-----
From: Petr Lindovsky [mailto:lindovsky@cncz.cz]
Sent: Friday, November 14, 2003 9:43 AM
To: 'xerces-j-user@xml.apache.org'
Subject: Design of a validating configuration server

Hello,

I've been assigned the task of maintaining a CORBA server application
(written in Java) responsible for managing the configuration of a
telecom traffic measurement system. This Config server uses the Xerces's
experimental DOM Level 3 implementation (version 2.5.0) and maintains
the configuration data in a DOM document. The structure of the document
is defined with an XML schema (containing e.g. identity constraints and
default attribute values).

When a client requests a modification of the document, the Config server
in the current design proceeds the following way:
- it creates a copy of the document using Document.cloneNode()
- it modifies the copy according to the client's request
- it invokes Document.normalizeDocument() and if successful, it replaces
the old document with the copy

This design worked OK at the beginning of the project but now, as the
configuration document gets bigger, modifications are unacceptably slow.
We were looking for a way to improve this and we considered the
following possibilities of normalizing "selectively":

- To extract "relevant parts" from the document copy into an empty
document (using Document.adoptNode()) and normalize it against a
"partial schema". This has the problem that you must parse the full
schema to create the partial one and that it's not easy to figure out
what the "relevant parts" are (especially in presence of identity
constraints).
- To normalize using a modification of
org.apache.xerces.dom.DOMNormalizer that would lead the schema validator
through "relevant branches" only (as suggested by Elena Litani in
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xerces-j-user@xml.ap
ache.org&msgNo=3073). This has the disadvantage that we start to depend
on Xerces's internals and again, it's not easy to find the "relevant"
branches.

(BTW, I know that the behavior of Document.cloneNode() is
implementation-defined according to the DOM specification but in Xerces,
it doesn't discard the default attributes and that's what is needed if
we validate partially.)

But maybe the best solution of the problem would be to use a completely
different design. (There exists a DOM Level 3 Validation specification,
but I don't know if there is an implementation available today.) I will
be grateful for your suggestions.

Regards,
Petr Lindovsky / CN Resources International, Prague, Czech Republic




---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org