An order with several line items, or a customer with several addresses, has relationships that do not fit naturally into one flat row. JSON and XML can keep related values together in a hierarchy. When an application or partner requires one of these formats, the transformation needs to preserve those relationships as well as rename fields.

Files.com TransformScript reads both formats into structured data and writes the result in the format your receiving system requires. Use the receiving system's specification to choose field names, nesting, and required values.

JSON Values and Collections

JSON uses named values in objects and ordered values in arrays. Values can be strings, numbers, booleans, null, objects, or arrays. A purchase order might contain a textual identifier and an array of line items:

{
  "order_id": "00123",
  "lines": [
    { "sku": "A10", "quantity": 2 },
    { "sku": "B20", "quantity": 1 }
  ]
}

Here, "00123" is text and 2 is a number. An empty string, null, and an omitted property are distinct representations; the receiving contract determines what each means. Dates and timestamps are represented using agreed values, often strings, rather than a dedicated JSON date type. RFC 8259 defines the JSON format.

Converting this order to a flat table requires a choice. One row per line could repeat the order identifier, keeping the relationship available to the loader. One row per order would need another agreed representation for the lines. A conversion that simply drops the nested array loses information even if the resulting CSV is well formed.

Newline-delimited JSON (NDJSON) places one complete JSON value on each line instead of enclosing the records in one array. A receiver expecting a JSON array needs a different reader from one expecting NDJSON. TransformScript provides separate JSON and NDJSON formats.

XML Elements and Attributes

XML represents a document as nested elements. Elements can contain text and child elements, and attributes carry named values on an element:

<Order id="00123">
  <Line sku="A10"><Quantity>2</Quantity></Line>
  <Line sku="B20"><Quantity>1</Quantity></Line>
</Order>

The two Line elements belong to the same order. The specification determines whether an identifier belongs in an attribute, such as id, or a child element, and whether element order matters. Moving a value between those positions changes the document the receiver sees.

The text 2 might represent a quantity, code, or identifier. The agreement and any supplied schema define its type and allowed range, along with the meaning of empty and absent elements.

XML Namespaces

Two systems can use the element name Order for different kinds of information. An XML namespace distinguishes a vocabulary by a URI. The prefix in a document is a local abbreviation for that URI:

<sales:Order xmlns:sales="urn:example:orders" id="00123"/>

Another sender can write the same namespaced element with another prefix:

<o:Order xmlns:o="urn:example:orders" id="00123"/>

Both identify Order in urn:example:orders. The URI and local name establish the element's identity; the prefix spelling does not. A namespace URI is an identifier, and need not be a downloadable page or schema. XML can also declare a default namespace for elements without a visible prefix.

When mapping partner XML, compare the namespace declarations as well as the visible tag names. Matching a literal prefix can fail when a partner changes its abbreviation; ignoring the namespace can confuse two different vocabularies. The W3C namespace specification defines these relationships, and TransformScript's XML selectors explain how to address the resulting data.