Structured documents often contain nestable elements. For example, a Section can contain subsections; an Item in a List might contain a sublist. Formatting typically changes for each level of nesting. The Title of a top-level Section might have a single-part number (1., 2., 3., and so forth), while the Title of a second-level Section has a two-part number (1.1., 1.2, 1.3, ....) and a third-level Section a three-part number (1.1.1, 1.1.2, 1.1.3, ...). Titles of more deeply nested Sections might not be numbered, and may change font size and other properties.
Nested lists may be progressively indented. Numbered lists may use different numbering conventions (1., 2., 3. and so forth) as opposed to (a., b., c., and so forth) for different levels. "Bulleted" lists can mark items in different levels of lists with different symbols (solid or outlined bullets), different shapes (circles, squares, or dashes).
An EDD can use either level rules or context levels to determine the appropriate convention for a particular list item. As the above examples illustrate, formatting changes for progressive levels often are highly individual and the EDD must test for each supported level and set the appropriate properties or paragraph formats. In such cases, the EDD developer must define rules that check for each supported level and format it appropriately. Even if the only change for successive levels is simply to indent each level a fixed amount beyond the containing lavel, the developer might want to check for the impossible point when the left margin is to the right of the right margin.
There are three ways to deal with limiting nested levels:
1. Use the same element tags for all levels and assume users will not create levels deeper than those for which formatting is defined. For example, Section may have a general rule such as (Title, (Paragraph | List)*, Section *). Text Format Rules for Title would test the nesting level and assign appropriate formatting. If the organization does not support more than, say, 6 levels of nesting, teach this limit to the writers using the resulting template.
2. Use the same element tags for all levels but make unexpected nesting visible by essentially embedding an error message in the element. For example, a Title in a level 1 section might use an autonumber such as <n+>., in a level 2 section might use <n>.<n+>, a level 3 section might use <n>.<n>.<n+> while anything more deeply nested might display in red, bold text something like ***Only 3 levels of Section allowed ***.
3. Use related but distinct tags for each level. For example:
Define an element called Section1 with the general rule Title, (Paragraph | List)*, Section2*, to allow Section2 elements within Section 1 elements.
Define Section 2 with the general rule Title, (Paragraph | List)*, Section3* and so forth.
Do not provide further nesting for the deepest supported level. In this case, suppose 5 levels are supported, the general rule for Section5 would be Title, (Paragraph | List)*. Thus, writers do not have the opportunity to try to insert an invalid structure.
My personal preference is to use the middle technique. It gives writers feedback if they attempt to nest sections more deeply than expected. And it also makes it easier to change the nesting level of existing sections. Suppose a writer decides to wrap a new Section around three existing 5th-level Sections. The old Sections would automatically change to 6th-level Sections. The same type of editing in method-3 would require the user to change the original Section5 elements to Section6. The need to explicitly identify the level rule in my opinion avoids an important usability benefit of structured documents.
--Lynne
AdChoices