Numbered Headings (Structured FM2019)

[QuintinSeegers]

Is it possible to autonumber headings in the format <Text><AutoNumber><Text>, e.g. Step 12: Issue Notices.

I know Autonumbering can be used, but that only allow for the number to be prefix, e.g. 12. Issue Notices and that I can set up the Autonumbering to include 'Step', however, the heading may not be Step #, it could be Appendix # instead. Creating different Heading elements is not ideal. I could use Attributes. (I find it annoying that there isn't an option to surpress the prompt to optional Attributes and only show the prompt for required Attributes. Not to mention that you can't set a default attribute value for text-type Attributes. But that's just my opinion.)

Is there a way to set up the Autonumbering to insert the number at a specific position, rather than first?

[frameexpert]

Here is how to set a default value for string attributes. However, you can't set a default value on required attributes.

[QuintinSeegers]

Ah, that's good to know. I thought you could only set a default value for Range-type attributes. Will get rid of those annoying <no value> I see when we have optional attributes and none was selected :-).

[frameexpert]

Is this what you mean for your first question? This just uses autonumbering, but in structured FrameMaker, you can use a combination of autonumbering and element prefixes and suffixes.

As far as "Step" versus "Appendix", is there a unique parent element that you could use to determine which format to use?

[QuintinSeegers]

In all of these instances, the same element (Heading) is used. We would need to use an Attribute to specify whether it's a Step or an Appendix.

I did try to set something up, using 2 Attributes: Numbering[None| Numbered] and Prefix[None | Step | Appendix]. Then I realised that the same Heading element is also used in certain documents where numbering of headings isn't allowed, but all other 'conditions/formatting' apply. Creating two different Elements simply because one has certain Attributes and the other doesn't seems a little counter-intuitive. I also have to consider that our writers need to understand which Heading Element to use in which circumstances.

Perhaps I'm trying to keep things too simple, resulting in things being over complicated.

[frameexpert · Accepted solution]

There is usually a balance between having a simple structure and keeping things easy for the author/editor. For example, if you have this:

<heading numbering-style>

it may keep the overall structure simpler, but then your user has to set an attribute value. Here is an alternative structure:

<appendix>

    <heading>

</appendix>

or

<step>

    <heading>

</step>

The structure adds an extra layer, but now you can use a context rule to determine the formatting of the heading numbering. Or, to avoid the extra level, you could do this

<appendix-heading>

<step-heading>

On custom EDDs, I prefer to develop an author-friendly structure, knowing that I can easily modify it on import/export via XSLT if necessary.

[QuintinSeegers]

I know what you mean by balance. Most of our document writers aren't writers. They're consultants writing ad-hoc documents for customers. So, the simplicity scale is tipped in their favour.

Thanks for your suggestions. Considering that there are existing documents based of the current EDD, going down the route of using Attributes might be easier than wrapping the Heading elements in another element. Fortunately our structure is rather strict (could it be called a structure if it isn't strict?), so any writers that complain about having to 'specify all these extra Attributes' can be told they can either use one Element and specify additional Attributes, of have numerous instances of the same type of Element and have to know when to use which one. Most of our team would go with the Attributes option.