Date: Wed, 14 May 1997 18:35:21 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: "Pedro F. Giffuni" <pgiffuni@fps.biblos.unal.edu.co>, Jean-Marc Zucconi <jmz@cabri.obs-besancon.fr>, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Is Thot (WYSIWIG editor) for you? Message-ID: <Pine.BSF.3.96.970514174011.311x-100000@fallout.campusview.indiana.edu> In-Reply-To: <199705142238.PAA21497@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 May 1997, Amancio Hasty wrote: > Whats the fundamental difference between an HTML editor and a SGML editor? SHORT VERSION An HTML editor is typically hardwired for the tags and document structure that the HTML DTD defines. An SGML editor can read *any* DTD to learn about the structure of documents conforming to that DTD. The editing functionality must be driven by the structure defined in the DTD, not anything hard coded. Likewise, for quasi-WYSIWYG visualization the rendering must be driven by a style-sheet loaded at run-time. Not having looked carefully at Thot, I have no idea how close it would be to being a truly general SGML editor. As I said, the overall design seems to be *conceptually* compatible with SGML which is a good thing. It may fall short on the "G" dimensions of SGML though. (G = Generalized) > It looks to me that HTML is a subset of SGML so by way of handling tags LONG VERSION It is more like the relationship between, say, C and awk. Awk is implemented using C, it isn't a subset of C. SGML provides the world with two basic things: a mechanism for defining markup languages (the document type definition, or DTD) and standardized rules for parsing any document marked up with according to an SGML DTD. To illustrate, here is an SGML DTD and associated document: <!DOCTYPE foo [ <!ELEMENT foo - - (a, b)+> <!ELEMENT a - - (#PCDATA)> <!ELEMENT b - - (#PCDATA)> ]> <foo> <a>A FOO document must contain an A element...</a> <b>followed by a B element.</b> <a>and because of the +, the A, B pair may be repeated.</a> <b>like this!</b> </foo> Since the parsing rules are the same regardless of the DTD, you only have to write an SGML parser once, and it can be reused in any application that deals with SGML files. For this example, a good SGML editor would read the DTD part (between the [ and ]) and know that a FOO must contain an A followed by a B, and optionally more A and B pairs. It could help the author by automatically providing a template of all the required elements, something like this: <foo> <a></a> <b></b> </foo> During editing, an "insert element" command would offer a list of only syntactically valid element at the point of the cursor. Additionally, the DTD can specify that elements have attributes and a good editor could provide a fill-out form style interface for setting the attributes. There are a couple special types of attributes, ID and IDREF, that are often used for cross referencing purposes. A good editor will keep a table of these handy for the user to consult, or when filling out an IDREF attribute, a list of valid IDs in the document could be supplied. All the information necessary to do this, and more, can be and should be gleaned from the DTD at runtime. HTML editors are almost universally hardwired to the elements defined in the HTML DTD and, consequently, are useless for other SGML document. An SGML editor, on the other hand, can handle any HTML document. In this sense, calling HTML a subset of SGML does make sense, but it is still a little misleading about the nature of SGML. For rendering, a style-sheet associates formatting with the element start and end tags. Since any given element may need different typographical treatment depending on the context (eg. a <p> inside a <li>, versus a <p> elsewhere) there must be a mechanism to select formatting rules based not only on the element, but is relation to other elements in the document. Cascading stylesheets (lightweight) and DSSSL (heavyweight) are both good candidates for the stylesheet role. -john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970514174011.311x-100000>