In part I: 3.2.3.1 (getTypeChildren) & 3.2.4.1 (getTypeDescendants) state that if a typeId is provided, the type definition for that typeId must be included in the response.

In part 2, the feeds 6.5 (Types Children) and 8.6 (Types Descendants) do not seem to include the type definition (if one is specified). This contradicts part I.

If part 2 followed part 1, it makes sense for service document 'types' collection and 'typesdescendants' link. However, for type feeds referred to via rel 'down' (e.g. in type definition atom entry for retrieving child or descendant types), it's preferable not to include self.

Two options:
a) don't include self in Part I and Part 2
b) Part 2: split each of Types Children and Types Descendants into two resources (one includes self, the other doesn't).

For comparison, Folders are treated differently - getChildren, getDescendants and getFolderTree do not include self in Part I.