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.
this is like saying Java is untyped because the source files are just text
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.
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.
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.