Using (the more generic) XmlNode in place of XmlTree

[m0davis]

Consider the situation of walking a NavXmlTree and filtering on nodes having certain properties (say, in their names). The current type signatures require sprinkling withoutNav throughout the code:

withNav $ returnA
    >>> someMovementArrows 
    >>> filterA (withoutNav $ hasName "somename") 
    >>> someMoreMovementArrows 

By changing the type signature of hasName from String -> a XmlTree XmlTree to XmlNode xn => String -> a xn xn, we avoid the need for the withoutNav call. This patch generalizes hasName as well as many others.

Most of the changes to Text.XML.HXT.Arrow.XmlArrow are pretty simple. The generalization of changeAttrValue was more complex. To get it to work on an arrow of XmlNodes, I needed to make xshow accept such an arrow, which in turn required generalizing Text.XML.HXT.DOM.ShowXml.xshow. I chose to go about this by creating a ToXmlTree class for use in place of XmlTree (when conversion from an XmlNavTree is desired).

This is admittedly a bit too specific: why not a ToNTree class instead? Simply because it would have required adding a ToXNode class and I was tired of adding classes. If this patch is well-received, I'll have a look at further generalizations.

[UweSchmidt]

At a first view it seems, this is a rather large change for getting rid of the withoutNav.
There is already a filter filterAxis, which take a simple arrow for filtering. If this isn't
the right filter, it is rather easy to defined an alias for filterA . withoutNav.
Wouldn't this solve your problem.

[m0davis]

Then what would you do about those convenient combinators?

 addNav 
 //> withoutNav (hasName "table")
 /> withoutNav (hasName "tr")
 >>> make-some-replacement-here
 >>> ...

[UweSchmidt]

you're right, if that withoutNav is spread all over the code, the generalization makes sence

[m0davis]

Yes, without the generalization, the withoutNav would indeed be spread all over the code.

What would you like to see before accepting the pull? As mentioned in the OP, I'll be happy to fill-out the generalization, starting with ToNTree and ToXNode.

[DanielG]

+1.

Having to use withoutNav everywhere is very ugly (and can lead to all sorts of problems when you use something that modifies the zipper context, like getChildren inside it). I might as well use an imperative language to do my XML processing then. But no sir! I choose Haskell to do it so I want to be able to do it in style ;)