Comment made by: nathan

Correction for Benjamin Peter's workaround:
The bottom part of his descent function got cut off:

I actually think this issue is concrete evidence supporting that we cannot have something that caters for DZIP-3 and at the same time. If we stick for `tag=` to mean

current tag or child

it's simply impossible to support out of the box nested nodes with the same tag as their parent.

It is my personal opinion that checking properties of the current node happens much less frequently than descending the tree, so that the syntax sugar for keyword predicates is best reserved for checking children.

Attached is a patch that follows the path Paul Dlug suggested and:

• rolls back the changes from DZIP-3

• pulls the functionality required by DZIP-3 in a dedicated self= predicate

On a side node: as much as I'd love to help maintaining the project, I'm afraid I cannot commit to any more than casual help.

Someone needs to dig in to see if there is a solution that lets people do what they want in DZIP-3 and here in DZIP-6. Does the patch here re-break the case in DZIP-3?

If so, then more work needs to be done to either find a solution that works for both or to decide whether one of these cases is not valid and shouldn't be supported, or to add something that lets you do both.

Bumping up a notch, I'd love to have someone signup to be an active maintainer for data.zip. I've helped out here on a drive-by approach, but I have no skin in this game. Given there are a bunch of (obviously) caring users here, it would be great to have help from one of you.

Comment made by: bwstearns

Ran into the same thing just today. Posted this (https://stackoverflow.com/questions/46535423/cant-access-deeply-nested-xml-with-clojure-data-zip-xml) a bit ago, but now that I've found this I know I'm not alone/crazy.

@bpeter thanks for the workaround. Does anyone know if fixing this is making it into 0.1.2/is there anything I can do to help make that happen?

Comment made by: pdlug

This worked for us with 0.2.0-alpha2 when copying the latest implementation of tag= without the or part as Benjamin Peter suggested. I'm not sure what the best fix is here seems tricky to accommodate the previous patch to allow it to match the root, clearly matching descendants it is more frequent case so perhaps a root= predicate is preferred over introducing something like descendant= through all the xml-> matchers. Of course if there's some fix to tag= which can support both that I'm not seeing that would be best but seems tricky.