2 ms·

XML's main limitation derives from its base primitives: Strings and hierarchies of ordered strings labelled with strings. Starting from that premise adds a grea

XML's main limitation derives from its base primitives: Strings and hierarchies of ordered strings labelled with strings. Starting from that premise adds a great degree of schematic overhead to convey semantics, which tends to overflow into syntactical boilerplate. Traditional parsers start from one string and evaluate that a character at a time. JSON starts from a few JavaScript primitives. SQL has primitives that vary with the engine you're using. These are other points on the spectrum that are appealing in the details - a plaintext string is accessible to all text editors and simple string processing tools. JSON covers a selection of common data primitives. And SQL has a grip on automatic constraint enforcement, which helps in defining user types with high data integrity. If I had to pick one that's really going underused, SQL would be it. A string source file could be dissected into a number of tables and edited like any other CRUD system, then re-serialized as a string. That we don't do it this way is more an accident of our current beliefs about which means of implementation are appropriate for various tasks - queries on relational data are "slow" compared to bodging buffers and recursing through DAGs. But if we want nice developer tools we should probably start acting like data integrity is more important. Slopping dependencies around the file system and relying on a separate bespoken tool chain to reconstruct their relationships as part of a built artifact is a thing we ought to outgrow at some point, but it's also so intrinsically accepted that the paradigm is hard to escape.

tannhaeuser 6y ago
It's somewhat unfortunate that XML arrived at this perception of being complex, when SGML (= superset of XML, HTML, and everything angle-bracket markup) very much is a technique to give structure to ordinary plain text. For example, SGML could parse .INI file syntax such as the following (and present it as a fully-tagged, canonical markup ie. XML): [config-item-X] config-param-Y=bla config-param-Z=123 If you look at how popular markdown and other wiki syntax is, and at the same seeing folks hit markdown's limitations fairly quickly (for example, markdown has no way to pull-in content from other files or doing any document composition whatsoever), then I hope you can see that SGML is a technique designed for a broad application in this area, being able to handle standard markdown and custom markdown extensions (not to mention that SGML is the only ISO markup meta-language able to handle HTML with all it's tag omission rules). In XML-land, this has been re-discovered as "invisible markup" a couple years ago, going full-circle in the "dumbing down" of SGML into XML (which was seen as progress and win for simplicity at the time when XML was subset from SGML). I would also disagree that the defining characteristic of SGML/XML is nesting of tags so much as it is regular content models. A content model such as configitem: configparam+ configparam: configparam-name, configparam-value is what drives SGML's tag inference in the above example. But yeah, SGML/XML is made for markup, not necessarily config files and service payloads. And I agree SQL could be improved by treating it like an ordinary programming language, with the same focus on SQL artifacts wrt syntax highlighting, static checking, and testing (though probably not in the way you suggested, by reading-in SQL script files as a primary means to serialize DBs :).

tannhaeuser 6y ago

It's somewhat unfortunate that XML arrived at this perception of being complex, when SGML (= superset of XML, HTML, and everything angle-bracket markup) very much is a technique to give structure to ordinary plain text. For example, SGML could parse .INI file syntax such as the following (and present it as a fully-tagged, canonical markup ie. XML): [config-item-X] config-param-Y=bla config-param-Z=123 If you look at how popular markdown and other wiki syntax is, and at the same seeing folks hit markdown's limitations fairly quickly (for example, markdown has no way to pull-in content from other files or doing any document composition whatsoever), then I hope you can see that SGML is a technique designed for a broad application in this area, being able to handle standard markdown and custom markdown extensions (not to mention that SGML is the only ISO markup meta-language able to handle HTML with all it's tag omission rules). In XML-land, this has been re-discovered as "invisible markup" a couple years ago, going full-circle in the "dumbing down" of SGML into XML (which was seen as progress and win for simplicity at the time when XML was subset from SGML). I would also disagree that the defining characteristic of SGML/XML is nesting of tags so much as it is regular content models. A content model such as configitem: configparam+ configparam: configparam-name, configparam-value is what drives SGML's tag inference in the above example. But yeah, SGML/XML is made for markup, not necessarily config files and service payloads. And I agree SQL could be improved by treating it like an ordinary programming language, with the same focus on SQL artifacts wrt syntax highlighting, static checking, and testing (though probably not in the way you suggested, by reading-in SQL script files as a primary means to serialize DBs :).