why can't you people just use json?
XML is a cheap DSL
101–110 of 274 posts
Re: XML is a cheap DSL
#102XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…
Your first counterpoint seems unnecessarily picky.
> So while it is a suitable DSL for many things (it is also seeing new life in web components definition), we are mostly only talking about XML-lookalike language, and not XML proper. If you go XML proper, you need to throw "cheap" out the window.
But the TWE did not embrace all that stuff. It’s not required for its purpose. And to call it “xml lookalike” on that basis seems odd. It’s objectively XML. It doesn’t use every xml feature, but it’s still XML.
It’s as if you’re saying, a school bus isn’t a bus, it’s just a bus-lookalike. Buses can have cup holders and school buses lack cup holders. Therefore a school bus is not really a bus.
I don’t see the validity or the relevance.
Re: XML is a cheap DSL
#103XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…
I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…
I think JSON has the opposite problem, it is too simple, the lack of comments in particular is particularly bad for many common usages of the format today.
I know some implementations of JSON support comments and other things, but is is not true JSON, in the same way that most simple XML implementations are not true XML. That's what I say "opposite problem", XML is too complex, and most practical uses of XML use incomplete implementations, while many practical uses of JSON use extended implementations.
By the way, this is not a problem for what JSON was designed for: a text interchange format, with JS being the language of choice, but it has gone beyond its design: configuration files, data stores, etc...
Re: XML is a cheap DSL
#104Earlier quoted context omitted.
Author here. I agree with all this, and I think it's important to note that nothing precludes you from doing a declarative specification that looks like imperative math notation, but it's also somewhat besides the point. Yes, you could make your own custom language, but then you have created the problem that the article is about: You need to port your parser to every single different place you want to use it. That's…
Why did you hardly engaged in the article on the subject of schema driven validation?
I used xml and xpath a lot in the early 2000s when it was popular, and I never wrote or learned about schema validation. It's totally optional and I never found a need for it.
It's probably helpful for "standard data interchange between separate parties" use cases, in what I was doing I totally controlled the production and the interpretation of the xml.
Re: XML is a cheap DSL
#105The trouble with XML has never been XML itself. It was also about how easy it was to generate great XML. Because it is complicated and everyone doesn't really agree on how to properly representative an idea or concept, you have to deal with varying output between producers. I personally love well formed XML, but the std dev is huge. Things like JSON have a much more tighter std dev. The best XML I've seen is generate…
Maybe rather: how easy it was to generate rotten XML. I feel you there.
The XML community, though, embraced the problem of different outputs between different producers, and assumed you'd want to enable interoperability in a Web-sized community where strict patterns to XML were infeasible. Hence all the work on namespaces, validation, transformation, search, and the Semantic Web, so that you could still get stuff done even when communities couldn't agree on their output.
Re: XML is a cheap DSL
#106As someone who knows exactly as much COBOL as everyone else here, XML is what comes out of Java tooling as the handicap for the office that demands Windows tools; of course, it's barbaric. The real crime is sending me this article in HTML, AKA the Super Weenie Hut Jr of generalized markup languages. Adobe FrameMaker is the real text editor used to forge your generalized markup language. Rumor has it that when FrameMaker dropped Mac support, Jobs cut out Flash games in the next Super Weenie Hut Junior.
Re: XML is a cheap DSL
#107Earlier quoted context omitted.
> Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink. But you don't have to use all those things. Configure your parser without namespace support, DTD support, etc. I'd much rather have a tool with tons of capabilities that can be selectively disabled rather than a "simple" one that requires _me_ to bolt on said…
As a data interchange format, you can only depend on the lowest commonly implemented features, which for XML is the base XML spec. For example, Namespaces is a "recommendation", and a conformant XML parser doesn't need to support it.
The problem comes when malicious actors start crafting documents with extra features that should not be parsed, but many software will wrongly parse them because they use the default, full featured parser. Or various combinations of this.
It's a pretty well understood problem and best practices exist, not everyone implements them.
Re: XML is a cheap DSL
#108To go up one level of abstraction; any thoughts on to whether or not we might actually be able "solve" the time old problem of "which data format" thanks to ubiquitous AI tooling?
Just kind of spitballing here, but in a world where can point AI at some good, or badly formed -- XML, json, toml whatever and just kind of say "hey, what's going on here, fix it?"
Re: XML is a cheap DSL
#109The trouble with XML has never been XML itself. It was also about how easy it was to generate great XML. Because it is complicated and everyone doesn't really agree on how to properly representative an idea or concept, you have to deal with varying output between producers. I personally love well formed XML, but the std dev is huge. Things like JSON have a much more tighter std dev. The best XML I've seen is generate…
Surely this is a product of the fact that XML is just more extensible (it’s in the name after all).
If you tried to represent the data (exactly) from any of the examples in the post, I think you’d find that you’d experience many of the same problems.
Personally, I think the problem with XML has always been the tooling. Slow parsers, incomplete validators
Re: XML is a cheap DSL
#110What I would do here is something like:
1. standardize on JSON as the internal representation, and
2. write a simple (So you would write something like:
from factgraph import Max, Dollar # or just import *
tentative_tax_net_nonrefundable_credits = Max(Dollar(0), total_tentative_tax - total_nonrefundable_credits)
def __sub__(self, other):
return SubtractNode(minuent=self, subtrachents=[other])