Although the answer provided by Zentrope was correct for the question as stated, it turns out I didn’t understand what was actually going on, and so it didn’t work in production. Now that I have a better answer, here’s me trying to explain it:
I’m using zip and zip-filter to work with an Amazon ECS library. This is how Amazon presents author names:
<authors>
<author>Author One</author>
<author>Author Two</author>
</authors>
That can be arbitrarily long; textbooks, for example, have a half-dozen authors sometimes. The Harry Potter books list both Rowling and Mary GrandPre as the authors, sometimes even listing GrandPre first in the XML.
The way that I was handing this in the interpretation stage resulted in this
(zf/xml-> Item :ItemAttributes :Author zf/text)
which appeared to return a string, but actually, whenever I tried to work with it, behaved like a lazy sequence. Passing it forward into my JSON wrapper resulted in a string that wrapped author names in brackets and double-quotes.
So when I asked about dealing with a string with those attributes, I thought I was dealing with the problem. It turns out that the code provided
(apply hash-map (read-string “["these are" "author names"]”))
works on a string, but throws errors, for good reason, when handed my lazy sequence.
All is not lost, though; this pointed me in the right direction. This works:
(apply vector (zf/xml-> Item :ItemAttributes :Author zf/text))
That resolves down to a vector with an arbitrary number of author names in it, which I can then safely JSONize and deal with forward and backward.
