Re: XML Examples? (much too long)

[Dan Brinegar <vr2link -at- VR2LINK -dot- COM>]

Despite the length of this message, it is not a rant (now what *was* the
limit on posting size?  ;-)

The discussion amongst Eric & Deb and Mark has been fascinating and
enlightening... but as far as I can tell, the following question has not
been answered --

On  Wed, 15 Apr 1998 14:08:33 +0200, Alessandro Bottoni <bottoni -at- CADLAB -dot- IT>
wrote:

>I'm very curious about XML and I'm following the "XML &Technical Writers
>..." discussion with great interest. In the last two weeks, I read a lot of
>interesting articles regarding XML. Despite this, I cannot figure out how
>XML can help us in the everyday work.

I think XML, and structured publishing in general (or any tools and
methodologies we use), should be about

  * helping build quality into our development process (whatever measures
of quality we care to use)...

  * which should help information developers reduce the effort needed to
document complex systems...

  * which makes it possible for techwhirlers, as part of the product team,
to *add value* UP FRONT, instead of being a "backend burden" to middle
management or a "nuisance" to developers/engineers.

So how can XML help us in our everyday work as techwriters?

Well, for the longest time, many of us were far out of the development loop
(usually at the bitter, burdensome end of it), concentrating on change
pages and the lead time required to revise and distribute a paper bookset:
the World Wide Web gave us a way to bypass at least the long lead times
necessary to generate paper; suddenly, almost anyone had the ability to
publish fast, fast, fast (I'm not sure who it was that said the competition
now was between the engineer/programmer who could update a webpage about
the latest changes to TigerSoft'97 and the tech pubs departments could even
begin think about starting on the revisions for the paper, PDF, and HTML
versions of the new manual).

This speed also made things even *more* difficult when it came to
*controlling* the structure and format of our publications: reusing them
can get very tough (which version of Word was this done in? How can I get
this out of PDF? Why won't these old Interleaf docs import into Frame?
How-come Worderfect doesn't work on these new PCs?), rewriting and
re-purposing whatever the engineers threw out there while we weren't
looking can be a nightmare, and trying to do the same old things with brand
new tools can make for a truly dogmatic and unworkable pubs process --
guaranteeing that we get even further out of the development loop.

As long as it stays difficult to completely eliminate paper, or to get
"obvious products" built that don't need techsupport, documentation,
trainers *OR* middle managers, we'll need good tools and methodologies.

XML looks like a tool/methodology that help us as info developers get our
documentation process more structured and more streamlined.

Alessandro, the first place I'd send anyone with an interest in XML is to
longtime fellow TECHWR-Ler Simon North's page:

http://www.xs4all.nl/~sintac/books.html

... where you can find almost anything you'd wanna know about it; enough,
even, to tapdance your way thru an interview for a position developing with
XML (no, I didn't get the job, but that was probably due to things better
discussed in another thread ;-)...

I was once-upon-a-time a structured publishing True Believer: I don't know
if I still am, although it seems that XML is the best prospect for meeting
the ideal of genuinely useable/reuseable/navigable information.

I wrote the following review on the first book published about XML a while
back; I see now, after the recent discussions, that I made a lot of
assumptions about who-could-possibly-be-interested-in-this-stuff. It's
possible that I wasn't thinking far-enough "out of the box" in that I was
still concentrating on the "legacy bookset" problem that's burned out many
a techwhirler -- in the interview I spoke of, the pubs manager was excited
about the XML project because the company didn't *have* a legacy bookset:
they were starting from scratch (and my worry was that they were going to
go ahead and *build* a legacy bookset, only with new tools) -- I think it's
possible that I just-can't-think-of what we can really do with XML: I was
certainly wrong about what techwriters were going to end up doing with the
World Wide Web (same thing techwriters should always do: try to take over
the world!).

"Presenting XML" by Richard Light (with Simon North and Charles A.
Allen) sams.net $24.99

Reviewed by Dan Brinegar
-------------------------

Sams.net and Richard Light have done the first book on the first really
promising development in structured publishing since the advent of the
web itself. This $24.99 book, co-written by the leading developers and
users of  the * Extensible Markup Language*, or XML standard offers
a useful headstart on the concepts, details, and impact of structured
web presentation for managers and developers alike.

XML is a new standards-based coding system which offers content
providers a robust method of distributing <i> structured, reusable</i>
chunks of information across the World Wide Web.

For many web developers and their employers, the promise of a
bright-shiny age of instantly accessible information over the web falls
flat on its face when they graduate from selling a few things or ideas
on a few web pages to dealing with the thousands (millions?) of pages of
critical information a large institution generates and needs to share
with itself, its suppliers or customers.

Getting that information distributed with "traditional" tools such as
straight HTML or Groupware apps is practically impossible without iron
discipline among the code-hogs and constant investment in new software,
equipment and communications links between workgroups.

Say you're working for an aircraft manufacturer, pharmaceutical company,
NASA or a museum of natural history and your bosses want everything
they've ever published put out on the web: there's no way you'd ever get
enough bodies to accurately code all that stuff by hand in HTML; and
much of the information would be out of date by the time you managed to
get everything converted to SGML or Groupware, onto CD, and out to the
users (Been there, tried that, got a nice keychain before they locked
the doors).

If every document, graphic, table, or part thereof were able to tell a
smart-enough browser what it is, what it's related to, where it fits in
the big picture, how old it is, *and* how to use it (*whew!*), users of
that information would have a *much* easier time of it (and so would the
developers).

That's been the goal of structured publishing since Vannevar Bush first
proposed an information appliance back in 1946.

Standard Generalized Markup Language, or SGML, has proven too complex
for all but the largest outfits, and unsuited to ready distribution over
the web; HTML (which "everybody knows" is a subset of SGML) has grown to
concentrate mostly on the "look" of a web page, and not its content (web
developers have been in kindof a hurry to get stuff out there, and the
way the ball bounced for explorers and navigators determined the
dazzling eye-candy uses of HTML -- that's where the money was during the
first spurt of web growth).

Now, however, with the "goldrush" money spent, the solid citizens of the
web (those companies and agencies and museums) *have* to get their stuff
out, and XML offers a way to do it.

The book (I was reviewing a book, right?), presented in four parts with
an appendix, glossary, index and a companion website will help
developers new to structured publishing, as well as old SGML hands come
to grips with the standard and understand the advantages of XML, the
rules behind the XML approach, integrating existing information (the
dreaded "Legacy Bookset") with the World Wide Web, and future
applications for XML within intranets or extranets (or both, or
something different -- now that it's easy to structure information and
make it useful, who knows? We might jsut break out of that box of
papers).

-----------------------------------------------------------
Dan BRINEGAR, CCDB Vr2Link
Performance S u p p o r t Svcs.
Phoenix, Arizona

"Denkst Du vielleicht, grad' an mich?
 Schriebe ich  eine Buch fuer Dich,
 von neun-und-neunzig DoeffProjekte,
 wie so'n schrechlich endung kommt..."