Hi Ray, I am forwarding this message to the xerces-j-dev list.
The DOMNormalizer class should have been *protected* from the start, since its primary reason is to provide implementation to normalizeDocument() function defined in the DOM Level 3 [1]. Given that the DOM Level 3 is at the stage of Working Draft, which represents work in progress and thus may be updated, I am concerned that some implementation, like yours, may choose to use this code not realizing that the DOMNormalizer code may change to reflect changes that could be introduced to the normalizeDocument() description. To avoid later complains from users about changes in functionality, I prefer keeping this code protected and final. Ray Grimmond wrote: > Please can you explain the reasons for changing these methods to > FINAL ?? Performance (plus the above concerns). > Bottom Line - need to serialize DOM via XMLDocumentHandler. Do you need support to all the functionality offered by normalizeDocument, i.e. namespace fixup, support for different features (infoset, comments, entities, etc), attribute value normalization, or need to traverse the tree and serialize it via XMLDocumentHandler? If you only need the latest, I suggest you prototype a component that allows to serialize DOM via XMLDocumentHandler and contribute the code to Xerces. [1] http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020409/core.html#Document3-normalizeDocument Thank you, -- Elena Litani / IBM Toronto Ray Grimmond wrote: > > > I want to use the same XMLDocumentHandler implementation in a number > of places in both the parser pipeline as a filter , as a parser > subclass, and also being driven by a serialize of the DOM Tree. > > Using version 2.0.2 , I used the DOMNormalizer class to walk the dom > by extending an XMLDocumentHandler implementation and implementing > Revalidation Handler > and by subclassing DOMNormalizer as follows > > public class DNValidationHandler extends MyXMLDocumentHandler > implements org.apache.xerces.impl.RevalidationHandler > { > public void setCurrentNode(Node node){ > myCurrentNode = node; // myCurrentNode defined > in MyXMLDocumentHandler > } > } > > public class DOMNormalizerSubclass extends > org.apache.xerces.dom.DOMNormalizer { > > > protected org.w3c.dom.Node normalizeNode(org.w3c.dom.Node > node) { > validator.setCurrentNode(node); > } > > protected void > setValidationHandler(org.apache.xerces.impl.RevalidationHandler > validator) { > this.validator = (DNValidationHandler) validator; > super.setValidationHandler(validator); > } > > } > > I know this is a rather unorthodox way of using the DOMNormalizer code > but we do not want to use multiple DOM Serializers. > > I dont want to use the org.xml.serialize package to serialize as > there is no support for XMLDocumentHandler... > > We need a way to serialize the DOMTree through XMLDocumentHandler and > pass-through the current node in the tree, either as a variable or as > an augmentation. > > Although not intended for its original purpose, it works like a > charm, making all DOMNormalizer methods as protected FINAL as in the > latest CVS Version 1.7 will put a stop to this. > > Please can you explain the reasons for changing these methods to > FINAL ?? > Do you really need to do this ??? > Maybe an alternative is to factor out the Normalizer code (also non > DOM-L3) > so that it can be used for other general serialization purposes > (using XMLDocumentHandler) as well as for Re-validation. > > Bottom Line - need to serialize DOM via XMLDocumentHandler. > > Thanks > > > Ray Grimmond > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
