- say you have an incoming data document. Say you need to programmatically read it / scan it / extract from it (think: cli and pipes).
You want to access this data for any of dozens of reasons. Graphs, logs, data points, transformations, data feeds, whatever.
I can do that task in json and yaml 10000% faster than with XML. With XML, you may have a schema (hope the document matches the putative schema!). Oh the schema is an http reference? Hope that still exists out there, the internet never breaks links. If you don't, well shit, is this tag beginning a list or a "subdocument"? Am I REALLY using the DOM api to step through nodes and attributes and CDATA? Guess I have to. There goes a day of coding.
Oh, in JSON and YAML, it's ONE LINE OF CODE to get it into something I can easily read, manipulate, analyze?
- say you have an upgrade program. it just needs to read in the old config file, rename some keys, add some new default values, etc. JSON/YAML? I can do that in stupid-simple code. XML? Well, I better hope there exists a library that loads this shit for me in my preferred language, or otherwise lots of fun with DOM. I forget, can I use regex to parse XML? (that is a joke)
- say I want to serialize an object graph pretty quickly for over the wire between languages. Do I want to write a complete XML mapping in two languages, or just do the one-line serialize, one-line deserialize? Yeah.
- say I want my config files to be somewhat extension friendly for plugins / extensions. XML parsing code? Yeah, that will be a ton of custom code. YAML/JSON deserializing to a map/dictionary? Oh, look at that, extension friendly code. Allow them to specify whatever json/yaml struct in their plugin section and pass it to the extension.
This stuff happens with such frequency that I never, ever think "man I wish this was XML".
Do YAML/JSON have some issues? Do I wish XPath and some XML features have json equipvalents? Sure ... very occaisionally. Actually, never.
Where to begin...
If the schema is not there you are in the same position as with receiving some json or yaml: a bad one. Is 20230806 and integer or someones idea of sending a day?
Parsing the data into a memory structure is a one liner in any language. Assigning meaning however..
Object graph between languages as you subscribe works only in a very small number of cases. Sent your data to a mainframe and see it disappear faster than you can sent it.
Extensions is where xml shines: use an extension namespace. Hell use a namespace per plugin. Unknown namespaces are normally ignored during deserialization if you use a schema, so no line of code needed at al.
All the issues you describe boil doen in my book as: i don't know how to do this properly with xml so xml is bad.
You want to access this data for any of dozens of reasons. Graphs, logs, data points, transformations, data feeds, whatever.
I can do that task in json and yaml 10000% faster than with XML. With XML, you may have a schema (hope the document matches the putative schema!). Oh the schema is an http reference? Hope that still exists out there, the internet never breaks links. If you don't, well shit, is this tag beginning a list or a "subdocument"? Am I REALLY using the DOM api to step through nodes and attributes and CDATA? Guess I have to. There goes a day of coding.
Oh, in JSON and YAML, it's ONE LINE OF CODE to get it into something I can easily read, manipulate, analyze?
- say you have an upgrade program. it just needs to read in the old config file, rename some keys, add some new default values, etc. JSON/YAML? I can do that in stupid-simple code. XML? Well, I better hope there exists a library that loads this shit for me in my preferred language, or otherwise lots of fun with DOM. I forget, can I use regex to parse XML? (that is a joke)
- say I want to serialize an object graph pretty quickly for over the wire between languages. Do I want to write a complete XML mapping in two languages, or just do the one-line serialize, one-line deserialize? Yeah.
- say I want my config files to be somewhat extension friendly for plugins / extensions. XML parsing code? Yeah, that will be a ton of custom code. YAML/JSON deserializing to a map/dictionary? Oh, look at that, extension friendly code. Allow them to specify whatever json/yaml struct in their plugin section and pass it to the extension.
This stuff happens with such frequency that I never, ever think "man I wish this was XML".
Do YAML/JSON have some issues? Do I wish XPath and some XML features have json equipvalents? Sure ... very occaisionally. Actually, never.