|
Re: .1
Thanx for the pointer back to 217.1. I don't think that's the exact
note that I'm looking for, but it answered some other questions.
Re: .2
I read the description on page 2-6 in the UG1, as well as the one on
pages 8-7 and 8-8. But I'm still fuzzy on how it's all working. Is
this how it works?
1. Process CANINES_PRO with /CONDITION=ENGLISH
2. Now process SETTERS, an element of CANINES_PRO, using
/PROFILE=CANINES_PRO, and the ENGLISH condition will be
remembered/implied
The example in the book on page 8-8 is very brief; too brief. And by
it's mention of <set_condition>, it implies that <set_condition> is
necessary in some file; that's how it seemed to me anyway. But I don't
believe that's true.
Seems there was also a discussion somewhere of the effects of having a
<set_condition>(FOO1) in a file, then processing that file with
/CONDITION=FOO2; with the latter overriding the former? I might even
have been the one to initiate that discussion. Something did not
"stick" with me somewhere.
Rose
|
| A /CONDITION qualifier (Yes, it ought to be called /SET_CONDITION,
but it isn't.) is equivalent to doing a <set_condition> tag before
any of your input file(s) are read. The advantage of using
the qualifier, rather than trying to put the tag at the front
of your input file is that the qualifier takes effect before
a /SYMBOLS file or a /INCLUDE file is read, hence you could
conditionalize the <define_symbol> tags in the /SYMBOLS file
or some of the text in the /INCLUDE file.
You can use a /CONDITION qualifier on the command line and
sprinkle <set_condition> tags all over your files. The tag
translator is not imposing any kind of "logic" to the condition
names that are set. For example, you may have a document that
is intended for printing in a VMS environment or in an ULTRIX
environment. You have conditionalized certain text with a
<condition>(VMS) tag and other text with a <condition>(ULTRIX)
tag. The unconditionalized text is intended to appear in both
the VMS version of the document and the ULTRIX version of the
document. In your mind, the document MUST be run with either
------------
the VMS condition name "on", or the ULTRIX condition name "on,"
but it makes no sense at all to run it with both condition names
on or with both condition names off. The tag translator does
not care in the slightest if you execute it with both condition
names on, off, or for that matter if you also turn on a half
dozen more condition names (RSTS, RSX, DOS, etc). That is, the
tag translator does not require that only one condition name is
on at any one time; the more the merrier!
If the tag translator sees a <condition>(VNS) (that is "VMS" spelled wrong)
it simply tests if there was a <set_condition> tag or a /CONDITION
qualifier that turned the "VNS" condition name "on" and if not
it skips to the next <endcondition> tag. It has no way of knowing
that VNS is a misspelling of VMS.
You can turn "off" a condition name, by the way, by executing
the <set_condition>(foo\REMOVE) tag. This works, regardless of
whether the condition name was turned on by a /CONDITION qualifier
or by a <set_condition> tag. (The /CONDITION qualifier is
"implemented" by the tag translator by actually executing a
<set_condition> tag, you see.) Unfortunately, there is
no /NOCONDITION version of the /CONDITION qualifier.)
This is complicated by the fact that we try to be helpful by
"remembering" the /CONDIITON qualifier that you used on a bookbuild
and then we automatically repeat it for you on an element build
provided you do not supply a /CONDITION qualifier on the element
build. (In retrospect, this is probably unhelpful, since it
only complicates the "model" of how condition names get set and
how they work, and as you can see in note 217.x, there are
users who do not want to use the same /CONDITION qualifier on element
builds that they used on the book build.)
|