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: Objects that share a fate From:"Sella Rush" <sellar -at- mail -dot- apptechsys -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 6 Jun 2000 15:07:48 -0700
I agree with using standard terminology unless it implies characteristics
that don't fit the situation. The parent/child analogy is a good one
because everyone can relate to it on some level. And it is used in several
different contexts, the programming concept of inheritance being only one of
them.
Note: The parent/child analogy is not just a database term--in general, it
is used to convey a sense of relationship. Quite often it is used with data
trees (hierarchical displays) to describe the relationships among individual
items in the tree. When you open up Windows Explorer you get trees of
directories, and these can be described as parents and children.
Roles: Do your--I'll use a generic term--items always take on a single
role, regardless of the context in which you're talking about them? One of
the advantages of "parent/child" over, say, "primary/secondary", is that it
is quite understandable to talk about a parent who is also a child with a
parent, rather than a primary that is secondary to another primary. (Here's
where we're getting into Martha's "cascade" effect!) So if in your case an
item's *role* can change, and this characteristic is relevant to your
discussion, the parent/child might be the best choice.
If a primary is always a primary and never secondary, then there are other
analogies you can turn to.other options might be:
host--dependent
("parasite" probably wouldn't work for you)
root--stem/branch/leaf/whatever
key--link
We use this fairly generic terminology in our product, which displays data
in hierarchical arrays. Each array has a single key and one or more links.
(but within the array, particularly when we're talking about the visual
representation of the array, we talk about parents and children)
primary/main
secondary/subsidiary
Thanks for this thread--it's made me think about the terminology for these
concepts, which are very important to what I'm doing!
Sella Rush mailto:sellar -at- apptechsys -dot- com
Applied Technical Systems (ATS)
Silverdale, Washington
Developers of the CCM Database
Demo: www.apptechsys.com/demo
