Skip to main content
W
Wes Edmonds
Participating Frequently
January 20, 2010
Answered

Text Formatting Rules for sibling elements

  • January 20, 2010
  • 1 reply
  • 926 views

How would you edit the EDD Text format rules of an element repeated several times after one sibling optional element? For example, you have the following elements, it's children, and their formats:

1. TASK (with Title)
   A. TOPIC (w/ Title)
      (1) SUBTASK (w/ Title)
      (2) SUBTASK (w/ Title)
      (3) SUBTASK (w/ Title)

Now, if the TOPIC Title elelment is not used, I need the Subtasks to appear as follows:

1. TASK (with Title)

    TOPIC (w/o Title) (TOPIC element still present)
        A. SUBTASK (w/ Title)
        B. SUBTASK (w/ Title)
        C. SUBTASK (w/ Title)

How would you write that in the EDD? Which element would I edit? The Subtask? Or, the Title?

I've tried several combinations in the Text format rules and subrules using different context specifications like {notfirst}, {after Title}, {first}, etc., but I can't seem to make it work. Anyone familiar with the ATA iSPEC 2200 will recognize the formatting.

Wes

This topic has been closed for replies.
Correct answer Ian Proudfoot

Hi Wes,

That's correct. This potentially confusing problem is only identified for the CMM DTD, but the problem is exactly the same for AMM and a few other doctypes. If you look at the description of the CMM task element in the iSpec document you will find examples of the five ways that the sub elements may be used. There is also the following advice "Avoid intermixing the different ways that TASK and TOPIC can be handled. It is recommended to pick one way and stay with it".  That's very good advice in my opinion.

The specification shows five ways that TASK and TOPIC may be used, but I found a total of thirteen possible constructs for the CMM! My development work for a FrameMaker ATAiSpec2200 application was for a commercia application so we built in an interface that allowed a single style to be selected then used throughout the manual.

Ian

1 reply

Ian Proudfoot
Ian Proudfoot
Legend
January 20, 2010

Wes,

My take on this problem is that the numbering has to be consistent across the entire manual, so that you don't change the numbering format of a child if the parent has no title. There are several reasons for this including:

  • The Topic is still there so it should be numbered, even if it has no title
  • Building cross reference formats that work becomes impossible if the autonumbers change according to the use of titles. This is because at some point you will need to cross ref to autonumbers with underscore which has to be coded into the cross ref format.
  • There are five different structures that can be considered legal for formatting purposes according to iSpec 2200. But it is essential that the chosen structures are used throughout an AMM, CMM or any other document. It is very easy to mix the structures in ways that can cause confusion later in the publication process. To avoid this I have used additional advisory formatting (e.g. bright red text) that only gets applied if you put the wrong structures together.
  • The ATA numbering system needs all the help it can get to remain manageable...

To give the topic an autonumber use a First Paragraph rule in the EDD. That will apply the autonumber to the title if it's there or any other element if it is missing.

I hope some of this helps

Ian

W
Wes EdmondsAuthor
Participating Frequently
January 20, 2010

Hi Ian,

So basically, your telling me the outline structure variations the iSPEC details is the Task DTD description are not options each manual must maintain??? Ugh, I've been banging away for 6 months trying to develop a context text formatting rules scheme that would allow the variations.

Ian Proudfoot
Ian ProudfootCorrect answer
Legend
January 20, 2010

Hi Wes,

That's correct. This potentially confusing problem is only identified for the CMM DTD, but the problem is exactly the same for AMM and a few other doctypes. If you look at the description of the CMM task element in the iSpec document you will find examples of the five ways that the sub elements may be used. There is also the following advice "Avoid intermixing the different ways that TASK and TOPIC can be handled. It is recommended to pick one way and stay with it".  That's very good advice in my opinion.

The specification shows five ways that TASK and TOPIC may be used, but I found a total of thirteen possible constructs for the CMM! My development work for a FrameMaker ATAiSpec2200 application was for a commercia application so we built in an interface that allowed a single style to be selected then used throughout the manual.

Ian

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices