I've never used zip.xml. What I usually do is use https://grishaev.me/en/zippo/ or something similar. Basically, I would use zippo/loc-find-all to locate all the items and then use zippo/loc-find on each item to find the type and value. I'm not sure how much you can assume about the xml you're consuming, but I've also had success mixing and matching zippers with meander.

The structure is fixed so I can assume everything. In this context, sounds like zippo won't actually bring anything new to the table. I briefly thought about using Specter for it, but decided against it as trying to remember and make sense of its grammar doesn't make me too enthusiastic.

It seems like you can just reduce over the children of the item element. Each child tag is just a key value pair that you can dump into a map.

Yea, zippo is more useful when you can't make as many assumptions about data. It's great for html parsing where you want to find the title and href for each container element somewhere inside the html.

(->> zitem
     (z/children)
     (into {}
           (map (fn [node]
                  [(:tag node) (-> node :content first)]))))

I should've added - the items have more nodes than I need. :) So I'll end up filtering as well, and it'll end up being more code than with a zipper->nodes->zippers->nodes chain.

The question is more about zippers themselves rather than about how to do it in general.

in that case, zippo/loc-find or zippo/loc-find-all should be helpful for finding the relevant children of each item element.

But that's what that :type already does in zip.xml/xml->. But I just discovered that I don't need to call zip/node to get an item because instead I should be iterating over already existing zippers, the ones that (zip.xml/xml-> ... :item) returns. So the chain becomes one link shorter.

I didn't really grok zippers until I read this article by my former team mate https://grishaev.me/en/clojure-zippers/ He makes the point in that article that zippers sweet spot is when you're trying to process docs where the structure is unknown ahead of time

However, zippers shine in the case where you must modify the tree. For the given goal, you could use xml-seq! Filter by #(= :item (:type %)). Then map to transform each <item> to a record, again using xml-seq unless some of them have child elements.

https://github.com/mudge/riveted I think Riveted might be your best bet rather than zippers for this problem. You can search for each of your <item> elements, and it returns a lazy sequence of navigator objects that can then be transformed into your desired format. I used it recently to solve a similar-ish problem and it was both extremely easy to use and highly performant - even my extremely unoptimized code was able to process a lot of complex XML very quickly

zippers are really good for some problems, but I personally have trouble keeping track of "where" I am in the tree when thinking about, writing and testing them, which is particularly burdensome if the XML you're working with has a complex internal structure. the XPath navigation in riveted makes the simple stuff simple while still enabling the more complex stuff.

Just to follow up on this, did you read https://blog.korny.info/2014/03/08/xml-for-fun-and-profit.html#zippers - particularly the way he navigates into the parsed XML and then uses zippers on a per node basis? I copied this and it didn’t feel like too much work once I understood.

@UFTRLDZEW Thanks for pointing me to Riveted! It's 10x faster than zippers in my use-cases (not even mentioning Xalan, which is atrociously slow, at least when it comes to XPaths).

It does seem to be in the Buddy's source code: https://github.com/funcool/buddy-sign/blob/c1c7ffcd4b49d3604916736d15f03893e15e5814/src/buddy/sign/jwe/cek.clj#L38

oh interesting… let me take a look

And some examples in the docs, but not sure how relevant they are to your usecase. https://github.com/funcool/buddy-auth/blob/88b3ac08e2b3984158a359908344f87109a6a2a7/doc/user-guide.md#encrypted-jwt

Ah, that’s in buddy-sign… I wouldn’t have thought to look there