NobbZ

Library to safely parse XML (by avoiding random atom creation)

I am writing an application where I need to parse XML, and intuitively I reached out for sweet_xml as its a wrapper around xmerl.

Though while I was inspecting the parsed result, I realized that attribute and element names appeared as atoms, and as the XML I receive will be beyond my control, I want to avoid “random” atom creation. Some HTML documents, that slip through could bring the system down…

So does anyone have a typ for an XML library I could use instead?

If it can directly transform the XML into a struct thats a plus, but not a strict requirement. Though if it can’t do structs directly, XPath is a requirement.

I explicitely do not want approaches that work like pythons xml2dict.

23 comments

#xml #package #sweet_xml

4 5445 23

2026-01-12 09:34:23 UTC

Most Liked

josevalim

Creator of Elixir

I have also used saxy successfully. Specially useful if you want to get only certain parts of the XML.

Post #3

voltone

There’s erlsom | Hex, which uses strings rather than atoms for element and attribute names…

Post #2

Adzz

Just to follow up with what we ended doing at work after a lot of research.

We now use the default Saxy handler to spit out simple form, then we use data_schema’s to query the simple form. We implemented our own querying for simple form - which was not to difficult to do in the end. (If you are interested I may be able to open source).

This means you can cast the strings in the XML into data values quickly, then traverse the results using Elixir functions rather than xpath.

Not using xmerl and SweetXML drastically reduced our memory impact (we are talking from 1gb to 80mb for large XMLs) and sped it all up by about 12 times.

On top of that I’ve also implemented a custom Saxy handler that will only create the intermediate simple_form representation for values that are required by a data schema. So you pass a schema to the saxy handler then Saxy only creates simple_form for the values that the schema wants.

This keeps the memory impact very low as it never spikes higher than what is required by the schema. It adds a little complexity though.

Post #20

Last Post!

SebAlbert

I should, at least for now, append a huge warning under my previous post. It seems Expath makes false promises (parsing only once) and has possibly-wrong examples in the README. With its current state, it’s not useful for my case. See the github issue I opened: Add an interface for Nodes/Nodesets for multi-step querying from an XPath context node other than the document root · Issue #1 · wearecococo/expath

In case you are interested, I went the route of compiling our xsd files with :erlsom (which generates atoms, but we are in control of those files) (at compile-time!), parsing the (untrusted) XML with the result (which feels extremely fast) - which never creates new atoms - and only then, knowing the XML ist good, feeding it into the (otherwise unsafe regarding atom creation) :xmerl for XPath evaluations (which support context nodes, other than Expath).

Of course, the idea of an upfront Schema validation before using an arbitrary library only works for predefined shapes of XML data.

P.S.: And you should make sure that your XML Schema Definitions don’t allow xs:any, or at least only strictly-checked; the same for attributes.

Post #24