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.
Yes, it could. That does not mean this outline applies to every document, which
seems to be what you're implying. This outline could not be used for what I
write. And my outline could not be used for what you write. Our structures are
based on *what we know the content will be* even if we don't have the actual
content yet. If I asked you to document a procedure you could have to come up
with a different outline.
> Databases are built the same way. They may have fields for "First
> Name", "Last Name", and whatnot, but this is only metadata, not data.
But when you're on that metadata level, you still know you'll be entering names.
That's why you created fields called "first name" and "last name." So even if
you don't have the content, you know what it's going to be. You know it's going
to be personal information. That's what I mean by knowing what the content will
be -- maybe we're not using the same definition.
> 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 would have been a better example than the outline (in fact, it's a lot like
my example of the empty outline), but it's still not a good description of
structure IMHO. Simply saying "text will go here" is not structure to me.
> 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.
But Tim, it's not completely "general." It only applies to one specific type of
document -- one that describes a product that is assembled and operated. And
since you must know what type of document you need before you can develop this
shell, you must have an idea of the content (even if that idea is only "all
about foo.") I've used databases long enough to understand the concept of empty
fields, but you still have to know what you'll be putting into your database in
order to design it.
> > > 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
--
======================================================
Tracy Boyington mailto:tracy_boyington -at- okvotech -dot- org
Oklahoma Department of Career and Technology Education
Stillwater, Oklahoma http://www.okvotech.org/cimc
======================================================
