Legacy XML responses as JSON: good for inspection, risky for code

It worked with one result and broke with two — the XML feed that looked like a tidy JSON object until a second element appeared

An XML sample with one result maps its child to an object or string; a second sibling turns the same property into an array. Code written against the first converted sample can therefore fail when cardinality changes. The JSON is a projection of observed occurrences, not a schema-aware contract.

ToolAcre makes the mapping predictable but cannot remove this one-versus-many ambiguity. For long-lived integration, normalize known collection paths from an XSD or documented contract and test both cardinalities against the XML reader actually used in production.

Why conversion is excellent for reading — nesting flattened into familiar braces, attributes surfaced as keys, and the whole response scannable at once

Conversion is excellent for reading because nested elements become familiar objects, repeated siblings become arrays and attributes appear as `@` keys. A large envelope can be scanned quickly without mentally matching closing tags. Type inference can remain off so text is not silently guessed into numbers or booleans.

The readable view is especially useful during incident triage, where locating an error code or payload matters more than preserving authorial markup. Keep the source beside the JSON because the projection may not retain every distinction needed by application code.

Why the converted shape is unstable — repeated elements becoming arrays only when repeated, attribute prefixes, and text nodes that appear or vanish

The converted shape depends on occurrence count, reserved prefixes and whether an element has attributes or children. Plain text can collapse to a string; the same text moves under `#text` when structure is added. CDATA appears under `#cdata`, and attributes use `@`.

These transitions are documented conventions, not unstable implementation accidents. They become risky only when code assumes one sample defines all future XML shapes. A schema-aware model can state repeatability and optionality; the generic parser cannot.

What gets lost that code may need — namespaces, element order, mixed content, CDATA boundaries and comments

Namespace prefixes stay in property names and declarations stay as `@xmlns:*`; they are not resolved to expanded names. CDATA remains marked under its special key. Comments, declaration and processing instructions are dropped. Mixed text around child elements is joined and loses relative position.

Element order among differently named properties is not a safe replacement for an XML node sequence after projection into an object. If document order, mixed prose or exact CDATA boundaries matter, use an XML tree or event parser rather than this JSON-shaped view.

Namespace prefixes and CDATA values remain visible, while ordering and node boundaries can be lost

Use an envelope-shaped document with a namespace prefix, one body child and two result elements. Conversion reveals the body path, keeps literal prefixes and produces a result array. The example demonstrates navigation without claiming WSDL, SOAP fault or namespace-resolution support.

Then repeat with one result and observe the array disappear. That pair is the regression fixture application code needs. ToolAcre can expose the difference; it cannot decide whether your domain should always wrap the value in an array.

Worked example: an envelope-shaped XML document without claiming SOAP schema support

Depending on conversion can be reasonable for data-centric XML when the mapping is documented, cardinalities are normalized and fixtures cover attributes, empty values, mixed content and namespaces. Treat the mapping itself as an interface owned by your application.

Keep type inference explicit. With it off, values are strings; with it on, parser heuristics choose numbers and booleans. A stable mapping should not toggle that option accidentally between environments.

What this does not cover — WSDL and XSD tooling for generating typed clients, which is the robust route for long-lived integrations

No WSDL or XSD tooling is included. The converter validates well-formed XML, refuses every DOCTYPE and projects nodes; it does not generate typed clients, validate sequences or enforce domain facets. Those tasks require schema-aware software.

DOCTYPE refusal also means some legacy documents will not parse even if their declarations are harmless. This is a security boundary preventing entity expansion, not evidence that the underlying service response is malformed.

Takeaway: convert to understand, parse to implement — and how the Syntax converters panel gives you the readable view in seconds

Convert to understand; parse against an owned contract to implement. The JSON view can reveal a payload in seconds, while the original XML remains the evidence for ordering, cardinality and namespaces.

Syntax converters is honest about its projection and warnings. Use that visibility to design edge-case tests rather than letting one tidy sample define an integration that breaks on the next repeated element.

A durable fixture set should include zero, one and several occurrences for repeatable elements; an attribute and child sharing a name; a self-closing element; mixed text; CDATA; and a literal namespace prefix. Run those fixtures through the mapping you actually deploy and assert the normalized domain object, not ToolAcre’s formatted JSON text. That approach uses the converter to explore shapes while keeping production behaviour tied to an explicit parser contract.