3 ms·

> SGML was not mysteriously forgotten. It was buried at a crossroads with a stake through its heart. > SGML developer pivoted to the web and XML Appreciate yo

> SGML was not mysteriously forgotten. It was buried at a crossroads with a stake through its heart. > SGML developer pivoted to the web and XML Appreciate your response, but with respect, that's the kind of hear-say criticism I was almost expecting. First, SGML hasn't gone anywhere. XML is just a proper subset of SGML, written by the same people who developed SGML and updated SGML to allow DTD-less markup aka XML. Next, XML just didn't make it to the web, wich was its entire raison d'etre, as in, chapter one, sentence one of the XML spec. It's true that XML has been used for almost everything and anything except its actual purpose (eg serialization of service payloads when those are consumed by programs rather than pasted into markup, or config file formats). Finally, SGML is the only game in town able to parse HTML based on an international standard. Don't we want a perspective to get us out of the dying web, or at least preserve what's worth preserving of the extant web? Or are you ok with monopolists having captured the web into craptastic browser tech? Now that's something overly complex and user-hostile, and where 12MB doesn't get you very far indeed. SGML complexity is a myth. You can code a parser in about one man-year, with optional features (SHORTREF, LINK, web bindings) taking another half (source: have done it [1]). I will concede that working off the SGML spec alone is ... laborious, and studying it is indeed a non-insignificant part of the work. The spec is only about the markup meta-language as entered by an author, and doesn't say anything about APIs etc (except for ESIS used for test case suites and early Perl-based processors). Closest to a "document information set" would be HyTime "groves" and, later, DOM. Missing from the spec is a formal model for tag inference and for deciding ambiguousness of content models. That void was quickly filled by Brüggemann-Kleins "One-unambiguous grammars" paper ca 1993, plus clarifications by James Clark (author of the SP SGML parser/toolbox [2]). XML Schema appeals to the exact same theory in it's "Unique particle attribution" constraint btw. Now don't get me wrong: there is valid criticism for SGML, and maybe a need for a new subset and/or extension (and I might have ideas to share). Just criticism with a broad brush and false dichotomies doesn't get us anywhere. [1]: http://sgmljs.net http://sgmljs.net [2]: http://www.jclark.com/sp/ http://www.jclark.com/sp/

treve 4y ago
> SGML complexity is a myth. You can code a parser in about one man-year This gave me a bit of a chuckle.
chrismorgan 4y ago
> SGML complexity is a myth. You can code a parser in about one man-year, with optional features (SHORTREF, LINK, web bindings) taking another half (source: have done it [1]). You’re waaaay off base if you think these figures make SGML complexity a myth. https://bundlephobia.com/package/sgml@0.2.1-beta https://bundlephobia.com/package/sgml@0.2.1-beta shows sgml.js to be about 400KB of minified code, and the bundle also contains sgml-ua.min.js which is 400KB but I think a different 400KB, and a simple line count shows sgml-ua.js and everything-else to each be around 18,000 lines excluding comments. You can implement XML (https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/) minus doctypes in a couple of hours, no trouble. You can add doctypes (including remote fetching, assuming an HTTP library) and validation in less than the remainder of a man-day. Be generous about doing a bang-up job of it all, and you’ll still easily be done in under a week. (And in a language like JavaScript, it’d probably be a couple of thousand lines at the most, depending of course on how you choose to model it all; possibly under 500.) SGML is very complex compared with XML. SGML has departed like Jehoram of old: to no one’s regret.
- tannhaeuser 4y ago
  sgmljs.net also bundles a markdown parser, a DTD for W3C HTML 5.2 (a really long string), SGML declaration support, loads of diagnostic messages, an URL parser, SGML LINK with pipelining and templating, implementations for a couple of (HyTime general arch) formal system identifiers such as for date and CSV parsing/formatting, plus a couple other things. It has essentially no external dependencies. The XML subset of SGML is simpler (that's the entire point of it) but implementing DOCTYPEs with the subset of markup declarations supported by XML still will take you much more than "the remainder of a man-day" LOL. Yes unlike with SGML, you can use an off-the-shelf regexp lib to perform actual checking, but you still need to perform model admissibility/ambiguousness checking with halfway usable diagnostics, and require hundreds of test cases. XML might be ok as a markup delivery format (that didn't make it on the web), but it absolutely doesn't begin to meet the bar of an authoring format. If it were, nobody would be using markdown, MediaWiki syntax, or other custom Wiki syntax, and your collection of helper apps and CMSs, template engines, and whatnot. All of which is included in SGML. (Still, I upvoted your comment FWIW)
