Michael, Implementation of the validation api would be great. In fact it was one of my first questions when I joined this forum. See http://www.archivum.info/[EMAIL PROTECTED]/2005-10/msg00010.html The methods to know, if or what nodes can be inserted are of great value. I tried to implement it myself but I gave up, because of the great complexity. I understand that implementing this part of the API is not top priority within the developer's team because it can be considered as extra or nice-to-have, but I still hope that it will be implemented in the future. On the other hand you can say that this is still a chance where one tool can excel in comparison to others.
But I think that validating the dom without modifiying is much more basic functionality. And all functionality (in fact too much :)) is already there in the document.normalizeDocument() method. Maybe a reason too have this available more soon. Dick Deneer Michael Glavassevich wrote: > > Hi Dick, > > There is a DOM Level 3 Validation module [1] which provides an API for > guided editing of XML documents. Among other things, it has a > validateDocument() [2] method which explicitly prohibits mutation of the > DOM during validation. If there's ever an effort to make Xerces' DOM > implementation more friendly to schema guided editing, I'd rather see it > through an implementation of this API. > > Thanks. > > [1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/ > [2] > http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/validation.html#VAL-Interfaces-DocumentEditVAL-validateDocument > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [EMAIL PROTECTED] > E-mail: [EMAIL PROTECTED] > > Dick Deneer <[EMAIL PROTECTED]> wrote on 04/18/2007 12:20:12 PM: > >> I am using the xerces parser and Dom implementation as the base of a >> simple XML editor. >> The editor has a source and a tree (DOM) view. >> >> Using the DOM in an editor requires other functionalitiy then just >> using a DOM for showing or validating purposes. >> In fact there are two issues with the current >> implementation, making it very hard to use xerces for this purpose. >> 1. It may be clear that it is important that the user gets the same >> (or nearly the same) xml after switching from source to DOM and back. >> 2. The user don't want unexpected additions or mutations in the DOM >> while editing or validating. >> >> I will give some examples: >> · It is not possible store entity references in attribute >> values when building a DOM, making is impossible to get the original >> XML back after serializing. There is a jira issue for this problem, see >> https://issues.apache.org/jira/browse/XERCESJ-1225 >> · The DOMNormalizer adds default required attributes to the DOM >> tree. Altough perfectly right according to the official >> specifications, this is not desired for the use in an editor. >> · First it will produce a error message "cvc-complex-type.4: >> Attribute 'xxxxx' must appear on element 'yyyyyy', which is in fact >> not valid anymore, because the problem is already solved by the >> DOMNormalizer, and secondly the XML is not the same anymore. These >> two things are confusing for the user. At this moment it is not >> happening for elements , but It looks like the same behavior is >> going to be implemented. >> · Adding a textNode which is adjacent to another, will >> immediately be delete by the DOMNormalizer. Again, this may be >> perfectly right, but confusing for a user when editing in a DOM. >> And it is not possible to validate the DOM without this "side-effect". >> >> Feedback of what happend is given by all kind of document events, >> which is great to still give some explanation to the user and keep >> trees in sync. But I would prefer to let some things not happen >> and be in control in the front. >> I really hope that in the future xerces will bring more "features or >> properties" to control the behavior of the DOMParser and DOMNormalizer. >> >> D. Deneer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Some-consideration-about-the-xerces-DOM-implementation-tf3602407.html#a10147485 Sent from the Xerces - J - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
