The responses to the query about the suitability of Word vs. WordPerfect
for preparing SGML seem to be falling into two threads: (1) a discussion
about various tools, such as WordPerfect 7.0 with its SGML support, or
MicroStar's Near and Far add-on to Word, and (2) a discussion about the
general principles of composition for application-independent descriptive
markup (a fancy way of saying what SGML is). Most posts are now leaning
towards (1); Nick Finke's very helpful remarks tend to (2). (1) is very
important, and this forum is an ideal place for us to get tips on what's
available. Then there's (2)....
In a sense, the "word processor" is misnamed: Word or WordPerfect is
really a WYSIWYG print engine: it's designed to take or create electronic
text and give you strong on-screen control of how it will look when
printed. (For those who don't recall the days of DOS and the Word
Processor wars of the 80's, WYSIWYG is "What You See Is What You Get.")
But this is only one way in which we want to automate the "processing" of
words, as becomes abundantly clear as we work to unchain ourselves from
the shackles of the application programs and take better advantage of the
computer's abilities to handle structured data. Shifting from a
perspective which centers on the _appearance_ of the text (such as a
well-designed layout can give you), to one which centers on the elements
and structures of the text itself as data (which is what descriptive
markup gives you), is what SGML is all about.
A strong WYSIWYG editor, which allows you to prettify your text without
concern for the underlying data structures, can actually be a hindrance to
clear and consistent descriptive markup if you don't yet see "through" the
screen into the code -- which is why those experienced with SGML will advise
you to use it only with chastity and forebearance. Think of it as a plain
ASCII editor, perhaps with some facilities for "styles" (which, as
pseudo-descriptive markup, are susceptible to mass conversion into SGML
tags). WordPerfect's relatively accessible formatting codes -- which
descend from a time when WordPerfect was the top-dog print engine for a
_line_ printer (remember dot matrix? daisy wheels?), and so has always
treated its data as a _stream_ -- make it somewhat more amenable than
Word to the logic of text-stream markup such as SGML, and so WP is ahead
by a few months in its support.
WordPerfect is not yet capable of true rules-based editing, however. (I
can't speak of Near and Far's support of Word, but I'd be very surprised
if it is either.) I refer to the capacity not only to check your tagging
against the DTD to see that your instance is valid (i.e. that your current
document checks out against the abstract model of what EAD allows), which
WP does nicely, but rather the active constraint of the whole editing
environment to offer you only the currently legal options. (As is, the
editor can tell you what's allowed, but it can't prevent you from doing
what's not.) This is a weakness of WordPerfect, in comparison to SoftQuad
Author/Editor, say, as an SGML creation tool, especially for those new to
the art of markup. This is perhaps made up for by the fact that it's a
more powerful tool for dealing with documents already created and
formatted and for -- who'd have thought? -- printing.
For those beginning with SGML and daunted by complex tag sets, the analogy
to HTML may be helpful (if you have experience with the web). Although
the tag set may be somewhat more elaborate, EAD will be more easily
applied to most finding aids than HTML would be, and will give you far
more functionality (but you've heard that). But many of the practical
problems of conversion will be the same and are handled the same way.
Where the analogy does _not_ help is in enabling us to shift our thinking
fully to the data-centered (versus presentation-centered) approach. (HTML
is still presentational encoding, as opposed to EAD.)
When we have truly native editing environments, not just add-ons to
popular print engines, creating a finding aid from scratch will be much
easier, if not such a fascinating challenge. It may look more like database
entry with forms, rather than the composition of "pages." While this won't
help us with the daunting problem of legacy conversion, it will
dramatically help with our re-education about these new/old information
structures. One of the most interesting thing for archivists will be to
look at all those old finding aids as themselves artifacts of information
technology and the mind-set(s) they reflect and enforce.
Wendell Piez
Center for Electronic Texts in the Humanities
|