5 ms·

HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your conte

HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your content within a element is replaced by , and moreover define that an asterisk appearing within content is replaced by , toggling emphasized text tags. So SGML very much acknowledges the need for lightweight markup, but the SHORTREF feature, like everything else requiring markup declarations, didn't make it into the XML subset of SGML. HTML itself doesn't have these and other features (such as basic text macros) because SGML was understood to be available at least at authoring time.

nerdponx 4y ago
Why didn't we end up with SGML -> XML "compilers"? As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing. Or are there some SGML features that cannot be represented with an equivalent in XML?
- tannhaeuser 4y ago
 > Why didn't we end up with SGML -> XML "compilers"? We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted depending on parameter entities, and also entity references expanded, etc. But SGML can also output HTML proper, unlike XML. SGML mostly has additional authoring features over XML indeed, but a number of additional concepts as well: much more powerful notations (used as general extension mechanism such as for math or parametric macro expansion) and stylesheets ie. link process declarations with state-dependent assignment of attributes and pipelining to yield markup projections, transforms, and views.
 - nerdponx 4y ago
 Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?
 - tuatoru 4y ago
 Because back in 1995 - 2005, getting a site up and running quickly was more important than doing it right. Cue (and queue) endless kludges to re-do parts of SGML, badly.
 - necovek 4y ago
 I was a big supporter of SGML-based languages: markup language written for humans to author. However, the trend in computing in late 90s and early 2000s was to come up with more easily parsed languages, thus came things like XML: a mark-up language tuned for computers to produce. But let's be honest here: parsing most XML can be done very simply, whereas supporting basic SGML was only possible with the OpenSP. SGML is a specification of over 1000 pages of dense text, and that's before you get a language DTD on top of it (like the HTML or DocBook or TEI DTDs). Basically, it is too complex and too flexible, and it was too expensive to produce the tooling to support it (GUI editors, processing tools, making them performant...). I mean, we are looking at MD here that is even less flexible than HTML: simplicity wins even if it only caters to 90% of the usecases!
 - dtagames 4y ago
 Me, too, having worked at IBM and used SGML there. But JSON is what really killed XML. It can be harder to read, especially at first, but it's shorter and fulfills all the same roles.
 necovek 4y ago
 I wouldn't say JSON killed XML: it's still widely in use for documents whose type definition changes rarely and which are more content oriented. The one benefit to XML/SGML languages is that you've got simple, ubiquotious support for "attributes", plain text content and nested tree content. I.e. to represent An <acronym expanded="HyperText Markup Language">HTML</> page was the driver for interactive web. in JSON, you have to come up with your own conventions for attributes and content: [ { "type": "p", "content": [ {"type": "STRING", "value": "An "}, {"type": "acronym", "attributes": {"expanded": "HyperText Markup Language"}, "content": [{"type": "STRING", "content": "HTML"}]}, {"type": "STRING", "content": " page was the driver for interactive web."} ] } ] I know which one I'd prefer ;) So with JSON, everyone comes up with their own format. And in these cases that XML was designed for (to mark up textual content), it handily beats JSON in expressiveness, simplicity and terseness too. The fact that it was misused for defining protocols and objects (i.e. SOAP, ugh) is a different matter. I would say that SGML/XML languages still have this benefit over even Markdown: any contextual modifier is either impossible or uses a one-off syntax (like images or links with text).

nerdponx 4y ago

Why didn't we end up with SGML -> XML "compilers"? As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing. Or are there some SGML features that cannot be represented with an equivalent in XML?

tannhaeuser 4y ago
> Why didn't we end up with SGML -> XML "compilers"? We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted depending on parameter entities, and also entity references expanded, etc. But SGML can also output HTML proper, unlike XML. SGML mostly has additional authoring features over XML indeed, but a number of additional concepts as well: much more powerful notations (used as general extension mechanism such as for math or parametric macro expansion) and stylesheets ie. link process declarations with state-dependent assignment of attributes and pipelining to yield markup projections, transforms, and views.
- nerdponx 4y ago
 Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?
 - tuatoru 4y ago
 Because back in 1995 - 2005, getting a site up and running quickly was more important than doing it right. Cue (and queue) endless kludges to re-do parts of SGML, badly.
 - necovek 4y ago
 I was a big supporter of SGML-based languages: markup language written for humans to author. However, the trend in computing in late 90s and early 2000s was to come up with more easily parsed languages, thus came things like XML: a mark-up language tuned for computers to produce. But let's be honest here: parsing most XML can be done very simply, whereas supporting basic SGML was only possible with the OpenSP. SGML is a specification of over 1000 pages of dense text, and that's before you get a language DTD on top of it (like the HTML or DocBook or TEI DTDs). Basically, it is too complex and too flexible, and it was too expensive to produce the tooling to support it (GUI editors, processing tools, making them performant...). I mean, we are looking at MD here that is even less flexible than HTML: simplicity wins even if it only caters to 90% of the usecases!
 - dtagames 4y ago
 Me, too, having worked at IBM and used SGML there. But JSON is what really killed XML. It can be harder to read, especially at first, but it's shorter and fulfills all the same roles.
 - necovek 4y ago
 I wouldn't say JSON killed XML: it's still widely in use for documents whose type definition changes rarely and which are more content oriented. The one benefit to XML/SGML languages is that you've got simple, ubiquotious support for "attributes", plain text content and nested tree content. I.e. to represent An <acronym expanded="HyperText Markup Language">HTML</> page was the driver for interactive web. in JSON, you have to come up with your own conventions for attributes and content: [ { "type": "p", "content": [ {"type": "STRING", "value": "An "}, {"type": "acronym", "attributes": {"expanded": "HyperText Markup Language"}, "content": [{"type": "STRING", "content": "HTML"}]}, {"type": "STRING", "content": " page was the driver for interactive web."} ] } ] I know which one I'd prefer ;) So with JSON, everyone comes up with their own format. And in these cases that XML was designed for (to mark up textual content), it handily beats JSON in expressiveness, simplicity and terseness too. The fact that it was misused for defining protocols and objects (i.e. SOAP, ugh) is a different matter. I would say that SGML/XML languages still have this benefit over even Markdown: any contextual modifier is either impossible or uses a one-off syntax (like images or links with text).