X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2446" "Wed" "28" "June" "1995" "14:41:43" "-0600" "Nelson H. F. Beebe" "beebe@MATH.UTAH.EDU" nil "44" "Re: (La)TeX is SGML?" "^Date:" nil nil "6" nil nil nil nil] nil) Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzg.zdv.Uni-Mainz.DE [134.93.178.7]) by trudi.zdv.Uni-Mainz.DE (8.6.12/8.6.12) with ESMTP id XAA13689 for ; Wed, 28 Jun 1995 23:35:49 +0200 Received: from DIRECTORY-DAEMON by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.3-12 #4432) id <01HS9A363MG09352V1@MZDMZA.ZDV.UNI-MAINZ.DE>; Wed, 28 Jun 1995 23:35:47 +0100 Received: from mxrelay.gmd.de by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.3-12 #4432) id <01HS9A2ZQQ349AMI60@MZDMZA.ZDV.UNI-MAINZ.DE>; Wed, 28 Jun 1995 23:35:39 +0100 Received: from vm.gmd.de by mxrelay.gmd.de (LSMTP for OpenVMS v0.1a) with SMTP id 515EEBC8 ; Wed, 28 Jun 1995 23:35:29 +0200 Received: from VM.GMD.DE (NJE origin LISTSERV@DEARN) by VM.GMD.DE (LMail V1.2b/1.8b) with BSMTP id 6449; Wed, 28 Jun 1995 23:35:06 +0200 Received: from VM.URZ.UNI-HEIDELBERG.DE by VM.URZ.UNI-HEIDELBERG.DE (LISTSERV release 1.8b) with NJE id 1726 for LATEX-L@VM.URZ.UNI-HEIDELBERG.DE; Wed, 28 Jun 1995 23:32:48 +0000 Received: from DHDURZ1 (NJE origin SMTP@DHDURZ1) by VM.URZ.UNI-HEIDELBERG.DE (LMail V1.2a/1.8a) with BSMTP id 2108; Wed, 28 Jun 1995 23:31:22 +0000 Received: from csc-sun.math.utah.edu by vm.urz.Uni-Heidelberg.de (IBM VM SMTP V2R2) with TCP; Wed, 28 Jun 95 23:31:11 CET Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with ESMTP id OAA13287; Wed, 28 Jun 1995 14:41:45 -0600 Received: (beebe@localhost) by plot79.math.utah.edu (8.6.11/8.6.11) id OAA05795; Wed, 28 Jun 1995 14:41:43 -0600 In-reply-to: Your message of Wed, 28 Jun 1995 19:43:08 +0100 Reply-to: Mailing list for the LaTeX3 project Message-id: X-Envelope-to: schoepf@goofy.zdv.uni-mainz.de MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Date: Wed, 28 Jun 1995 14:41:43 -0600 From: "Nelson H. F. Beebe" Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: (La)TeX is SGML? Status: R X-Status: X-Keywords: X-UID: 1663 Discussions this morning on the LaTeX3 project list raise the issue of whether ``it will be possible to "compile" directly SGML documents...'' in TeX. Folks, don't hold your breath on this one. Here is why: (1) SGML is a complex language definition, and its grammar, right down to meaning of individual characters (vaguely like TeX's \catcode wizardry), is determined on-the-fly during processing of the grammar file prior to processing the document encoded in that grammar. In particular, the `standard' tools (lex/flex/LeX, bison/yacc/occs, ...) for creating lexers, parsers, and compilers for LL(1), LALR(1), and LR(1) grammars (incidentally, Don Knuth is the father of LR(k) parsing), are incapable of handling the more complicated SGML grammars. (2) Two hand-coded validating parsers for SGML already exist, both by James Clark, so we already have solid evidence of the complexity of the task. The first generation implementation, sgmls, is 22K lines of C code, about 10% larger than either TeX or Metafont. The second generation implementation, nsgmls, is more than 45K lines of C++ code (and also includes two tag normalizers and an SGML support library). Both C and C++ are MUCH better suited to writing compilers or parsers than TeX is; a full-blown SGML parser in TeX is very likely infeasible, and certainly foolish. [For more information on SGML tools, visit my home page, whose URL appears elsewhere in this mail message.] The already-existing translators from SGML to (La)TeX are not complete solutions, because (a) they are based on particular document type definitions (notably, HTML), NOT the general SGML grammar, and (b) they are not founded on a rigorous grammatical analysis, but rather on simple ad hoc pattern matching. Thus, they can do a good bit of the job, but will never be completely reliable. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ========================================================================