X M L

SGML is a far greater "language" than HTML which, in fact, is a "subset." And far greater functionality is made available. But, far from being available to everyone as HTML is, SGML c'n offer a very deep challenge even to programmers (you know, the fellows who write the browsers that process pages). But those programmers wanted to make browsers and other apps (for intra-, extra-, and Internet use) that could process, and be guided by, more complex documents than our HTML'd eLetters and reports, papers, and, in general, "pages" (really scrolls because pages come into it only in cut stacks for printing on paper.

XML would seem to imply "extended" and that's how I'm going to use the term in my faked up version. But actually it means "extensible." Its chief feature is that a programmer can add tag sets, write an application to process those tag sets, and, thereby, allow the writer of the document to have specific functionality employed by the application. There are, then, Data Type Definitions for the tags and these can be integrated with cascading style sheets and other "adjunct documents" to allow very high powered goings on for those with proprietary applications and systems and their customers.

All that is fascinating to an amateur programmer and semi-pro writer like m'self. But for most cyberseafarers (staying close to the beach, they got tagged "surfers"), there's nothing much to do with any of that except be dazzled by whatever gets stuck into the cyber-Macey's window.

Why would I have an XML menu in eWriter?!

To begin with, a writer working with XML documents in a context where it's used will use eWriter as always. The particular tag sets will be in boilerplate cylinders as will the different syntax of style sheets, DTD sheets, and whatever other tools be. The only way to have a menu would be to have all the items "set by the writer" as some items on the File and Tools menus. And there would never be enough slots so cylinders would be needed anyway.

I'm thinking about the spirit that led some folks to XML, somewhere between HTML and SGML. It's a little different than the spirit that's pushed the envelope of HTML through versions. The push came from a desire to attach styles, for instance, to "semantic" elements, and along the same line to wrap things into "production numbers" (Broadway term).

Everyhuman's eTypewriter can't be anything very proprietary or it dissolves like a dream on waking. It's a "duplex" typewriter, the two pieces at the two ends of an email worm hole in cyberspace. The typing end is any text editor (with very good ones available without cost). And the screening / printing end is just about any web browser, with even top of the line browsers ranging from free to maybe fifty bucks. Of course, if you know that specific readers have very powerful ones or even those coming up with XML or other SGML magics built in, you c'n use whatever you have access to. But, in general, I've set everything in sight in eWriter to work with NN2.x, the Mosaic that (according to books out then) had those NN-extensions (like frames), and IE3 (after beta versions) which pretty well caught up and began the "race" (now ending in NN4 and IE4 which are bloatware and full of problems).

But, I wanted to serve, for Everyhuman, that spirit that wants production numbers, compact, special semantically focused "productivity tools."

My XML is not really "extensible" in any way, but it's not really "extended," either. It's ways to make life easier by wrapping up a task.

Take the first item on the menu. It's "@Address to Mailto" and that says, of course, that it'll take an email address typed into the text and make a mailto link at that location. That's what a browser using XML to display an XML document on the screen or printer does. ...if a tag in the agreed upon tag set directed it.

I was reading an article about XML, and this was an example used by the author, Dale Dougherty. Uhmm, I thought. In eWriter I'd come to an email address while writing (or typing) and think, I want that link. So I'd hit Ctrl+NumPad1 to set up an anchor. I'd get two Input dialogs in sequence (typing in HTML tags as if punctuation like commas and such) and I'd type the address twice, the first time with "mailto:" in front of it, inside the same quotes (which the typewriter provides). Not much of a job and set up not to slow even spontaneous writing too much. An HTML "editor" would just put an end to the writing with a full dialog and parameters to think about. But typing something twice isn't too good an idea. The anchor machine has to be set up for different texts in the two locations.

Now, in my XML approach, Alt+X,m (for "mail") gets a single input dialog, and it does the two typings and builds the anchor. Two key strokes or mouse clicks and type the address once. This is how punctuation should work. And if you write a letter or report or list with a dozen addresses in it and you want each to be a link ...you will appreciate this bit of batch typing.

It's gathered around a "semantic" element, an address as an address, not as a string. In the documents we c'n write we can't have the document do that, and we've got to do it each time we want the result. But that's not bad. If you use any Find / Replace dialog in any software, and hit Replace All, you'll be asked to confirm each unless you hit a second All. And often you'll value being able to skip a false hit. In the XML document, I'm sure you'll have to get tags put in some way. Not every string with an @ in it c'n be put up in such a link, though @ and some periods scattered would get close on simple recognition. Filtering has got to be for tags, not content.

The second item is "URL to Link" and works the same way as the @Address. It's a little smarter. If the address starts with "ftp.", you get an ftp link. Otherwise, you get an http link. If you want gopher or something, you'll have to massage it manually, replace the "http" with "gopher."

The next two are "Image to Figure" and "text to figure." I can illustrate these here. But I don't want to put any big .gif or .jpg files into eWriter.zip, though, so the image will be only that tiny "broken picture" element that the browsers put up when they can't find the image. To see the images of various sizes and how they suggest you massage the code (spacing and all) just bring in things you have on hand. If you want some .jpgs to use, you c'n get pictures of my apps by right clicking on them at www.ccnet.com/~acorioso/ac_apps.htm. In fact, on that page, the picture of PathFinder is a good size, so I'll write the code here for it. (Or have the XML routine write it).

Text to Figure does an interesting thing. You've seen the magnified excerpts from text in a space or box in the center of the page or a column. The text skinnies up with columnar phrasing. It can be set in italics or be a different color than the surrounding text. The XML item will ask about type size and color. You'll have to massage italics in.

There are other XML items and I suggest that you try them out. Each item, when clicked, brings up a plaque that tells you how to use it. After you've plugged in parameters (do not be intimidated, params are just punctuation marks), you may get another plaque telling you how to massage the "packet" just placed into your text to get the effect you want

I've just added an item to make a "stack of buttons" and this might seem a little far away from what you expect in an eTypewriter. Most uses of buttons (with Javascript scripts) do not produce material that you can print, and printed letters, papers, and such are the usual end result. But as we move into the ephemeral and virtual future ...we can't throw away special reading and research done only on screen. And that's not only for multimedia, but even material for reading. You can use buttons to jump to end notes. and those endnotes will print at the end of the document. But you can also use buttons for popup "footnotes" (which I guess will be "popnotes" in the evolving jargon). And those will not print anywhere, though you can read them by View Source and, of course, print that source (which is the "manuscript" version of the web-page).

To see the use of a stack of buttons, put reader.htm in your browser (from eWriter, so you have the source) and note the "button index" on the left. Pull that file (toc.htm) into eWriter (or view Source). In the HEAD section, you see a Javascript script with a function GetPage(). Look down at the stack of buttons and you'll see that each button calls GetPage with a particular .htm file as the parameter. Click the button and you get that page in the main panel on the left. You can "adapt" this reader to be a book shell for any group of .htm files you want to collect into a book. The "reader" c'n be regarded as a "template" that you can use. It involves four files: reader.htm to set up the framework, toc.htm, the live index, top.htm, the "cover," and intro.htm, the "introduction" for the book that should come up when the book is opened.

Gene Fowler
January, 1998