XML is well structured, typed and general purpose, but it's a pain for humans to edit. I think the editing pain is one of the main reasons people look for XML alternatives. Personally I wish XML was written a lot more like HAML.
Ever use the earliest IDE incarnations of Eclipse on a PC still measured in hundreds of Mhz, or when RAM was still in the dozens of MB? That was the world XML found itself in during its inception.
But, I agree that this is one of the worst parts of XML
Nah, I have an easier time editing XML in a dumb text editor than YAML with the best tooling I've ever found for it.
In fact, I have an easier time with any of its competitors people post around than with YAML. What is distressing, because the language has clearly the goal of being easy to write.
Xcode's plist editing ability is a mild improvement over manipulating XML text directly, but could use more obvious shortcuts/hotkeys. Even writing XML in an IDE like IntelliJ isn't great, autocomplete should do a lot more.
node @attr="bob saget"
subnode @foo="john"
subnode @ham="bar baz"
html:h1
p $"this is literal text"
Humans can screw up anything. And more text often allows it to hide for longer.
XML has them sorta built in (basically all (notable) libraries support them), but it's not like it's required or somehow innately protected because of that. It's just a bit easier to adopt.
JSONSchema? It's pretty standardized and well accepted.
All JSON evaluates to some value in YAML. But it's not always the value you want it to.
Oh hey, I had some while making https://hn-blogs.kronis.dev/
I wrote more about it on my blog: https://blog.kronis.dev/articles/ever-wanted-to-read-thousan... but the gist of it is that I had to parse thousands of blog feeds and some article from 2009 included a SOH control sequence inside of otherwise valid XML and this broke everything, until I added additional error handling.
“test this against Go 1.20”
> It interprets that as Go 1.2.
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.
I am searching for this, any clue ?
However, before you start, there were bugs that I found, and Augeas is a bit hard to work with.