Re:Xee: A Modern XPath and XSLT Engine in Rust
by amy_petrik on Friday March 28, 2025 @11:05PM
(#43512357)
XML is honestly the greatest and I'm not sure why it didn't take off. People sometimes ask me, "what impacted the humanity the most - electricity? antibiotics? combustion engines?" -- no, no, and no, it was XML. Everything can be expressed in XML, and basically everything can read and write XML. It's like the whole world could read and write the same files. Imagine what if those files included programs, that's what XSLT is, a program that's a file of the XML format that performs transformations between XML format and XML format. Wow - now everything can read and write your programming language! About 90% of it is usually around a capacity to use XML to document your XML to XML transforming XML code, and then the other 9% is boilerplate, 1% does the lifting. Brilliant. Imagine a more verbose java, for those of us who find java terse, it almost feels like assembly to me. XML is like the tower of babel that unites all of humanity and JSON is the devil that shattered that dream.
Re:Xee: A Modern XPath and XSLT Engine in Rust
by kfuse on Saturday March 29, 2025 @01:18AM
(#43512965)
Maybe one reason is its verbosity for small everyday tasks, like config files or when representing arrays. If xml allowed empty tags there probably would be no need for json.
Re:Xee: A Modern XPath and XSLT Engine in Rust
by forty on Saturday March 29, 2025 @09:25AM
(#43515356)
Empty tag as in <tag /> ?
Re:Xee: A Modern XPath and XSLT Engine in Rust
by amy_petrik on Saturday March 29, 2025 @03:11PM
(#43517769)
That's a bit confusing to me, I don't understand. I think that type of tagging can be ambiguous. Just to suggest a better construct:
<tag type="tag" class="tag" purpose="tag" tag_subtype="empty" description="this is a emptytag, a subtype of tag" empty="true"></tag>
Now, that's not perfect, I would even describe it as minimalist, but I hope it sets you in the right direction!
If your data is essentially a long piece of text, with annotations associated with certain parts of that text, this is where XML shines.
When you try to use XML to represent something like an ecommerce order, financial transaction, instant message and so on, this is where you start to see problems. Trying to shove some extremely convoluted representation of text ranges and their attributes into JSON is just as bad.
A good "rule of thumb" would be "does this document still make sense if all the tags are stripped, and only the text nodes remain?" If yes, choose XML, if not, choose JSON.