A

Anonymous

Answered

Help with format rules in EDD

Forum|Forum|15 years ago
September 9, 2010
3 replies
2608 views

Frame9 + DITA-FmX

I'm working on my EDD, writing formatting rules that will apply our

standard template formats to the appropriate DITA elements.

I'm having a problem that is puzzling me. Our template defines

different formats for steps and bullets that are in a table, and steps

and bullets that are not in a table. So, for the <li> element, I've

written a set of formatting rules designed to capture those contexts,

plus a few other things (nested level of the list, whether the <li> is

the first in the <ol>, etc.), and apply the correct paragraph format.

The context clause that applies formats for <li> elements inside a

table appears *before* the clause that applies formats to <li>

elements outside a table. Roughly, it goes like this:

If context is: * < entry

[so these rules are meant for lists in a table cell]

If context is: ul < li < ol

Use paragraph format ...

[for the specific case of a bulleted list nested in a

numbered list]

Else, if context is: ul

Count ancestors named: ul

Stop counting at first ancestor named: entry

If level is 1:

...

Else, if context is: ol

Count ancestors named: ol

Stop counting at first ancestor named: entry

If level is 1:

...

Else, if context is: * < (conbody | section)

[so these rules are meant for lists outside a table,

and only in ref or concept topics]

If context is: ul

... etc.

This is working fine for lists outside a table, but that whole first

section of rules that applies to numbered and bulleted lists inside a

table seems to be skipped somehow, and the formats that are being

applied are those for numbered and bulleted lists outside a table. I

suspect that the * < (conbody | section) context may be too broad? but

since it appears *after* the clause for the * < entry context I

figured the table lists would be picked up first.

The thing that is really puzzling me is that when I look in the Show

Element Context view -- with those little arrows that point to the

formatting rule that is being applied -- the correct formatting rules

(and formats) are indicated. So I'm not sure what the problem is.

My EDD is valid, and the documents I import it into are also valid. Is

there any way I can track down this problem when the Show Element

Context view appears to be telling me my rules are correct?

All suggestions welcome...

Thx.

Structured

This topic has been closed for replies.

Correct answer Van Kurtz

Kyle,

Yes, that is the good (proper?) way to do it.

Note that with the three rules you listed in your last post, you could simply put Rule 3 before Rule 1, without combining them into one rule. In this way, it FIRST applies the formatting as if it is in a conbody or section. Then applies the formatting AGAIN IF the list is inside a table. That should work.

HOWEVER, this forces FrameMaker to possibly format the list twice. By combining the rules into one, you apply the formatting only once but after you know what to apply. My guess is that combining the rules into one will not make things work faster, because formatting is applied rather quickly; it is just a little cleaner. So, whichever is clearer to you is how you should do it.

When using multiple formatting rules for an element, you just need to do some due diligence and trace through the list to see if later rules affect the previous rules in ways you do not want. There are many situations in which multiple rules are both necessary and useful.

Van

skumark5

Participating Frequently

This blog is very useful and i feel that there are experts blogging here to resolve the issues and helping the people in need. Thank you guys..Please keep doing this.

Regards

sudheer

S

skumark4

New Participant

Hi Guys..Could somebody help me?

I have given some attribute values in the highest validating element.

i wanted assign these attribute values to child element atrribute values.

For Ex:

I have CMM element as hightest element.

CMM have atrributs like "chapno, subno, secno".

I have assisgned some values to these attributes.

I have a child element called "Task" which also has attributes "chapno, subno, secno".

I wanted to assign the attribute values of element CMM to attribut values of Task automatically.

plz help me guys.

Thanks

Sudheer

V

Van Kurtz

Inspiring

Sudheer,

Why do you need the child element to copy its attributes from the parent? In my opinion, it is probably unnecessary and a poor practice.

If the EDD needs the attribute values to format the child element, then it can and should get them from the parent. So, for example, your EDD would be something like:

If context is: * < CMM[chapno="xxx"]

then format rules

If you have another reason for copying the attributes or I am missing something, please clarify.

Thanks,
Van

Ian Proudfoot

Brainiac

Hi Van,

The attribute values are not fixed. I Should assign the values in the frame files but not in the EDD. If i assingn the values to CMM attributes in frame files, the values should reflect to Task element's attributes automatically in the framefiles.

As i said if i assing values chapno=24, subno=20, secno=25 to CMM element,

then task number should be generated some thing like "TASK 24-25-20-XXX-XX-X".

Till now i have been giving the attribute values for each and every Task. My concern is, every time i insert a Task, that should generate the autogenerated text as i said above by taking the values from CMM element.

