At present, the data dictionary page has special logic for extensions. The purpose of this special logic is to avoid inheriting the default name, definition, usage notes, etc. for all extension slices in the data dictionary view, because that would be totally useless. However there are three issues with the current logic:

1. It's not an extension-specific issue. The logic should be based on whether you're looking at slices of any sort that have a profiled type definition, not only when you're looking at extensions

2. The current logic ends up suppressing any inline comments that have been provided.

3. The current logic isn't consistent across all views and isn't reflected in the snapshot

Proposal (based on previous discussions):
a) When generating the snapshot for a slice, if the root slice element declares a type and the type is resolvable, that should be treated as the "base" for the purposes of determining the expansion. If the type is not available, the snapshot generation process should use the base type, but spit out a warning message.

b) Remove all slice-specific and extension-specific rendering logic from the different generated views

Rationale: The content for the base definitions, usage notes, etc. will be visible in the "slice definition" elements, so skipping these and drawing information from the profile declared on each set of slicing elements will not result in any lost information. And it will always provide more contextually appropriate information. However, we can't just grab information from the profile, we need to integrate it with any in-line constraints. And that means we need to use the snapshot generation logic. Doing this will also simplify rendering logic - which will make it easier for others who want to come up with additional rendering widgets.