@joefromct there is a guide in https://github.com/metosin/muuntaja/blob/master/doc/Creating-new-formats.md for adding new formats.

thanks for that, i think i have something working. Here’s what i have so far for adding xml as a new format to a muuntaja instance:

i basically stole most of that from [here](https://github.com/metosin/muuntaja/blob/d69dfbb38f9fd6ab956d5638596433fd727f2f81/modules/muuntaja-yaml/src/muuntaja/format/yaml.clj#L1)

nice. what kind of data does the format return for the handler?

is it a json-like map?

just a string at the moment, but i’ll have specs to make sure it’s well-formed xml, i don’t have a schema at the moment so maybe i can plug that in later too

i was unsure on line 10 for the (slurp data) bit but i don’t know if there is a better way to do it… surprised everyone else is lucky enough to not be using xml 😉

<xml><kikka>1</kikka></xml> => {:xml {:kikka 1}}?

yeah i was tinkering with that too, as per here https://github.com/joefromct/clj-xmltojson

haha. using that in some legacy, but using a custom endpoint to read that. not as a first class format

^ it’s a bit more json looking than what you get from clojure.xml iirc

nice! I think we wrote similar small too when last needed that.

~lossless transformation there and back.

🙂 sounds good, thanks for your help

oh, it’s on internet 😮

https://github.com/metosin/noxml

must be private, i get a 404 ?

oh, it’s private. last modified 4years ago. kinda horrible, that clj-xmltojson must be better.

(declare xml->clj)

(defn- attr-name [k] (keyword (str "#" (name k))))
(defn- decorate-attrs [m] (zipmap (map attr-name (keys m)) (vals m)))
(defn- merge-to-vector [m1 m2] (merge-with #(flatten [%1 %2]) m1 m2))
(defn- childs? [v] (map? (first v)))
(defn- lift-text-nodes [m] (if (= (keys m) [:##text]) (val (first m)) m))
(defn- parts [{:keys [attrs content]}]
  (merge {} (decorate-attrs attrs)
         (if (childs? content)
           (reduce merge-to-vector (map xml->clj content))
           (hash-map :##text (first content)))))

(defn xml->clj
  ([xml] (hash-map (:tag xml) (-> xml parts lift-text-nodes)))
  ([xml schema]
   (xmls/->clj (xml->clj xml) schema)))

but that’s about the source.

well… no promises there. I think the idea is sound, but i have a nasty postwalk i’ve been thinking about trying to remove somehow for performance reasons. There is this clever bit of the python equivelent library that has a concept of “force list” for single-entry xml elements…. to force to a vector. The only way i could add the “force list” functionality was with a postwalk

that i could think of

so far

force list, doall?

basically, xml like this: <xml> <planes> <plane>jumbo</plane> </planes> </xml> you could pass a set into clj-xmltojson that would yield a vector of length one for the “jumbo plane”

thus, forcing it to a list … when you don’t have an xsd and you need to make sure planes is always a list. This would be “inferred” to be a list: <xml> <planes> <plane>jumbo</plane> <plane>f35</plane> </planes> </xml>

you would like them all to be lists?

Yes, when they are deliberately passed in via the force-list parameter (set) it’s pretty nasty code, i should find time to rewrite it and update the readme. embarrassed that somebody is actually looking at atm.

here’s a specific example from my repl

you can see the second call to xml->json with the force-list set ensures that “:plane” is always a list/vector in the output

so anyway, i’ll rewrite it one of these days and try to make the readme decent.