|
The following is my user's perspective on using
XML with the Arbortext Epic XML editing environment. -- By Andreas
Ramos
There's tremendous interest in XML. It's been around for a number
of years, but it was always a "coming soon to a theater near
you" kind of thing. We had FrameMaker or Word, and both of
those could produce documentation from concept-to-print. One could
do everything in one platform (for example, write in Word on PC,
output to PDF, and view a PDF on a PC.) One really didn't need another
solution, nor was there much need for cross-platform solutions.
(companies and their users either live on Windows or on UNIX, and
in most cases, they aren't obligated to use the other platform.)
In the last few years, we've seen an extreme proliferation of platforms.
Windows and UNIX are no longer the only platforms. We now have Palm
PDAs (Palm, Handspring, Sony Cleo) and many other kinds of PDAs
(go into any office store and you'll see a dozen different types
of PDAs,) dozens of cell phones, WebTV, Tivo, other TV devices,
and so on. All of these devices are linkable.
Documentation now needs to be able to output content to multiple
devices with radically different OS (such as a Palm devices or WAP
cell phones) and radically different screens (19" color screens
vs a 3" (diagonal) PDA black-and-white screen.) All of this
can be delivered via the web or wireless as well.
So... XML's long-awaited problem has finally arrived: multiple
interlinked platforms, for which XML is the solution. If we want
an XML mission statement: Write a single text file and have it automatically
outputted in different formats for different devices and distribute
it automatically via web or wireless.
For corporate documentation, the end of Frame and Word is in sight.
Just as HTML became a standard (for the past few years at work,
I write nearly everything in only XML or HTML,) XML will become
the standard format for documentation. XML has other advantages:
it is license-free (no company owns it,) platform-independant (it
runs on all systems,) and it is easy to develop.
I see a few hands, so let's take some questions.
What about business cases, localization, content re-use, and connection
to applications or websites?
At our startup...
- Localization is theory at the moment. I doubt most of the
localization bureaus have XML installed. It's too expensive and
too complicated.
- Content re-use: we do this quite a bit. With a few tags,
we can output the same file in personalized versions to various
OEMs, staff, etc.
- Connection to applications: This is the really different thing about
XML. At other companies, I ran tech pubs basically as a standalone
group; we had our own tools, etc. But with XML, my file is just
another engineering file. I use CVS to check out my files from the
engineering server. I edit the files with Epic. When I finish, I
check the file with CVS back into the engineering server. At night,
the build is done and my file is processed by the XML converters
into the various formats: HTML, PDFs, WinHelp files, etc. These
are then sent to various clients, internal users, and so on. XML
lets us create versions for various OEMs; each gets their version
with their logo and corp information. XML automates the production
and distribution of documentation. Everyone has the "release-of-the-day",
or as someone else called it, a rolling release. With print, you
had a two-three month lead time; with XML, you can output as often
as you like: daily outputs of docs via wireless onto 300 million
cell phones and PDAs.
What about costs, ROI (return on investment,) writer productivity,
and so on?
- You never hear about this in a sales presentation because they
don't want to scare you. The ArborText Epic XML authoring environment
is around $50,000. (We did the server installation ourselves and
saved about $10,000.)
- XML also requires a number of highly-skilled people in the process.
An XML solution includes XML, XSL (the layout language,) FOS (the
converters for various formats,) servers, and so on.) It took an
XML-experienced fellow more than two months to get the setup to
actually work, and that was with generous help from several engineers.
Much of the work has to be done inhouse. ArborText is not helpful.
- As for productivity: well… as an editor, Epic is primitive,
poorly documented, and poorly supported. It's little better than
NotePad. Any expert Frame or Word writer will be astounded at how
many essential writer's tools are missing. ArborText gets away with
this because they have little competition.
As XML becomes more widespread, better tools will be written and
the price will collapse. Either MacroMedia/Allaire, Microsoft, or
similar will create an XML authoring environment.
What is the experience with semantic taxonomies? Part of the power
of SGML/XML is supposed to be content semantics.
- XML stands for eXtensible Markup Language. In theory, you can make
up your own tags. But that's just theory. In reality, every industry
council (aerospace, pharmaceuticals, trucking, etc.) has XML committees
and each one has published its own collection of XML tags, which
are specific to that industry.
- For computering, we use the DocBook set of tags. These are some
300 tags, of which 80% you'll never see. In practice, we use about
20-30 tags, and of these, I use perhaps 15 for nearly 98% of my
docs. It's like HTML, where you use just a few tags for nearly everything.
- Content semantics is mostly theory at our startup. We use XML mostly
for layout tagging. The future of this is in price or item tagging,
but that would be an issue for pricing and catalog management departments.
It's not really a matter for computer documentation.
What about control over layout on various platforms?
-
The text "flows into the container." Which means that
section headings can appear at the bottom of a page, an image can
be separated from its descriptive paragraph, and so on. In theory,
this can be controlled, but we haven't figured out how to do this,
and since we won't print our docs, we don't really bothering about
this. ArborText themselves can't figure out how to do this. Their
own documentation is a layout mess.
What does XML means to writers? What does it mean for our profession?
For the last 15 years, tech pubs for me was a draft-to-print process.
I did the text, the layout, the production, worked with print vendors,
supervised the book printing, and so on. As technical writers, much
of our value is in our collection of skills in creating printed
books.
XML sales critters will say "XML allows you to be your Inner
Writer!" But folks, to be honest here, we're not highly paid
for our Inner Writer. We're highly paid for our Inner Graphics Dude,
our Inner Print Vendor Relations Person, and our Inner Nerd who
can use 10 different tools and two dozen undocumented kludges to
produce a printed manual.
Some people may say that our real skill is SME (Subject Matter
Expertise,) such as SQL, telecoms, VoIP, or whatever. Yes, there's
a value in that, but our real value is our production skills: we
can produce and deliver books.
Look, to put it differently, we were the chef at a little French
restaurant where we could whip up hors d'ouvres, make turtle soup
from scratch, prepare the seared Atlantic salmon, select the perfect
wines, follow up with a perfect handmade creme brulee, train the
waiters, set the flower arrangements, pick the music for the violins,
and so on. We did it all, and no one else could do it.
With XML, we just chop lettuce, dump it into the Happy Clown, and
it spits out a burger. We don't even get to make fries.
At the moment, very few people know how to use XML, and there's
demand for it, but from a writer's point of view, it's easier to
use than HTML, and we all know how well THAT is paid. For the writer,
XML requires very few skills, and that may lead to a drop in income.
Small shops may continue to ignore XML, either because they are
reluctant to spend $50,000, or they don't need to output to ten
devices simultaneously. But I'd guess that most mid-sized and larger
companies will switch to XML in the next few years because it allows
better/cheaper/faster distribution of content.
All of this is my experience. Your mileage may vary. If you're
using XML, write to me about XML.
Here's a writer's point-of-view on using the Arbortext Epic editor
to create XML.
|
