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.
|> I'm
|> still struggling with how much of this information in stored
|> in the SGML database, and how much is more appropriately
|> maintained externally.
|>
|> What do you think, SGML persons?
[...]
Joyce,
Since, strictly speaking, this isn't about tech writing, I'm replying by
email.
In the DTD's you use to define document components, the tag sets should
describe the contents of the information the elements contain. Larger
divisions should describe the structures the smaller elements make
depending on your delivery medium (like ref-chapter, or
online-procedure). Ideally, all structural elements are composed of
compatible content elements, making your information reusable across
different delivery media.
Anything related to format should be expressed within element attribute
values. Anything that describes classes or categories of metadata should
be held externally and associated with configurations or groupings of
elements in the database.
The SGML database can contain any or all of these things. Ideally, it
should contain any objects you want to (or need to) manage. You
obviously want to manage the tagged SGML document fragments in order to
control versioning, to use in various configurations, to hold as a
repository against which you run queries, and to group for metadata
associations.
If the rules for the containment relationships are complicated enough,
keeping them updated through releases and versions could be complicated
enough to require direct management as SGML document instances held in
your database as objects. Some prefer other structures to hold this kind
of information. That's your call. A lot of your decision here will be
based on the tools you have to work with.
Depending on your database tools, you *should* be able to associate
metadata with categories of objects. Ideally, you should be able to
express a category as some grouping, either directly (as in a list of
entities) or in a virtual sense (say as the result of query expression).
These associations of metadata with document fragment groupings *can* be
held as SGML document instances, but probably will be more useful to you
as other structures accessible to your database tools.
If you are creating groupings based on attribute values for small
elements for the purpose of associating metadata with SGML document
instances, you might want to reconsider your database design. ;-)
In short, I suggest: keep things in your database that you want to
manage, manipulate, or associate with metadata. Keep everything else out
of your database, but still accessible to the tools. Tag for content
small, structure medium, and document type large, and use attributes for
format information - but sparingly.
Your mileage may vary. Every problem has the potential to inspire many
different and equally viable solutions - I'm sure I don't know enough
about what you are asking to have answered in full consideration of all
the factors. However, I hope this helps.
--
Len Olszewski Project Manager, SGML Technology Group
saslpo -at- unx -dot- sas -dot- com Publication Technologies Development Department
919-677-8000 x7487 SAS Institute, SAS Campus Drive, Cary, NC 27513
------"Speaking from SAS, and not for SAS."------
