[Framers] Conditional Expression build crashing FrameMaker with Internal Errors

[Robert Lauriston]

I found FrameMaker's conditions became hard to use and maintain with
even three overlapping deliverables: in one case, for students,
teachers, and system administrators, in another customers, managers,
and sysadmins.

Flare's reuse features are much more manageable and transparent for
more complex projects.

My guess is your original expressions caused crashes because the
logical redundancies were too complicated for the parser to evaluate.


On Wed, May 11, 2016 at 11:30 AM, Lin Sims <ljsims.ml at gmail.com> wrote:
> I wanted to thank you again for the help with this. I was looking at a
> nightmare, and it's now just a bad memory. :-)
>
> While it already seems to be working fine, I wanted to double-check
> something. The expressions are set up as you suggested, to NOT the
> conditions I don't want visible in a particular book.
>
> However, instead of setting a condition for each book being generated (which
> would involve determining all of the different valid condition combinations;
> admittedly a small task in this book), I am layering tags, mostly because
> that's how I already have it set up and I really don't want to figure out
> how to revise the tags and their application across 400+ pages in multiple
> document and book files. The other reason is that I rarely know ahead of
> time how many books will be coming out of the same set of documents. There's
> always a minimum of two (internal and external), but I'll often have new IP
> being added on months after I've started the project.
>
> Your suggestion works just as well with layered conditions as it does with a
> condition tag set up for the particular combination of circumstances.
>
> I was wondering, though, if you or anyone else had a lot of experience doing
> it this way and if there were a limit to the number of layers that could be
> used. I have a maximum of two tags on any given piece of information at the
> moment, but I'm also looking ahead to other books sets I have that can
> generate up to 7 or 8 documents where a piece of information can appear in 4
> but not the other 3, and there's not a lot of consistency to the
> combinations. In other words, I'd rather have 7 or 8 conditions to work with
> than the 20 or more that would be needed to cover all the combinations that
> have appeared as new books are sourced from the same set of documents. And
> yes, they really DO share enough information that it's far better to single
> source than it is to split into separate projects.
>
> So will using your suggestion keep working when information has been tagged
> with more than two conditions, and is there a hard limit to how many
> conditions can be layered this way?
>
> I swear, I have to read that chapter again. Maybe several more times. And
> I'd still like to know why my original expressions crashed things.
>
> On Wed, May 11, 2016 at 1:15 PM, Robert Lauriston <robert at lauriston.com>
> wrote:
>>
>> 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")