EDD context rules for any ancestors with certain attribute

[Simon_Song]

Hi all,

I am new to EDD programming, I understand the use of wildcard * in the context rule, like * < chapter.

But what if I want to add a context rule based on if any ancestor has attribute @Deleted User="yes", would something like the following work?

Else, if context is: * [change = ”yes”]

Text range.

Font properties

     Color: Forest Green

I have tried the above, importing the EDD seems fine (i.e. FM did not complain it been invalid), but it did not have any effect to the rendered document.

Is there anyway in the EDD that allow me to do this?

Because the above method did not work for me, so I thought I will explicitly list all the possible ancestors that may have @Deleted User=yes, so I tried the following context rule:

Else, if context is: * < (chapter | codechapter | codechapterdivision | codechaptersubdivision | part | division | subdivision | clause | subclause | schedule | subschedule) [change = ”yes”]

Text range.

Font properties

     Color: Forest Green

Surprisingly, this did not work either. However, when I reduced the list to just * < (chapter | clause)[change = ”yes”], FM renders the document correctly (i.e. the text becomes green).

Thanks in advance for your help.

Simon.

================================

Just to add that I am using FM 2017 release, version 14.

Message was edited by: Simon

[Lynne A. Price]

Simon,

  I have been successful with context specifications of the form in your second example:

      * < (list of elements) [attribute = "value"]

In my case, none of the listed elements can be descendants of any of the others. From the names of the elements in your example, I wonder if the element nesting may be causing problems.

Note that you should be able to replace your single clause with 11 new ones:

Else, if context is: * < chapter[change = ”yes”]

Text range.

Font properties

     Color: Forest Green

Else, if context is: * < codechapter [change = ”yes”]

Text range.

Font properties

     Color: Forest Green

Else, if context is: * < codechapterdivision[change = ”yes”]

Text range.

Font properties

     Color: Forest Green

and so forth.

     --Lynne

P. S. Are you familiar with the Structure > Show Element Context command? It shows you which format rules have fired for the current element. It can be very helpful in debugging context specifications.

[Simon_Song]

Hi Lynne,

Thanks for your reply.

I've tried a few changes and it seems that adding the attribute indicator to each ancestor as follow, works for me.

Else, if context is: * < (chapter[change = ”yes”] | codechapter[change = ”yes”] | codechapterdivision[change = ”yes”] | codechaptersubdivision[change = ”yes”] | part[change = ”yes”] | division[change = ”yes”] | subdivision[change = ”yes”] | clause[change = ”yes”] | subclause[change = ”yes”] | schedule[change = ”yes”] | subschedule[change = ”yes”])

Text range.

Font properties

     Color: Forest Green

Regards,

Simon.

[Lynne A. Price]

Simon,

    I'm glad you have found a context rule that works, but I would still like to understand why your second attempt did not. In summary, you have tried:

1. * [change = ”yes”]

2.  * < (chapter | codechapter | codechapterdivision | codechaptersubdivision | part | division | subdivision | clause | subclause | schedule | subschedule) [change = ”yes”]

3. * < (chapter | clause)[change = ”yes”]

4. * < (chapter[change = ”yes”] | codechapter[change = ”yes”] | codechapterdivision[change = ”yes”] | codechaptersubdivision[change = ”yes”] | part[change = ”yes”] | division[change = ”yes”] | subdivision[change = ”yes”] | clause[change = ”yes”] | subclause[change = ”yes”] | schedule[change = ”yes”] | subschedule[change = ”yes”])

Specification 1. is the most compact and I agree that it should work. I do not understand why 3. works (even if does not test all the contexts you want) but 2. does not. And 4. is a large amount of testing.

You have not mentioned what element you are formatting with these rules. Do you reuse this format rule in the definitions of multiple element types? If so, I recommend putting the long specification in a variable so that you can reuse it multiple times with no risk of a typo in any of the copies.

I'm also surprised that you are setting the color for a text range. In general, documents have three classes of element, although nesting can, of course, go much deeper:

1. What we might call organizational elements, such as all those you have listed in your context specification: parts, chapters, sections, and so forth. Of course, such elements can be nested.

2. Paragraph-level elements, which includes elements called paragraph (or para or p) and other elements that can occur as siblings or alternatives of paragraphs. For the sake of this discussion, I consider title, head, heading and their abbreviations to be paragraph-level elements as I do elements such as list, which require subelements such as item which are also at the paragraph level.

3. Inline elements such as phrase, name, citedtitle, partnumber.

I'm introducing this terminology just to point out that typically organizational elements and paragraph-level elements are formatted as FrameMaker paragraphs. Text ranges are parts of paragraphs. From the elements and attribute you've shown in your context specifications, it seems that you indicate when an organizational element has changed, but are changing text ranges within it.

It is also possible that your attempt 2. did work, but it's affect was undone by other format rules applied to nested elements. The Show Element Context command can help identify such situations. If the formatting specified for a nested element cancels the affect of the formatting of a containing element, though, switching from rule 2. to 4. shouldn't solve the problem.

As I mentioned in a private message, is there any chance of you sending me a sample document that illustrates some of these issues? It need no contain any proprietary text, of course.

--Lynne