On 2015-02-28, Harald Brabenetz wrote: > I made the changes: > https://github.com/brabenetz/xmlunit/commit/3f824ef2b7cb348efea76b85d3d5a35da7fe8550
> If the DOMDifferenceEngine is the one and only implementation, then I > think embrace DOM as part of XMLUnit's diff API is fine, > But if there is another implementation then DOMDifferenceEngine > planned, then it's maybe (depends on the other implementations) better > to reject the changes. Somewhere in the back of my head is the idea of a pull model based DifferencEngine that would need to sacrifice certain features (most importantly it could only match nodes in order so we'd lose the whole ElementSelector business) but would be way more memory efficient for big documents. DOM really is a memory hog on both platforms we support. For .NET constructing XmlNodes for the state of an XmlReader would be easy, for Java we'd be burdened by providing our own implementations of the DOM interfaces on top of StAX. Not a big deal, but still something that had to be done. OTOH I'm not convinced said "stream" DifferenceEngine would be used much. After all most people - at least those who report problems with XMLUnit - seem to be using ElementQualifiers (now ElementSelectors) of some sort in order to deal with permutations of elements. Stefan ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Xmlunit-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xmlunit-general