ekidd 4y ago
I suppose I should actually give more details. You probably already know most of this history. I was basically still a kid, working for a vendor in 1997, and my job was to write a library for manipulating SGML parse trees. Today, it would be a DOM library, but the HTML DOM wasn't standardized until the fall of 1998. I think I remember hearing about HyTime, but I didn't have a copy of any of their related work. I basically had a copy the SGML standard, and of James Clark's nsgmls parser. A very experienced and capable colleague was in charge of writing an SGML parser. Our target machines had roughly 8MB of RAM and maybe 80 MHz CPUs. Which meant they could parse SGML, but it took a noticeable amount of their resources. My frustration with implementing SGML was first-hand, although I was working on the easy bits. SGML at the time was mostly an expensive enterprise niche, except for James Clark's excellent free tools. The most popular application I saw in the wild was probably DocBook? A lot of SGML vendors were playing up the connection between SGML and HTML in an effort to seem relevant, but their tools were notoriously expensive. None of the vendors were especially mainstream. The arrival of XML really was a sea change. Judging from my colleagues who actually attended trade shows and who paid attention to the other players, the enterprise SGML vendors basically saw XML as an attempt to break out of their niche. XML was almost immediately "mainstream", at least for people who wanted something other than HTML tag soup. Of course, as you point out, HTML ultimately turned away from XML. But the number of people who knew and cared about XML seemed to rapidly exceed the size of the SGML community. > Finally, SGML is the only game in town able to parse HTML based on an international standard. Is this actually true? Can any standards-compliant SGML parser actually parse arbitrary valid HTML 5 as SGML, and pass the test suites? https://www.w3.org/html/wg/wiki/Testing https://www.w3.org/html/wg/wiki/Testing The HTML 5 spec at https://html.spec.whatwg.org/ https://html.spec.whatwg.org/ states: > Also, since neither of the two authoring formats defined in this specification are applications of SGML, a validating SGML system cannot constitute a conformance checker either. HTML 5 has two syntaxes. There's the "HTML" syntax, which is basically tag soup, but at least there's an actual parsing spec these days. There's also apparently still an XML syntax for HTML 5? But the HTML syntax is the one that's common on the web. > Missing from the spec is a formal model for tag inference and for deciding ambiguousness of content models. That void was quickly filled by Brüggemann-Kleins "One-unambiguous grammars" paper ca 1993, plus clarifications by James Clark As far as I can tell, this sort complex and opaque documentation is one reason why promising standards get outcompeted by clear, simple 30-page specs. I've seen so many interesting technologies wind up as obscure footnotes in history because few companies could implement them at an acceptable cost. (Of course, today, a good open source implementation can play a much larger role.) But to respond to your original remarks, I think this one of the major reasons that "each comp sci generation" ignores so much of the past. The past was frequently frustrating. It sometimes had glaring drawbacks. Often it was expensive and proprietary. And sometimes the ideas were too far ahead of their time. I fondly remember at least a dozen technologies that contained brilliant ideas, but which never succeeded in becoming popular. Usually the reasons why they failed (or at least remained obscure) are obvious in retrospect.

treve 4y ago

> SGML complexity is a myth. You can code a parser in about one man-year This gave me a bit of a chuckle.

chrismorgan 4y ago

> SGML complexity is a myth. You can code a parser in about one man-year, with optional features (SHORTREF, LINK, web bindings) taking another half (source: have done it [1]). You’re waaaay off base if you think these figures make SGML complexity a myth. https://bundlephobia.com/package/sgml@0.2.1-beta https://bundlephobia.com/package/sgml@0.2.1-beta shows sgml.js to be about 400KB of minified code, and the bundle also contains sgml-ua.min.js which is 400KB but I think a different 400KB, and a simple line count shows sgml-ua.js and everything-else to each be around 18,000 lines excluding comments. You can implement XML (https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/) minus doctypes in a couple of hours, no trouble. You can add doctypes (including remote fetching, assuming an HTTP library) and validation in less than the remainder of a man-day. Be generous about doing a bang-up job of it all, and you’ll still easily be done in under a week. (And in a language like JavaScript, it’d probably be a couple of thousand lines at the most, depending of course on how you choose to model it all; possibly under 500.) SGML is very complex compared with XML. SGML has departed like Jehoram of old: to no one’s regret.

