Nadia Kowalczyk

Conversion between these formats is a choice of data model rather than a syntax exercise, and the syntax is the easy half. Nested objects do not: a table has columns and rows, so a list of records inside one field has to become rows, columns, or a string. Each of those is a different decision with different consequences when converting back. Spreadsheets are the constraint that surprises people. A cell holds one value, so a list becomes a joined string and a nested object becomes a stringified structure, and both come back as text that needs parsing. Excel also has a row limit and a column limit, and it reformats values it recognises as dates, numbers or currency on the way in, which changes data you did not touch. CSV has no types at all, so every value crosses as text and the receiving side guesses. Dates are the usual casualty, since a date in one locale parses as nonsense in another. XML can represent nesting natively and handles mixed content better than the others, which is why it survives in feeds nobody wants to maintain. Its cost is the namespace and entity rules. My rule is to convert through a neutral structure rather than between two formats directly, so the mapping is visible and testable. Converting through a neutral structure means the mapping is written down once, which is what makes a conversion repeatable and what makes it reviewable. The round trip is the test: convert to the new format and back, then compare, and anything that differs was lost rather than transformed.