The record node determines what one CSV row means
XML is a hierarchy; CSV is a table. Converting between them requires a semantic choice: which repeated element represents one record? A converter can detect repeated paths, but frequency alone does not prove business meaning.
If you select an order node, one row can represent one order. If you select a line-item node, the same document may produce several rows per order. Both outputs can be structurally valid and still answer different questions.
Read the hierarchy before flattening it
<orders>
<order id="A-100">
<customer>North Shop</customer>
<items>
<item sku="P-1" quantity="2" />
<item sku="P-2" quantity="1" />
</items>
</order>
</orders>Selecting /orders/order produces one order record. The id attribute and customer element can become columns, while the two item children still need a representation choice.
Selecting /orders/order/items/item produces two line-item records. That is appropriate for an item-level table, but the parent order ID and customer may need to be carried into each row. A tool that does not show the selected record path makes this change hard to audit.
DataFormatKit's XML to CSV converter lists candidate repeated nodes, shows the chosen path, and records it in result metadata.
Repeated children need an explicit representation
A single XML record can contain repeated tags such as phone numbers, categories, or items. Flattening them into columns, joining them, retaining JSON text, or expanding rows all change how the result can be used.
- Join scalar values when order is known and the destination accepts one delimited cell.
- Keep JSON text when preserving the collection matters more than immediate spreadsheet filtering.
- Expand into rows only when the child entity should become the table's record unit.
- Avoid automatic cross products when two repeated child collections exist. Multiplying them can invent relationships that are absent from the XML.
Attributes and namespaces are part of the structure
Attributes should receive stable column names that cannot collide with child elements. Namespace prefixes may distinguish fields that share a local name. Removing them without checking the schema can merge different concepts.
Review meaning, safety, and completeness separately
- Confirm the record path against a real downstream task.
- Compare the number of selected XML nodes with the CSV row count.
- Inspect how attributes, namespaces, empty elements, and mixed text are named.
- Review every repeated-child transformation.
- Reject DTD and custom entity declarations unless a dedicated, hardened XML workflow is required.
- Keep representative source paths in the conversion report.
A correct XML-to-CSV result is not simply the flattest table. It is a table whose row meaning and transformations can be explained.