Help with format rules in EDD

[Guest]

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.

[Van Kurtz]

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

[Guest]

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?

[Van Kurtz · Accepted solution]

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

[Guest]

Worked like a charm! and fixed another issue I hadn't figure out yet as well.

I'm reviewing all my rules to check for this problem. Thanks again!

[skumark4]

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

[Van Kurtz]

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

[skumark5]

Hi Van,

Thanks for the reply. I will try as you said. I will contact you in this blog incase of any clarification. I expect your kind cooperation.

This blog is very helpful and your suggestions are very valuable and helpful.

Sudheer

[skumark5]

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.

[Ian Proudfoot]

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

[skumark5]

Hi Ian,

Sorry.!! I don't know much abot the blogging rules..Anyways i got the info what i need. Thanks..

Sudheer.

[Ian Proudfoot]

Hi Sudheer,

Although you may get the corrected printed output using attribute rules it will not give you the correctly populated attributes for SGML export. For ATA iSpec2200 CMM you have to follow the AMTOSS rules which requires that the coding is present on all relevant elements.

Ian

[Van Kurtz]

Sudheer,

Prefix Rule

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

First, I know nothing about ISpec 2200 DTD. So, I do not understand why the Task element needs the same attributes as the enclosing CMM element; but we do not need to worry about that.

As you have written your prefix rule, the TASK element is taking the attribute values from the TASK element itself, because the TASK element does indeed have those attributes. IF the TASK element did not have these attributes defined for it in the EDD, then FrameMaker would traverse up the hierarchy until it found an element that had those attributes, which is probably the CMM element. Note the IF at the beginning of the sentence. I am simply illustrating what FrameMaker would do if this were the case...but it is not the case, so we move on.

As described in Developing Structured Applications, you need to specify the name of the element whose attributes you want to use in the prefix. The format for this is:

<$attribute[attribute_name:element_name]>

Note the colon. So, your prefix for TASK would be:

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

In this case, the EDD uses chapno, secno, and subno attribute values from the CMM element BUT Function_Code, Sequence_Number, Configuration_Letter, and Variant_Number from the TASK element. IF you want the last four attribute values to come from the CMM element also, you need to insert :CMM after each one.

I hope this is what you are trying to do. If not, please clarify.

Van

[skumark5]

Hi Van,

I got what i wanted. Thanks for the help..

Sudheer.

[Ian Proudfoot]

Sudheer,

In the past I have have used the FDK and FrameScript to do this attribute copying. If you are using FM10 then it could be done with ExtendScript.

As Van says this sort of requirement is normally bad practice. But for the ATA iSpec 2200 DTDs its an essential 'feature'.

Ian

[skumark5]

Hi Proudfoot,

thanks for the reply. I am using FM 10. I will try as Van said and try to use parent element atrributes. I am trying this for ISpec 2200 DTD.

Regards

Sudheer

[skumark5]

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