Re: Structure vs. Substance?

Subject: Re: Structure vs. Substance?
From: "Tim Altom" <taltom -at- simplywritten -dot- com>
To: "Tracy Boyington" <tracy_boyington -at- okvotech -dot- org>, "TechDoc List" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 12 Jun 2000 17:20:02 -0500

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

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."
Check our Web site for the upcoming Clustar class info

> > You're right, and oddly enough that structure would be sufficient for a
> > small project. A better approach, with still a high level of
> > 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
> 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
> your reason for using this example?

Re: Structure vs. Substance?: From: Tim Altom

Previous by Author: Re: Structure vs. Substance?
Next by Author: Re: Chicken and the Egg
Previous by Thread: Re: Structure vs. Substance?
Next by Thread: Re: Structure vs. Substance?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads