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.
Ah, but this is not content. Content must be about something specific. This
is actually metadata, or in this case "metacontent": a description of a type
of content. This outline could be used for everything from a swingset to a
tugboat. Databases are built the same way. They may have fields for "First
Name", "Last Name", and whatnot, but this is only metadata, not data. Think
of content as being data. When you talk *about* the data, you've moved up at
least one level of abstraction, and you're no longer dealing directly with
the data.
If you've worked with HTML, you know what metacontent is. Each tag is a kind
of metacontent. The tag itself gives no hint as to what the text or table or
graphic is going to be. It merely says "here's something categorized as a
<p>". Is the <p> tag content? No. You could, in fact, eliminate everything
between the tags in an HTML page and have a perfectly legitimate HTML page
left, with nothing being displayed. What you now have is an abstraction, not
content.
This is a difference hard for many writers to distinguish. However, database
designers, SGML/XML DTD developers, engineers, OOP programmers, and others
will know the concept well. All can develop "shells" that have no content,
but can be tested and evaluated nonetheless. The example I used (reprinted
below) is but one general document structure, although it has a wide
application space.
The concept of reusable structures like Clustar depends on the general truth
that products resemble one another on an abstract level, and can have an
abstract structure applied to their documentation. The more abstract the
structure, the wider the application, but the more decisions that have to be
made before the structure is ready for prime time. DocBook is highly
abstract and complex, making it work almost everywhere. Clustar is
considerably simpler, so with a correspondingly smaller application space
but a faster time to implementation.
In our minds, there is no chicken-and-egg problem; structure comes first,
followed by content, then by appearance (layout). Structure is designed to
be global; content is designed to be modular; layout is device-dependent.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
>
> > You're right, and oddly enough that structure would be sufficient for a
> > small project. A better approach, with still a high level of
abstraction,
> > might be:
> >
> > I. Assembly
> > A. Assembly of unit
> > 1. Steps
> > 2. Reference information
> > B. Assembly of unit
> > 1. Steps
> > 2. Reference information
> > C. Assembly of unit
> > 1. Steps
> > 2. Reference information
> > 2. Operation
> > A. Control functions
> > 1. Control
> > 2. Control
> > B. Setup
>
> But Tim, this has content. Not much content, and really only a description
of
> what the content will be, but in order to get this far you already know
that you
> are writing about an object that is assembled and operated and has
controls. Are
> you assuming this is the "default" content for all TWs, or do I
misunderstand
> your reason for using this example?