tannhaeuser 4y ago
sgmljs.net also bundles a markdown parser, a DTD for W3C HTML 5.2 (a really long string), SGML declaration support, loads of diagnostic messages, an URL parser, SGML LINK with pipelining and templating, implementations for a couple of (HyTime general arch) formal system identifiers such as for date and CSV parsing/formatting, plus a couple other things. It has essentially no external dependencies. The XML subset of SGML is simpler (that's the entire point of it) but implementing DOCTYPEs with the subset of markup declarations supported by XML still will take you much more than "the remainder of a man-day" LOL. Yes unlike with SGML, you can use an off-the-shelf regexp lib to perform actual checking, but you still need to perform model admissibility/ambiguousness checking with halfway usable diagnostics, and require hundreds of test cases. XML might be ok as a markup delivery format (that didn't make it on the web), but it absolutely doesn't begin to meet the bar of an authoring format. If it were, nobody would be using markdown, MediaWiki syntax, or other custom Wiki syntax, and your collection of helper apps and CMSs, template engines, and whatnot. All of which is included in SGML. (Still, I upvoted your comment FWIW)

ekidd 4y ago

I suppose I should actually give more details. You probably already know most of this history. I was basically still a kid, working for a vendor in 1997, and my job was to write a library for manipulating SGML parse trees. Today, it would be a DOM library, but the HTML DOM wasn't standardized until the fall of 1998. I think I remember hearing about HyTime, but I didn't have a copy of any of their related work. I basically had a copy the SGML standard, and of James Clark's nsgmls parser. A very experienced and capable colleague was in charge of writing an SGML parser. Our target machines had roughly 8MB of RAM and maybe 80 MHz CPUs. Which meant they could parse SGML, but it took a noticeable amount of their resources. My frustration with implementing SGML was first-hand, although I was working on the easy bits. SGML at the time was mostly an expensive enterprise niche, except for James Clark's excellent free tools. The most popular application I saw in the wild was probably DocBook? A lot of SGML vendors were playing up the connection between SGML and HTML in an effort to seem relevant, but their tools were notoriously expensive. None of the vendors were especially mainstream. The arrival of XML really was a sea change. Judging from my colleagues who actually attended trade shows and who paid attention to the other players, the enterprise SGML vendors basically saw XML as an attempt to break out of their niche. XML was almost immediately "mainstream", at least for people who wanted something other than HTML tag soup. Of course, as you point out, HTML ultimately turned away from XML. But the number of people who knew and cared about XML seemed to rapidly exceed the size of the SGML community. > Finally, SGML is the only game in town able to parse HTML based on an international standard. Is this actually true? Can any standards-compliant SGML parser actually parse arbitrary valid HTML 5 as SGML, and pass the test suites? https://www.w3.org/html/wg/wiki/Testing https://www.w3.org/html/wg/wiki/Testing The HTML 5 spec at https://html.spec.whatwg.org/ https://html.spec.whatwg.org/ states: > Also, since neither of the two authoring formats defined in this specification are applications of SGML, a validating SGML system cannot constitute a conformance checker either. HTML 5 has two syntaxes. There's the "HTML" syntax, which is basically tag soup, but at least there's an actual parsing spec these days. There's also apparently still an XML syntax for HTML 5? But the HTML syntax is the one that's common on the web. > Missing from the spec is a formal model for tag inference and for deciding ambiguousness of content models. That void was quickly filled by Brüggemann-Kleins "One-unambiguous grammars" paper ca 1993, plus clarifications by James Clark As far as I can tell, this sort complex and opaque documentation is one reason why promising standards get outcompeted by clear, simple 30-page specs. I've seen so many interesting technologies wind up as obscure footnotes in history because few companies could implement them at an acceptable cost. (Of course, today, a good open source implementation can play a much larger role.) But to respond to your original remarks, I think this one of the major reasons that "each comp sci generation" ignores so much of the past. The past was frequently frustrating. It sometimes had glaring drawbacks. Often it was expensive and proprietary. And sometimes the ideas were too far ahead of their time. I fondly remember at least a dozen technologies that contained brilliant ideas, but which never succeeded in becoming popular. Usually the reasons why they failed (or at least remained obscure) are obvious in retrospect.