Hi Dick, The only thing I can think of that might be removed are namespace declaration attributes. Will be removed if you've set the "namespace-declarations" parameter to false. Of course if you want the namespace declarations to stay in the DOM (which I'm assuming you do for xsi:type and other QName values) you shouldn't set it to false.
Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] Dick Deneer <[EMAIL PROTECTED]> wrote on 10/04/2007 03:52:09 AM: > Michael, > > One more question about this. > Do I also have to take in account that an attribute can be removed by > the normalizer, or will that never happen? > > Regards > Dick Deneer > > Op 4-okt-2007, om 5:01 heeft Michael Glavassevich het volgende > geschreven: > > > Hi Dick, > > > > I wouldn't expect the normalizer to have predictable behaviour if some > > other code is modifying the DOM in arbitrary ways while its doing > > its job. > > It has quite a bit of state which it assumes will be consistent > > throughout > > the normalize cycle. > > > > Have you tried queueing the defaulted attributes for removal after > > normalizeDocument() completes? > > > > Thanks. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [EMAIL PROTECTED] > > E-mail: [EMAIL PROTECTED] > > > > Dick Deneer <[EMAIL PROTECTED]> wrote on 10/03/2007 > > 02:00:32 PM: > > > >> My xml editor totally depends on the functionality of the > >> DOMNormalizer > >> In a try to suppress the addition of attributes (see discussion in > >> http://www.nabble.com/Some-consideration-about-the-xerces-DOM- > >> implementation-tf3602407.html) I wrote a DocumentListener that > >> immediately removes the attributes that were added by the > >> normalizer. This way I am getting the exact behavior I want: Error > >> messages for missing required attributes are still reported, but > >> the attributes are not already inserted in the document. > >> But now a very strange behavior was reported. In the editor I am > >> retrieving the typedefinition by casting the attribute to an > >> AttrPSVI. This way I can support the user by displaying combo boxes > >> for enumeration. > >> If I have deleted attributes that were inserted, It looks like I am > >> getting the wrong typeinfo for the remaining attributes. Is it > >> possible the typeInfo is retrieved by a number and that the removal > >> of the attribute causes a mismatch? Also the getValidity gives the > >> wrong value. > >> > >> You can see the behavior in my editor (http:// > >> www.donkeydevelopment.com > >> ). Put the attached xml and xsd in the same directory. Open the xml > >> document and press the validate button. You will see that the error > >> is reported on the wrong place and that the typeinfo in the > >> comboboxis > > wrong. > >> If you adjust the parameter "insert_default_attributes=false" to > >> "insert_default_attributes=true" in the XMLSpear.properties file, > >> restart the editor and try again you will see the expected > >> behaviour. But this time I do not suppres the insert of the default > > attribute. > >> > >> Of course I am not absoluty sure but I think it is a bug in xerces. > >> > >> Using Xerces 2.9.0 > >> [attachment "test.xml" deleted by Michael Glavassevich/Toronto/IBM] > >> [attachment "test.xsd" deleted by Michael Glavassevich/Toronto/IBM] > >> Dick Deneer > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
