| Item 1:
<includes_file> declares a LOGICAL name for a file name, whereas
the other "name-declaring" tags declare SYMBOL names. I admit,
there is a lot of similarity in the concept since both are names
through which you can address something else.
The <includes_file> syntax comes from the DCL DEFINE command in
which the logical name comes first, the equivalence name comes
second. (If you've been around Digital long enough you know about
the old ASSIGN command in which the ordering of the two arguments was
reversed. For about five years I kept the syntax of those two
commands taped to my terminal, because I could not remember which
was which.) So it seems quite "logical" to me that the <includes_file>
syntax should be the same as the DEFINE command syntax. Perhaps
if the documentation pointed out the same parallel it would seem
"logical" to new users, too.
The tagname <includes_file> could be changed to <define_logical>.
<define_logical> says what the tag DOES, <includes_file> tells WHY
THE TAG IS NEEDED (because the element is going to <include> this
file).
|
| By the way, the tags that take file names as arguments
(<element>, <includes_file>, <include>, <figure_file>, etc)
read the file name argument just like any other argument.
If you are using < and > to surround the directory specification
in the file name, then the tag translator is going to try
to make a tag out of your directory specification!
I just tried <includes_file>(foo\<kohlbrenner>table.gnc) and
I got two error messages. The first was that <kohlbrenner> is
an undefined tag. The second was a failure to open the file
FOO (RMS said the file specification syntax was bad). By
the time it got to opening the file, the file specification
was something like "<literal>(<kohlbrenner>)table.gnc".
So, (for V1.0 at least) you must use SQUARE BRACKETS in
all file specifications that are actually going to be seen
by the tag translator. We'll be sure to document that in
each of the tag descriptions.
Note that if I had said
<includes_file>(foo\<kohlbrenner.table>table.gnc)
it would have worked fine because the period would have convinced
the tag translator that this was not intended to be a tag.
But if the top level directory had been [EXAMPLE], I would have
been in trouble still!
<includes_file>(foo\<example.tree>ash.gnc)
In this case, the tag translator would have noted that <example
is pretty close to <example> and it would have issued an ISTHISTAG
message asking if you had perhaps left off the ">". When the tag
translator sees what looks like a tag without its closing angle
bracket, it checks to see if the name that it has is a known tag
name. If it is a known tag, then it issues the Information-level
ISTHISTAG message. If it is not a known tag, then it gives up
trying to make a tag out of what it has and simply passes it on
as text.
|
| Rose:
For your information, we have revised much of the processing and
book building info. in the User's Guide for Version 1 release. Most
of your comments in 155.0 are already done: chapters 2 and 5 have
been combined (after we extracted command and qualifier info. and
placed it in a command line appendix.) Also, there is now an example
for each kind of processing (file build, book build, element build, sub-
element build). In general, how to do each of these processes is
explained more clearly.
I'll check into clarifying the use of <includes_file> in the U.G.
as well.
So, it looks like we are on the same wavelength! Thanks for the
input. Barbara
|