4 ms·

> What if we pretend we can go back in time, and create a transparent, gracefully degrading plain-text format that is trivial to build viewers and editors for?

> What if we pretend we can go back in time, and create a transparent, gracefully degrading plain-text format that is trivial to build viewers and editors for? Actually, the idea behind SGML's SHORTREF feature is exactly that: yöu can define char sequences consisting of newlines, tabs, or any sequence of chars not already interpreted as markup delimiter, and gave SGML replace those into eg a start- or end-element tag or whatever, in a context-dependent way so you can cover most of markdown, or CSV, or JSON. And we have to go only as far back in time as 1986 when SGML was published as an ISO standard after a decade or so of reaching consensus. It's not exactly trivial though, but not that hard either by today's standard. Beyond SGML, what's really puzzling to me is that we keep on throwing mud against a wall to see what sticks, and every comp.sci. generation seem to reinvent everything from scratch without consideration what came before. It's especially paradoxical considering SGML legacy as a text format is directly in front of you as HTML, and materials on SGML and HTML are broadly accessible. Why invent text formats for the long haul if nobody bothers reading?

jasim 4y ago
Is there a tool that does what Karthik's software does, but with SGML?
ekidd 4y ago
> Beyond SGML, what's really puzzling to me is that we keep on throwing mud against a wall to see what sticks, and every comp.sci. generation seem to reinvent everything from scratch without consideration what came before. I'm old enough to remember the height of SGML's popularity. I used to work in the office next to someone who was writing an SGML parser. He was an incredibly skilled developer; he was also the editor of the spec for a major programming language. And he loathed SGML. The SGML standard was a $99 doorstop of a book. Parsing SGML (and DTDs, and capability declarations) was basically impossible using standard parsing theory. Instead, you needed hundreds of hand-built parsing routines. And even when you parsed some SGML, you were left with the frustrating fact that there was no standard "document information set" (if I recall the name correctly) that told you what your parser should return. One of our favorite lunch-time rants was "Someone should define a stripped-down version of SGML that doesn't require a 2.3 MB C++ parsing library (because our users only have 8MB of RAM, and they're using 12 MB of that to run Netscape and an OS)." Then one day, my boss walks in and says, "Hey, our corporate W3 representative just got a copy of this. You'll like it." And he dropped an early draft of XML on my desk. The spec was 30 pages long, and easy to implement. Within a month, pretty much everyone who could abandon SGML had done so. A few legacy vendors continued supplying enterprise SGML users, but every other SGML developer pivoted to the web and XML. It was a chance to trade frustrating niche tools for a hot web market. SGML occupied a weird middle space: It was not only programmer hostile, but its creator bragged about how it was programmer hostile, because users came first. Except SGML was still far too technical for any mainstream users, who normally wanted GUI tools. SGML was not mysteriously forgotten. It was buried at a crossroads with a stake through its heart. And plenty of programmers who worked with SGML volunteered to shovel.
- tannhaeuser 4y ago
  > 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.

jasim 4y ago

Is there a tool that does what Karthik's software does, but with SGML?

ekidd 4y ago

> Beyond SGML, what's really puzzling to me is that we keep on throwing mud against a wall to see what sticks, and every comp.sci. generation seem to reinvent everything from scratch without consideration what came before. I'm old enough to remember the height of SGML's popularity. I used to work in the office next to someone who was writing an SGML parser. He was an incredibly skilled developer; he was also the editor of the spec for a major programming language. And he loathed SGML. The SGML standard was a $99 doorstop of a book. Parsing SGML (and DTDs, and capability declarations) was basically impossible using standard parsing theory. Instead, you needed hundreds of hand-built parsing routines. And even when you parsed some SGML, you were left with the frustrating fact that there was no standard "document information set" (if I recall the name correctly) that told you what your parser should return. One of our favorite lunch-time rants was "Someone should define a stripped-down version of SGML that doesn't require a 2.3 MB C++ parsing library (because our users only have 8MB of RAM, and they're using 12 MB of that to run Netscape and an OS)." Then one day, my boss walks in and says, "Hey, our corporate W3 representative just got a copy of this. You'll like it." And he dropped an early draft of XML on my desk. The spec was 30 pages long, and easy to implement. Within a month, pretty much everyone who could abandon SGML had done so. A few legacy vendors continued supplying enterprise SGML users, but every other SGML developer pivoted to the web and XML. It was a chance to trade frustrating niche tools for a hot web market. SGML occupied a weird middle space: It was not only programmer hostile, but its creator bragged about how it was programmer hostile, because users came first. Except SGML was still far too technical for any mainstream users, who normally wanted GUI tools. SGML was not mysteriously forgotten. It was buried at a crossroads with a stake through its heart. And plenty of programmers who worked with SGML volunteered to shovel.

tannhaeuser 4y ago
> 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.