Some scenarios would benefit from an NodeMatcher that simply "does what I mean": Try all possible pairings of control/test nodes and pick the permutation that contains the least number of differences (and prefer "similar" over "different").
The ElementSelector interface is not suitable since it only sees pairs of nodes but in order to be useful the implementation needs to see all candidate nodes at once.
Probably such a NodeMatcher would require quite a bit of caching of decisions already made. It would also require knowledge of the DifferenceEngine it belongs, at least to the DifferenceEvaluator. On the other hand it should not use the specified ComparisonController and certainly not inform ComparisonListeners at all while searching for candidate matches.
Of course this option would be way more expensive than carefully chosen ElementSelectors, in particular for big documents with many siblings at more than one level of the tree. Therefore it shouldn't be the default choice.
Some scenarios would benefit from an
NodeMatcherthat simply "does what I mean": Try all possible pairings of control/test nodes and pick the permutation that contains the least number of differences (and prefer "similar" over "different").The
ElementSelectorinterface is not suitable since it only sees pairs of nodes but in order to be useful the implementation needs to see all candidate nodes at once.Probably such a
NodeMatcherwould require quite a bit of caching of decisions already made. It would also require knowledge of theDifferenceEngineit belongs, at least to theDifferenceEvaluator. On the other hand it should not use the specifiedComparisonControllerand certainly not informComparisonListeners at all while searching for candidate matches.Of course this option would be way more expensive than carefully chosen
ElementSelectors, in particular for big documents with many siblings at more than one level of the tree. Therefore it shouldn't be the default choice.