Using OR (|) indicators in a specification

[#1]

I am using FrameMaker 2019.

Page 257 of the "Developing Structured Applications" Guide (2015) covers the use of OR indicators within a specification for a Context Rule.

I have attempted to make use of this with the following:

This appears to work OK when All the (Action | Command) tests finds all Action elements or all Command elements.

Action        

               Action

                              Action

                                             Action

Or

Command

                    Command

                                        Command

                                                            Command

However if the results a mixed e.g.:

Action

               Command

                                       Action

                                                       Action

The rules seem to work on the first element in the (Action | Command) pair i.e. It finds the first Action element but fails to find the second Command element.

Is this a feature or a bug?

[#2]

Timothy,

   Can you send a screen capture of the Show Element Context window when the insertion point is in an element that does not format properly? You can open this window with Structure > Show Element Context.

    Meanwhile, over the weekend, I will try to find time to create a test EDD based on the information you have provided and see if I can duplicate your problem.

     --Lynne

[#3]

Thanks for the reply.

Here is the relevant set of rules you requested.

You should note that anywhere you see <AA means that the rule will not work <AA is a test rule I am using. In this case I hadcreated some rules to work around my problem. However they provide an indication where the OR cases fail.

[#4]

Timothy,

    First, I created a test case that is much simpler than yours. I found that context specifications such as:

        (s1 | s2) < * < (s1 | s2) < * < (s1 | s2)

sometimes work and sometimes don't, even when used to format an element that has both s1 and s2 ancestors. However,

    (s1 | s2) < (s1 | s2) < (s1 | s2)

worked (although it might not be what you want to test). Also,

    s1 < * < s1 < * s1

also worked in all my test cases. Thus, the problem isn't just the OR indicator, the wildcard, or a context involving different types of ancestors. I was unable to come up with a description of what causes the failure.

  I filed my test case with bug FRMAKER-6701.

  Second, your context rule is unusually complicated. Is it necessary to explicitly list so many ancestors? When elements can an asterisk represent? Depending on the way your various elements can nest, you might be able to use a level rule instead of a context rule. Based on your initial message, I tried a test using the element definition:

Element (Container): Challenge

    General rule: <TEXT>

    Text format rules

    1. Count ancestors named: Action

                                                Command

        If level is: 0

              No additional formatting.

        Else, if level is: 1

             Use format change list: Challenge1

        Else, if level is: 2

             Use format change list: Challenge2

        Else, if level is: 3

             Use format change list: Challenge3

        Else, if level is: 3

             Use format change list: Challenge4

        Else

             Use format change list: Illegal

This rule was sufficient for my test case, but may not address all the possible variations you need to support. Good luck,

    --Lynne

[#5]

Thanks Lynne.

Well done identifying the wildcard as the issue. That's great thinking.

I initially started using the Level rule.

Unfortunately I am dealing with elements that are indent in the same way, but are somewhat asymmetric in the way their hierarchy works

This results in some combination that the level rule captures incorrectly.

Also unfortunately the wild cards a are necessary to cater for some hierarchical variations that are allowed.

I have found a workaround though. I am using the Or based rules and then creating specific rules for cases that fail.

Its a pain and requires a lot of testing, but it provides a consistent result.

I am trying to think of a way to take the wildcards out of play, but I think it would be even more complex than my workaround.

One of the things that the EDD function needs is a way to provide commenting at the rule level rather than just the Element level.

I could identify the special cases for future removal when the bug is fixed.

Accepting that it is a bug provides some relief. The main thing is that I am not nuts (Yet).

[#6]

Lynne,

I have finally got around to creating a rule using two Level rules that are nested that seems to work for all my cases.

Has there been any response from Adobe regarding the bug?

I have found a number of other rules that apply to high level Elements that can't be manages using Level rules, that don't work properly.