[Framers] Conditional Expression build crashing FrameMaker with Internal Errors

[Robert Lauriston]

I'd probably name that TrustedCustomerOnly (or NDACustomerOnly?)
instead of External.

On Tue, May 10, 2016 at 10:07 PM, Lin Sims <ljsims.ml at gmail.com> wrote:
> Most of the text is unconditional. And sadly, I actually need the External
> tag.
>
> Not because of any of the actual TEXT, but because of the proprietary
> language in the footers. We have one sentence for internal, do not show to
> customers on pain of feeding the dragons, and another of you're our customer
> and we trust you to a certain point, but you do not show this to anyone
> else, y'hear?. And the text is in separate variables, so I can't just import
> a variable definition to them. So for the sake of not having to import page
> layouts as well as conditions and variables ... I have an External tag.
>
> Laughable, ain't it?
>
> On Tue, May 10, 2016 at 9:37 PM, Robert Lauriston <robert at lauriston.com>
> wrote:
>>
>> Exactly. In your situation, I'd maybe have AOnly, ACustOnly,
>> AInternalOnly, BOnly, BCustOnly, BInternalOnly, and Internal. Then the
>> conditional expressions would be:
>>
>> for A regular version: not (ACustOnly or AInternalOnly or BOnly or
>> BCustOnly or BInternalOnly or Internal)
>> for A Cust version: not (AInternalOnly or BOnly or BCustOnly or
>> BInternalOnly or Internal)
>> for A internal version: not (BOnly or BCustOnly or BInternalOnly)
>>
>> If there's so little unconditional text that it makes sense to tag
>> everything, it would probably be easier to switch to Flare.
>>
>> On Tue, May 10, 2016 at 5:44 PM, Lin Sims <ljsims.ml at gmail.com> wrote:
>> > Interesting. If I understand you correctly, you're suggesting that the
>> > text
>> > that needs to appear in a certain version be tagged with a condition for
>> > that version, and then in all the other versions (where it doesn't
>> > appear),
>> > you NOT it.
>> >
>> > I tell you what, after today I am definitely going to remember that!
>> >
>> > On Tue, May 10, 2016 at 6:31 PM, Robert Lauriston <robert at lauriston.com>
>> > wrote:
>> >>
>> >> If you have much content that is used in all versions, defining
>> >> conditional text to be excluded with NOT is simpler and less work.
>> >>
>> >> On Tue, May 10, 2016 at 3:02 PM, Lin Sims <ljsims.ml at gmail.com> wrote:
>> >> > One of the "rules" I learned somewhere was to either have all your
>> >> > conditions say what the text is IN, or have them all say what the
>> >> > text
>> >> > is
>> >> > NOT in, because (I was told) it could get confusing if some
>> >> > conditions
>> >> > were
>> >> > for when you did want text and others where for when you didn't want
>> >> > it.
>> >> > I
>> >> > generally pick what I want the text to be in.
>> >> >
>> >> > So my environment at the moment has two separate IPs, and two (or
>> >> > maybe
>> >> > 3)
>> >> > separate audiences, so that was how I defined my conditions (plus the
>> >> > two
>> >> > spare that are only seen in review drafts).
>> >> >
>> >> > People inside the company get to see everything for a particular IP,
>> >> > so
>> >> > their book has generic plus internal information for the IP plus the
>> >> > one
>> >> > special customer's information for the IP.
>> >> >
>> >> > People outside the company (who aren't the specific customer) get to
>> >> > see
>> >> > the
>> >> > generic information for the IP.
>> >> >
>> >> > People who work for that one special customer get to see the generic
>> >> > information for the IP plus the customer-specific information for the
>> >> > IP
>> >> > but
>> >> > NOT the internal information for the IP.
>> >> >
>> >> > I had considered doing separate tags for each combination, but I
>> >> > could
>> >> > see
>> >> > the number of possible combinations getting wildly out of hand.
>> >> >
>> >> > There's the additional issue that I while I usually know which IP the
>> >> > information is for (if it isn't generic), I don't always know who the
>> >> > audience is. It can change. The IP has been known to change. ("Oh, we
>> >> > said
>> >> > it was IP A and everyone could see it? Sorry, it's actually for both
>> >> > IP
>> >> > A
>> >> > and IP B, but only we and Cust01 get to see it.")
>> >> >
>> >> > Robert's "not" suggestion seems to be working correctly to generate
>> >> > the
>> >> > 6
>> >> > books I believe I'll need, but I will probably do some more testing
>> >> > to
>> >> > be
>> >> > sure, since I don't entirely understand how Frame is handling
>> >> > conditions. I
>> >> > honestly thought I had to explicitly state all the combinations I did
>> >> > want
>> >> > and all the ones I didn't want (hence the crashes and the plea for
>> >> > help).
>> >> >
>> >> > Again, thanks to all (and particularly Robert) for all the help.
>> >> >
>> >> > Time to go home.
>> >> >
>> >> >
>> >> > On Tue, May 10, 2016 at 5:02 PM, Robert Lauriston
>> >> > <robert at lauriston.com>
>> >> > wrote:
>> >> >>
>> >> >> Generally speaking, when defining a set of conditions, you want to
>> >> >> (1)
>> >> >> minimize the amount of text that has to be tagged, (2) minimize
>> >> >> multiple tagging, (3) maximize unconditional text, and (4) define
>> >> >> the
>> >> >> minimum number of conditions to achieve that.
>> >> >>
>> >> >> Sometimes that means defining conditions for text to be included,
>> >> >> other times it means defining conditions for text to be excluded.
>> >> >> Best
>> >> >> practice, those should be named so as to indicate their function,
>> >> >> for
>> >> >> example IncludeInFoo, OnlyInFoo, and ExcludeFromFoo.
>> >> >>
>> >> >> I'm not sure why an Internal tag would ever be combined with any
>> >> >> other
>> >> >> tag. External should be unnecessary since it means the same thing as
>> >> >> the absence of the Internal tag.
>> >> >>
>> >> >> On Tue, May 10, 2016 at 1:21 PM, Lin Sims <ljsims.ml at gmail.com>
>> >> >> wrote:
>> >> >> > Yours is a more elegant solution. As I said before, this is my
>> >> >> > first
>> >> >> > go-around with Conditional expressions. It didn't help at all that
>> >> >> > the
>> >> >> > standard I was told to apply here was to tag text with the
>> >> >> > condition
>> >> >> > for
>> >> >> > the
>> >> >> > book I want to produce. That produced some odd results I can no
>> >> >> > longer
>> >> >> > recall (mostly because I had text tagged for both Internal and
>> >> >> > Cust01).
>> >> >> >
>> >> >> > What I wound up with, in variations, is as follows:
>> >> >> >
>> >> >> > For a book where I want IP A and Cust01, but not IP B or Internal,
>> >> >> > I
>> >> >> > used:
>> >> >> >
>> >> >> > "IP A" or "Cust01" and not ("IP B" or ("IP A" and "Internal"))
>> >> >> >
>> >> >> > It works.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Tue, May 10, 2016 at 3:35 PM, Robert Lauriston
>> >> >> > <robert at lauriston.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> ("A" or "External" or ("A" and "External")) could be simplified
>> >> >> >> to
>> >> >> >>
>> >> >> >> ("A" or "External")
>> >> >> >>
>> >> >> >> not (("A" and "Internal") or "B" or ("B" and "External") or "TBP
>> >> >> >> or
>> >> >> >> "WriterNote")
>> >> >> >>
>> >> >> >> could be simplified to
>> >> >> >>
>> >> >> >> not ("A" and "Internal") or "B"  or "TBP or "WriterNote")
>> >> >> >>
>> >> >> >> But it's not clear why you can't just use
>> >> >> >>
>> >> >> >> not ("Internal" or "B"  or "TBP or "WriterNote")