I would rather say that XML is untyped (an XML document only contains text of various flavours), and that is why the only concrete example given works in XML but would fail in YAML or JSON:
“test this against Go 1.20”
> It interprets that as Go 1.2.
Well, understand your data format before complaining. YAML, like JSON, understands data types. If you were to write { value: 1.20 } in JSON, it would similarly be interpreted as the numeric value 6/5. The only reason this works "magically" in XML is because XML itself doesn't have data types, it only has text, and the interpretation is left to the user rather than done by the parser.
I don't understand why you are being downvoted. You're absolutely right, though I'd nitpick and say not say "untyped" but that the only types that XML gives you are dom nodes and strings.
Contrast that with JSON, which provides booleans, numbers, and the list and object composite types. (side rant: as a standard JSON does not define whether it's numbers are integers, floats, or decimals! a conforming implementation can use whatever type it wants).
Yes, XML has (multiple) schema definition languages that can be used to enforce that the strings can be coerced into specific types, but XML itself conveys no type information in-band about the values. I think this is one of the reasons it is difficult read and write by hand.
Nice, I wasn't aware of that. But it doesn't change the argument much: the XML document still only contains text data, and it's the schema validation phase that's responsible for converting the data into the correct format. Validating an XML document is an optional step, and I'm not aware of many tools that use XML as their config that perform full schema validation.
To add, the XML specification on decimal data types [0] explicitly says: Precision is not reflected in this value space; the number 2.0 is not distinct from the number 2.00 -- so a decimal data type in an XML document would have the exact same problem as the YAML example in TFA; the only difference is that with XML, the authors of the tool would have to actively shoot themselves in the foot by annotating that element as a decimal type rather than text.
The problem isn't that XML's decimal type doesn't distinguish between 1.2 and 1.20 - it's that versions aren't decimals in the first place.
The fact that versions often contain numbers separated by decimal points or that often times, versions only have two components or that minor versions may rarely exceed 9 for a particular product are merely coincidences.
My full sentence is more like saying Java is untyped if it were possible to run Java source files from the AST while skipping the type validation step, which seems pretty much a truism to me.
