TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Have I missed the point? or are we on a different wavelength?
Unless I am mistaken, the discussion about SGML has rather hung on the idea of
the technology being an impediment. Please correct me if I'm wrong, but my
understanding of the wider context was this:
- back in the early 1980's AECMA (the europeean association of aerospace
equipment manufacturers) started to realise that modern aerospace projects
had become so large, so expensive, and so politically sensitive that no
single country dared to consider undertaking such projects on its own
- cooperation across international borders (especially when the major
assemblies all had to be fitted together to make one aircraft) meant that
there *had* to be some means of (electronically) exchanging (engineering)
data.
This gave rise, in 1987, to AECMA specification 2000M (Integrated Data
Processing for Military Equipment) and AECMA specification 1000D (Air
Vehicle Technical Publications using a Common Source Database).
- Working in parallel, the Department of Defense realised that something had
to be done at their end to try and stem the flow of information and impose
some kind of order on the chaos (current estimates I have seen are in excess
of 1 000 000 pages of changed documentation every year, not counting new
publications). Tieing in some of the 'loose ends' of ILS (Integrated
Logistics Support), which forced defense suppliers to standardise on their
supply and component coding, the DoD drafted their so-called 'CALS
(Computer Assisted Logistics Support) initiative. CALS laid down certain
(well-known, but ill-defined) standards for encoding information, and one of
these was SGML. (As you all know SGML has its own history, and I won't
discuss that for now.)
For many companies SGML is 'nice' but not necessary, although it *can* have
its uses. (My 'sources' inform me that they are using SGML in Germany to code
ASCII text news broadcast for satellite transmission and display on domestic
TV screens, while here in the Netherlands, Kluwer (a local publishing giant)
encoded the new book of civil law into SGML so that they could produce about
30 different books on it, each for a different set of readers). The key to all
this is *RE-USE* of the same material for different purposes.
As far as this aspect is concerned, CALS/SGML is an *intermediate* stage
towards a 'vision' of the future of universally accessible information. The
'next' initiatives (of which few have heard very much as yet - you will) are
CITIS (Contractor Integrated Technical Information Service) and IETMDB
(Interchange of Electronic Manufacturing DataBases).
Eventually (so goes the dream), some un-named technician in the field will be
able to tap a few keys on his personal maintenance computer (assuming we still
have keyboards by then) and be able to access the technical information he
needs from any defense supplier in the world to find the information he needs.
To make this possible, a complete re-think is needed. And, as I had understood
it, this means that we have to change the way we consider our technical
documentation. We have to stop thinking in terms of 'documents' and start
thinking in terms of 'information'. Information is then built up of three
things (I think of them as 'layers'). The first is the content (text &
graphics), the second is the structure (sometimes referred to as the 'style')
which defines what & where, and the third is form (layout, appearance, etc.).
SGML covers (part of) the first layer (I haven't yet seen a method of encoding
text to cover the sort of content description that would accommodate
the kind of database storage and retrieval that I think would be required to
provide universally transportable chunks of text), the second is covered by
the SGML DTD (document type definition), and the third is covered by the FOSI
(I can't remember offhand what it stands for).
The bottom line is this: someone, somewhere, had a 'vision'. What we have now
is just a few steps along the path to turning that vision into a reality. When
we stumble along the way (as we are bound to with anything really new), we
should not complain too loudly about the obstacles along the way. And we
certainly shouldn't complain if we are having problems when we haven't even
realised where we are going.
Yes, the technology can be confusing (it took me several years to work it all
out to my satisfaction). But does it 'interfere' - IMHO a resounding NO. Maybe
it interferes with what you are doing, but should you *really* be worrying
about it? and, given the wider context of the 'bigger picture', isn't it worth
a little discomfort now for the greater gain in the future?
Simon ("shoot me if you wish, but I think what I say").
================================ Unclassified ==================================
Simon JJ North BA EngTech FISTC Consultant, Communication of
north -at- hgl -dot- signaal -dot- nl Technical Information
Tel: (+31)-(0)74-483533 (work) Quality Group
(+31)-(0)5490-28623 (home) Software Research & Development
-------------------------------- Hollandse Signaalapparaten BV
The opinions expressed do not PO Box 42, 7550 GD Hengelo
represent those of my employer. The Netherlands.
================================ Unclassified ==================================
