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 (e.g., 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 go, 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, and in particular, no 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". That is, the content model of <faq-question> as it is currently defined would allow users to allow nested topics via configuration of a document type shell DTD and would allow specializers 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 to allow us to create FAQ question instances, it's not yet complete because we haven't declared the DITA @class attributes that define the specialization hierarchies for the new specialized 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>.