Map Specialization Step 1: Design the Map Element Types

A typical FAQ consists of one or more groups of questions, where each group has a descriptive title. There may also be some introductory material that is not itself FAQ questions.

That suggests that an FAQ map needs the following components:

A topicref for referring to individual FAQ questions, e.g. "faq-question"
A topic head type for creating sets of related questions, e.g. "faq-question-set"
Some metadata for the FAQ set as a whole
The ability to refer to generic (non-FAQ question) topics at the start of an FAQ set.

The metadata requirement is handled by the generic metadata for topicrefs and maps (at least for the purpose of this exercise). References to generic topics can be done using unspecialized <topicref>.

That just leaves two element types to be defined for the FAQ map domain:

<faq-question>

Represents the use of a single FAQ question topic. Would normally be used with faq-question topics. Because we've defined the <faq-question> topic type to require short descriptions, it is probably appropriate to set the default value for the @type attribute to "faq-question" so that users are warned if they point to other topic types. Because FAQ questions are explicitly atomic, <faq-question> does not allow subordinate topicrefs.

<faq-question-set>

Creates a group of related FAQ questions. May have an initial generic topic or may refer to a non-FAQ-question topic to act as an introduction or to satisfy the need for title-only topics in some processing environments.

The content model is:

(topicmeta?, 
 topicref?, 
 faq-question*)

For the FAQ map type we need the following element types:

<faq-map>

Specializes from <map> and serves as the root of an FAQ publication. It's content model is:¹

(title,
 topicmeta?,
 keydef*,
 faq-question-set+,
 reltable*)

¹ I like to define my map types so that they allow exactly one root topicref type that serves as the root of the navigation tree defined by the map. I think that makes the use and intent of the map clearer, especially now that the @processing-role attribute makes a clear distinction between topicrefs that contribute to the navigation tree and those that do not (resource-only topicrefs). It also makes it clearer what the effect of a mapref to a subordinate map is because this pattern means that a reference to a map is equivalent to a reference to the root navigation topicref in the map. However, I did not apply that pattern to this example in order to keep it as simple as possible. For example, in a real design I would probably make the content model of <faq-map> something like "(faq | faq-question-set)" where <faq> is "(faq-question-set)+". This would let you have a single root map with <faq> as the root of the entire navigation tree but also allow submaps that contain single <faq-question-set> elements. That model allows a document with multiple FAQ question sets, but ensures that all maps have exactly one navigation root topicref.