Understand Type Inference from XML Text Values

Type Inference: Beyond Simple Strings

The converter does not treat every XML text value as a string. It analyzes each value to determine the most specific JSON Schema type. This produces more useful schemas that can validate the actual shape of converted XML data.

Inference Rules

XML Value	Detected Type	Reasoning
hello	string	Default for non-numeric, non-boolean text
42	integer	Whole number within safe integer range
3.14	number	Decimal number
1.5e10	number	Scientific notation
true	boolean	Exact match to boolean literal
false	boolean	Exact match to boolean literal
`` (empty)	string	Empty string defaults to string
2024-01-15	string	Date strings remain strings (no date type in JSON Schema)
9999999999999999	string	Number exceeds safe integer range

Type Unions

When the same element contains different types across multiple occurrences, the schema uses a type union:

<items>
  <value>42</value>
  <value>hello</value>
  <value>true</value>
</items>

This produces an array item with type ["integer", "string", "boolean"] because the three <value> elements contain different types.

Why Not Always Use String?

While defaulting to string for everything would be simpler, it produces less useful schemas. A schema that knows a <price> element is a number can be used to validate that converted JSON data actually contains numeric values, not accidentally stringified ones. This is particularly important when the JSON Schema will be used to validate data in a pipeline where XML is converted to JSON.

Edge Cases

• Leading zeros: Values like 007 are treated as strings because they are not standard numbers
• Whitespace-only: Treated as empty string
• CDATA sections: Content inside CDATA is treated the same as regular text content
• Null: XML has no null concept — empty elements map to empty string type