https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
Last thing I really did with XML was a technology called EXI, a transfer method that converted an XML document into a compressed binary data stream. Because translating a data structure to ASCII, compressing it, sending it over HTTP etc and doing the same thing in reverse is a bit silly. At this point protobuf and co are more popular, but imagine if XML stayed around. It's all compatible standards working with each other (in my idealized mind), whereas there's a hard barrier between e.g. protobuf/grpc and JSON APIs. Possibly for the better?
I was curious about how it is implemented and I found the spec easy to read and quite elegant: https://www.w3.org/TR/exi/
For a transport tech XML was OK. Just wasted 20% of your bandwidth on being a text encoding. Plus wrapping your head around those style sheets was a mind twister. Not surprised people despise it. As it has the ability to be wickedly complex for no real reason.
XPath is kind of fine. It's hard to remember all the syntax but I can usually get there with a bit of experimentation.
XSLT is absolutely insane nonsense and needs to die in a fire.
True, and it's even more sad that XML was originally just intended as a simplified subset of SGML (HTML's meta syntax with tag inference and other shortforms) for delivery of markup on the web and to evolve markup vocabularies and capabilities of browsers (of which only SVG and MathML made it). But when the web hype took over, W3C (MS) came up with SOAP, WS-this and WS-that, and a number of programming languages based on XML including XSLT (don't tell HNers it was originally Scheme but absolutely had to be XML just like JavaScript had to be named after Java; such was the madness).
If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.
/*bookstore/*book/*title
its been some godawful mess like
/*[name()='bookstore']/*[name()='book']/*[name()='title']
... I guess because they couldn't bear to have it just match on tags as they are in the file and it had to be tethered to some namespace stuff that most people dont bother with. A lot of XML is ad-hoc without a namespace defined anywhere
Its like
Me: Hello Xpath, heres an XML document, please find all the bookstore/book/title tags
Xpath: *gasps* Sir, I couldn't possibly look for those tags unless you tell me which namespace we are in. Are you some sort of deviant?
Me: oh ffs *googles xpath name() syntax*
Is not actually relevant and is not an information the average XML processor even receives. If the file uses a default namespace (xmlns), then the elements are namespaced, and anything processing the XML has to either properly handle namespaces or explicitly ignore namespaces.
> A lot of XML is ad-hoc without a namespace defined anywhere
If the element is not namespaced xpath does not require a prefix, you just write
//bookstore/book/titlemy:book is a different thing from your:book and you generally don't want to accidentally match on both. Keeping them separate is the entire point of namespaces. Same as in any programming language.
/*:bookstore/*:book/*:titleXML is a markup language system. You typically have a document, and various parts of it can be marked up with metadata, to an arbitrary degree.
JSON is a data format. You typically have a fixed schema and things are located within it at known positions.
Both of these have use-cases where they are better than the other. For something like a web page, you want a markup language that you progressively render by stepping through the byte stream. For something like a config file, you want a data format where you can look up specific keys.
Generally speaking, if you’re thinking about parsing something by streaming its contents and reacting to what you see, that’s the kind of application where XML fits. But if you’re thinking about parsing something by loading it into memory and looking up keys, then that’s the kind of application where JSON fits.