The projection mapping

Every fpml-convert implementation follows the same rules. The mapping is reversible without the schema — that is the whole design goal.

Elements

• Element local name → object key. A tag repeated under one parent becomes an array, in document order.
• Namespaces are reduced to the local name. Both namespace prefixes and ElementTree Clark notation ({uri}local) collapse to the bare local name, so the mapping is identical whether the parser is a browser DOMParser or a server-side XML parser.

Attributes

• Attributes become @-prefixed keys, placed before any child keys, in the order @id, @xsi:type, @href, then any others.
• xsi:type is kept verbatim as @xsi:type — it selects the concrete schema type and is never dropped.

References

• A pure reference element (href, no children, no other content) becomes the scalar «id». One that also carries content stays an object but gains @href = «id».
• The «…» delimiters are what let Structile render the value as a clickable link to the element whose @id matches.

Values

• Typed lexical forms are preserved as strings, never coerced. 1000000.00 stays exactly 1000000.00.

Strictness

• Every element the projection descends into is checked against a supported-subset allowlist. An unknown element is a loud error, never a silent partial projection. This is what lets Structile tell this interpreter apart from other candidates.

Serialisation

• Writing a value back out re-emits children in schema (xs:sequence) order, so a value whose keys were reordered while editing still writes back as schema-ordered FpML.
• The confirmation default namespace and xsi: are re-declared on the root; xsi:schemaLocation is intentionally not reproduced.