Date: Wed, 14 May 1997 17:29:39 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: John Fieber <jfieber@indiana.edu> 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: <199705150029.RAA22701@rah.star-gate.com> In-Reply-To: Your message of "Wed, 14 May 1997 18:35:21 CDT." <Pine.BSF.3.96.970514174011.311x-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
First off , this is a cool session 8) when you get a chance, check out http://rah.star-gate.com/languages.html it discusses the theory of their meta language thingy. Just fire off an e-mail to the amaya asking them about how difficult will it be for Thot to support SGML. Have fun, Amancio >From The Desk Of John Fieber : > 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?199705150029.RAA22701>