XML to JSON Converter

XML has two ways to attach a value to an element - as an attribute or as a child element - and JSON has only one. So `<user id="42"><name>Ada</name></user>` presents an immediate problem: `id` and `name` are structurally different in XML but must both become object members in JSON.

The common resolution is to prefix attribute names, usually with `@`, giving `{"user":{"@id":"42","name":"Ada"}}`. This is lossless and lets a converter reconstruct the original XML, at the cost of keys that are awkward to work with in code. The alternative is to merge attributes in as ordinary members, which reads much better but loses the distinction and can collide when an attribute and a child element share a name.

Which you want depends on whether you need to convert back. For one-way consumption, merged attributes are more pleasant. For a round trip, prefixing is necessary.

This is the defect that causes real production incidents, so it is worth stating plainly. XML has no array type. A list of items is expressed as repeated sibling elements, which means `<items><item>a</item><item>b</item></items>` and `<items><item>a</item></items>` are structurally the same pattern with different counts.

A converter looking at the second one cannot tell whether `item` is a collection that happens to hold one element, or a single value. So it guesses - and the usual guess is that one element means a scalar. Your code then works perfectly against test data with two items and fails with a type error the day a response contains exactly one.

There are only two real defences. Either configure the converter with a list of element names that must always be treated as arrays, which requires knowing the schema, or normalise defensively in your own code: wrap anything you expect to be a collection in an array if it is not one already. The second is uglier and works without a schema, which is why it is what most production code ends up doing.

XML allows text and elements to be siblings, which is natural for documents - `<p>Hello <b>world</b>!</p>` has text, an element, and more text as children of one node. JSON objects have no concept of ordered mixed members, so this cannot be represented directly. Converters typically collect the text into a special key such as `#text`, which preserves the content but loses the interleaving order. For document-oriented XML, that loss can be significant.

Whitespace is the related nuisance. XML preserves whitespace between elements by default, so pretty-printed XML contains text nodes made entirely of newlines and indentation. A converter that treats those as content produces `#text` keys full of whitespace throughout the output. Most trim them, which is almost always what you want - but it is a decision, and `xml:space="preserve"` exists precisely because sometimes the whitespace is data.