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.
Subject:Re: Why SGML From:Simon North <snorth -at- TEDOPRES -dot- NL> Date:Tue, 19 Dec 1995 09:36:26 GMT
In his article Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM> said:
> Another good reason is electronic interchange of information in standard
> ASCII formats.
Basically comes under the headings of re-use and re-purposing. Just as
translation does.
The database tools aren't (quite) there yet, but they will be soon. The
soon-to-be-published revision of the DSSSL standard, tied in to the
revision of the HyTime standard in which the corrigendum appears to adopt
the same conceptual 'grove' model of an SGML element hierarchy is (IMHO)
going to set things on their head and greatly facilitate the development
of the software we so sorely need ...
Once we're on the subject, there _is_ another aspect of SGML which serves
as a good reason for adopting it - but is also the greatest obstacle to
adopting it. SGML is about _information_, not just documents. It is a very
sophisticated technology (?) which really needs a sophisticated user to make
full use of it. Integral to its use is an analysis of exactly what information
you produce and use; where, when, what for, why ... it more or less requires
a full-blown 'information strategy'. The most sensible approach to this is the
same kind of process methodology as applied for ISO 9000, TQM and the
CMM/SPICE. These are hard things to justify, but the adoption of SGML within
this context _can_ make some of the benefits more visible. SGML forces you to
examine your information management/production as an _engineering_process_
which,
I content, is a GOOD THING (it's also my specialisation, which is why my job
title
is "documentation engineer").
