Hi Elena, Thank you for your reply.
I didn't mention one thing in my previous message: In a modification operation, the bottleneck is the Document.normalizeDocument() call, not Document.cloneNode(). We have measured this in a realistic situation and the results were: - about 400 ms when Document.normalizeDocument() was skipped - about 7800 ms with the normalization Yes, it is a good idea to replace copying the document with the 'undoing' approach using events you are mentioning. I was thinking about this approach before but for now, I stayed with the original copying design as it isn't the bottleneck here. (The Java serialization would probably be slower than cloning.) I think that in our case, we have to do the validation for all users; we cannot assume that some of them don't do any mistakes. I have looked at the canAppendChild() method from the Validation API and it seems that it only checks whether "the Node.appendChild operation would make this document not compliant with the VAL_INCOMPLETE validity type", probably even if the strict validation (VAL_SCHEMA) is used. (In our application, it WOULD make sense to require that the user insert a "foo" element with the "a" and "b" already appended.) So maybe a better solution would be to set the DocumentEditVAL.continuousValidityChecking flag which somehow enforces the validity during an editing process, even though I'm not sure how (will the Node.appendChild() method throw an exception if "foo" doesn't have "a" and "b" children yet?). But again, are there any Validation API implementations available today? Regards, Petr -----Original Message----- From: Elena Litani [mailto:[EMAIL PROTECTED] Sent: Thursday, November 27, 2003 10:30 PM To: [EMAIL PROTECTED] Subject: FWD: Re: Design of a validating configuration server 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#VA L-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:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 9:43 AM To: '[EMAIL PROTECTED]' 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/[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