Below is the prefix rule for TASK element i have in my EDD. These attributs are not taking values from CMM but taking values from Task. These should take values from CMM element.

Prefix Rule

TASK <$attribute[chapno]>-<$attribute[secno]>-<$attribute[subno]>-<$attribute[Function_Code]>-<$attribute[Sequence_Number]>-<$attribute[Configuration_Letter]><$attribute[Variant_Number]>

I hope you got my point.

Please help me.

Hi Sudheer,

I think this ATA related topic should be moved to a new thread as it is not really related to the originl problem which is already marked as fixed.

Ian

V

Van Kurtz

Inspiring

Kyle,

If context is: * < entry
[so these rules are meant for lists in a table cell]
If context is: ul < li < ol
Use paragraph format ...
[for the specific case of a bulleted list nested in a
numbered list]
Else, if context is: ul
Count ancestors named: ul
Stop counting at first ancestor named: entry
If level is 1:
...

Else, if context is: ol
Count ancestors named: ol
Stop counting at first ancestor named: entry
If level is 1:
...

Else, if context is: * < (conbody | section)
[so these rules are meant for lists outside a table,
and only in ref or concept topics]

If context is: ul
... etc.

You may have mistyped the above, but for now I will assume that it is what you have.

First, there can be more than one formatting rule for an element. To outline:

1. If context:

2. If context:

3. If context:

etc

Each and every rule is checked, and if applicable, applied. For example, if Rules 1 and 3 both satisfy their contexts, then they are both applied, even if Rule 3 undoes Rule 1. So, you need to keep that in mind. If you look at your listing above, you see that the first IF for entry is followed by another IF; I am assuming the second IF is the second rule. If so, it applies to all li elements that fit the context, irrespective of whether they are inside or outside a table.

The second point is that once you determine that your list is inside a table, you need to apply a subrule that determines the level and formatting of the list item.

So, you need to do something like this:

If context: * < table

Subrule element

If context is: ul < li < ol

.

etc

Else if context: * < (conbody | section)

Subrule element

If context is: ul < li < ol

.

etc

The subrule structure under the table-if is probably the same as the one under the else-if, except that the applied formats will be different.

An alternative would be:

If context is: ul < li < ol

Subrule element

If context is: * < table

Else if context is:* < (conbody | section)

Else, if context is: ul

Count ancestors named: ul

Stop counting at first ancestor named: entry

If level is 1:

...

Subrule element

If context is: * < table

Else if context is:* < (conbody | section)

Else, if context is: ol

Count ancestors named: ol

Stop counting at first ancestor named: entry

If level is 1:

...

Subrule element

If context is: * < table

Else if context is:* < (conbody | section)

In other words, you would have to check the inside/outside of the table context at the end of each if or else-if.

So, it all depends upon what repeating of rules you want to do. In my mind, the first approach is better, because it clearly establishes whether the item is inside or outside of a table. Once, you determine that, then you apply a subrule to figure out the formatting.

Good luck,

Van

A

Anonymous

Van, thanks so much. That is hugely helpful; I did not know the difference between creating multiple rules and creating one

big rule with a lot of else-ifs and subrules. I think that does answer my question. I actually did simplify what I put in my

first post, but basically I have three rules:

1. If context is * < entry

...bunch of if, else if, subrules that cover all table contexts...

2. If context is: step {first} < *

...adds a keep with...

3. If context is * < (conbody | section)

...bunch of if, else if, subrules that cover non-table contexts...

So I see how the table contexts I'm trying to catch in rule 1 are also matching the contexts in rule 3

and having their formats re-applied. So I guess what I need to do is to combine rules 1 and 3 into

a single rule with the appropriate subrules, etc., so the clauses in the single rule will only be applied

to the first match. Is that right?

V

Van KurtzCorrect answer

Inspiring

Kyle,

Yes, that is the good (proper?) way to do it.

Note that with the three rules you listed in your last post, you could simply put Rule 3 before Rule 1, without combining them into one rule. In this way, it FIRST applies the formatting as if it is in a conbody or section. Then applies the formatting AGAIN IF the list is inside a table. That should work.

HOWEVER, this forces FrameMaker to possibly format the list twice. By combining the rules into one, you apply the formatting only once but after you know what to apply. My guess is that combining the rules into one will not make things work faster, because formatting is applied rather quickly; it is just a little cleaner. So, whichever is clearer to you is how you should do it.

When using multiple formatting rules for an element, you just need to do some due diligence and trace through the list to see if later rules affect the previous rules in ways you do not want. There are many situations in which multiple rules are both necessary and useful.

Van

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded