8.2.3.1.2 (Static semantics of) Kind Tests

(presentation)
    The sub-subheads ("Semantics") are more prominent than the subheads
    ("Document kind test", "Element kind test", etc.).
    (leftover from last year, comment #218)

(Static semantics of) Document kind test

    Sem 1 / rule 3 / premise 2
    Sem 1 / rule 4 / premise 2
    "not(Type1 <: DocumentType or DocumentType <: Type1)"
        There's no need to introduce a metasyntactic 'or'.
        not( A or B ) = not( A ) and not( B ), so replace with:
            not(Type1 <: DocumentType)
            not(DocumentType <: Type1)
        (Note that this is what's done by the corresponding rules under
        element kind test and attribute kind test.)

    Sem 1 / rule 3 / premise 4
    Sem 1 / rule 4 / premise 4
    "Type2 <: empty"
        Prepend "statEnv |-".

(Static semantics of) Element kind test

    Sem 2 / rule 5
    "ElementNameOrWildcard TypeSpecifier"
        This is not a valid Formal Type.
        Change to "element ElementName TypeSpecifier".
    (leftover from last year, comment #223)

(Static semantics of) Attribute kind test

    Sem 3 / rule 5
    "AttribNameOrWildcard TypeReference"
        This is not a valid Formal Type.
        Change to "attribute AttributeName TypeReference".
    (leftover from last year, comment #226)

(Static semantics of) Processing instruction, comment, and text kind tests.

    (very last line of section)
    "If none of the above rules apply, then the node test returns the
    empty sequence and the following rule applies:
    statEnv |- test node() with PrincipalNodeKind of NodeType : empty"
        Presentationally, this looks like a judgment form declaration. It
        would be nice if you could at least make it *look* like an
        inference rule. E.g., have a single premise saying "otherwise".
    (leftover from last year, comment #229)

        But more importantly, consider the immediately previous rule:
        there can't be a case where *this* rule would apply but *that* one
        wouldn't.