| A file might be said to "contain" a symbolic name when it
has a tag like <appendix>(Table of Codes\codes_ap).
^^^^^^^^
symbolic name
BUT this has absolutely NOTHING to do with <include>,
<includes_file>, or LOGICAL names.
That is, logical names and symbolic names are two totally
disjoint concepts. They are not used interchangeably, they
never appear in the same place, and neither name can be used to
"access" the other.
So, this topic has NOTHING to do with symbolic names, it has
EVERYTHING to do with logical names.
WHen we use <INCLUDE>, <FIGURE_FILE>, etc tags in our SDML files
we have a choice of supplying the full file spec to reference the
file or of supplying a logical name. It's often convenient to
supply the logical name, since you may want to put the included
files off in another directory, and the directory may change over
time. So, instead of writing
<include>(USE$:[BFTSPLK.TABLES]table_of_codes.sdml)
instead we write:
<include>(code_table)
When the tag translator sees the shorter form of that <include>
tag it has to figure out how to find the file. It tries
doing a logical name translation (a VMS system service) on the
argument, and provided the logical name is defined in such a way
as to produce an "equivalence string" that is the full file spec,
the <include> will be successful in locating the file.
In this case the logical name, code_table, has to be defined in
a VMS logical name table as USE$:[BFTSPLK.TABLES]table_of_codes.sdml.
So, how do you make sure that the logical name is defined for this
<include> tag that may be buried off in the bowels of one of your SDML
files? Well, you can write yourself a note and tape it to your
terminal:
"Whenever you run DOCUMENT on the book, or the element, or
the second section in the element that does the include of
the table of codes, remember to execute the DEFINE command
before the DOCUMENT command, so that the logical for code_table
will be defined."
The alternative is to put an <includes_file> tag in the profile
that says the code_table logical name should be equated to the
equivalence string: USE$:[BFTSPLK.TABLES]table_of_codes.sdml.
<includes_file>(code_table\USE$:[BFTSPLK.TABLES]table_of_codes.sdml)
That will get processed during the bookbuild and will get repeated
during every element build (automatically). It means you don't
have to execute DEFINE commands from your terminal before you execute
DOCUMENT.
The other nice thing about the <includes_file> tag is that it
documents what the logical's definition was at the time of the
bookbuild. That might be handy six months later when you go to
revise the book and you are wondering where you stashed the
"table_of_codes" file.
If you want to give full file specs in the <include> tags, then
you don't have to worry about defining logical names and you don't
have to put any <includes_file> tags in your profile.
|
| Thanx for the reply in .3. I was off on the wrong track in spite
of the fact that <includes_file> is documented just as you described, though
not in as much detail. I'm the first person to admit that symbols and
logicals have always be confusing to me; I always take two passes with
DCL SHOW; gee, if not's symbol, it must be logical!
I did run test files this a.m., before reading .3, that readily illustrated
the answer I was searching for. But I'm glad you offered the explanation
you did, cuz I'm gonna offer it word-for-word to anyone else who gets confused
about it.
Thanx again!
Rose
|