The browser not only screens or prints that interface copy, which it produces under the tag-borne directions in the engine or manuscript copy, but it will show you the engine under a menu item called something like View Source. The older punctuation, the commas, periods and semicolns, are the same in both copies. But to see the driving tags, our new punctuation, you have to read the engine copy. There will even be information in the engine copy only, the content of popup boxes, which won't be printed, and the content of comments that won't be printed or screened. A "reading in depth," then, can involve reading engine and interface copies ...and that leads to "understanding engines" which makes you a more able writer.

From HTML to XML: It's not only browsers or displayers that read HTML engines. To a limited extent applications that read HTML can do things with the items marked. HTML is, however, mainly for display on the web. Doing much other than display is not very inviting, and even display is fairly limited. Linking is limited. Just about anything you can think of is limited. So, ...folks decided it was time for a subset (rather than a production of) SGML.

It's called XML, "extensible" markup language. What matters here is that with XML, you will be able to "define" tags and the XML-equipped browser will recognize your tags. Then, using XSL, you'll create a "style sheet" that tells the browser how to display (mainly) whatever appears within <TAG>...</TAG> (in place of the three dots).

Your tag can tell anybody (or any browser) what the meaning of that content is, and the display can make sense. Suppose you're doing a report, or a page, and there are a lot of dates in the text. And many of those dates, but not all dates in the text, are hire-dates of employees. And you'd like those to be, say, in green italics so they stand out. You might have employee names also green italics to match, but we'll keep this simple, just the dates.

In XML, you'd define a tag-set. <hire-date>...</hire-date>. In the style sheet, you'd define anything inside this pair of tags that form a "semantic element" (you and your readers know what a hire-date is), to be displayed in green italics.

A little eTypewriter magic: Suppose we wanted to do this now. How do we go about it. Well, we'll use those "loaded revolver cylinder" boilerplate sets that we export to and import from bplates.set (an ini-file). you could have this in a boilerplate: <FONT COLOR="Green"><I></I></FONT>. If this was a menu item, the cursor would be set in the middle for your typing. And if you had selected text, the tags might surround it for you. As it is, you'll have to move the cursor into the middle and maybe split the line, give yourself an empty to type in. Still, a whole lot of typing only has to be done once (to set the boilerplate).

No magic yet? The browsers have always had a very nice behavior. If they don't recognize a tag. they ignore it. So we can surround the above tags (in our boilerplate) with <hire-date>...</hire-date>. If your reader doesn't remember why some dates are green italics, (or missed the meeting), he or she c'n simply read the engine, locate one, read the ID-tag, and be up to speed. That's some heavy-duty information available only through that "doubled" reading. Now, the reader knows that all green, italic dates are hire dates.

All right, it's not all that magical. But it does let us display elements according to what the content means. And it allows the reader who isn't in on the particular meaning to read in the engine to find out. That, of course, requires adding in the ID-tags. In XML you'd have to in order to get the effect, but magicians have to do things deliberately (and slyly, of course).

And mini-templates: If you want to use ID-tags for chunks of documents, you can build such a chunk and store it in a .tpt file. Then, use template load to bring that into an editor window as a New File, but never do a Save from there. Either fill it and, then, move it into a document in another window, or move it right away and fill it in, throwing away the separate copy in either case.

Actually, for, say, an Intranet's group of writers and readers, you can form full document templates (.tpt files) and have virtual XML. Your style sheet can be in a style comment at the top of every document for reference by writer or reader. In that comment, you define the ID-tags to be used in the boilerplate. Our current crop of browsers, at least, will ignore the ID-tags. I'm guessing that early XML browsers will note the tags but, not having their kind of style sheet, won't do anything to their content but will read the contained HTML tags.

Suppose we had wanted an <employee-name> tag like our <hire-date> tag. It's nice to have a fully meaningful tag right on the spot. But, in this case we can use a "generalized" tag like, say, <emp-data> and define it in that style comment:

<!-- STYLE:
<emp-data>:
name= employee-name
date= hire-date
...
STYLE -->

If the boilerplate is applied to a name, that name is an employee's name. If it is applied to a date, that date is an employee's hire date and not any other date that might be relevant in an employee's record.

The style comment can even contain the "loaded revolver cylinders" of boilerplate that can be moved to the writer's local bplates.set for import into the live boilerplate set. [See bplates.htm or "Boilerplate" in the eManual -- reader.htm.]

In any case, ...what's important is the idea of these ID-tags that our browsers will ignore but that a "doubled" reading c'n make available to any reader who wonders why the element is displayed as it is, what meaning that display carries. And the "style sheet" is the normal HTML tags contained in the element defined by the ID-tags. What's important about the XML/XSL concept, so far as punctuation is concerned, is "tagging concepts," tagging to mark meanings (semantic content). The display of materials is meaning-driven. There's no reason to wait until Microsoft or somebody else wants to sell us something to begin using this sort of "intelligent display."

Gene Fowler
April, 1998