Step 2-5. Declare Element Type Parameter Entities

In faq-question.mod, find the comment labeled "ELEMENT NAME ENTITIES."

These parameter entities allow document type shell DTDs to extend the base content models that reference these element types by redeclaring these parameter entities to either include additional element types (for example, specializations of the parameter entity's associated element type) or replace the original type with new types.

In this section of the file, make the following changes to the parameter entity declarations:

Change "concept" to "faq-question" for both the parameter entity name and value.
Change "conbody" to "faq-answer" for both the parameter entity name and value.
Declare a new parameter entity %faq-question-statement; like so:
```
<!ENTITY % faq-question-statement "faq-question-statement" >
```

The element name entities section should now look like this:

<!-- ============================================================= -->
<!--                   ELEMENT NAME ENTITIES                       -->
<!-- ============================================================= -->
 

<!ENTITY % faq-question           "faq-question" >
<!ENTITY % faq-answer             "faq-answer"   >
<!ENTITY % faq-question-statement "faq-question-statement" >

Validate the test document again. The test document should validate.

If it does validate, then we know that the declarations are correct in the module, at least as far allowing our new element types, and that the document type shell DTD is hooked up correctly.

At this point another test would be to see if our requirement that no nested topics or nested FAQ questions are allowed is satisfied. Only the <no-topic-nesting> element should be allowed.

Note that if you wanted to be really forceful about the requirement for no topic nesting, you could simply modify the content model of <faq-question> to remove the reference to %faq-question-info-types; entirely. That would be a statement that nested topics should never be allowed, while the <no-topic-nesting> element simply says "for this configuration, I don't want to allow topics."

The content model of <faq-question> as it is currently defined would enable users to configure a document type shell DTD that would allow nested topics, and would enable developers to allow nested topics in a specialization of <faq-question>. If it was essential to the semantic of FAQ questions that nested topics never be allowed, it would be better to remove the reference to %info-types;. But that would probably be too constraining in this case. In general, when designing an element type that is general enough that it is likely to itself be a base for specialization, you should err on the side of laxity, and let configurators and specializers add in the constraints they want.

While the declarations are now sufficient for us to create FAQ question instances, it's not complete because we haven't declared the DITA @class attributes that define the specialization hierarchies for the new element types. This means that if we try to process our test document with the DITA Open Toolkit we won't get any output because the toolkit will not know that <faq-question> is actually a specialization of <concept>.