4.7.1 Direct Element Constructors

Norm

"Literal XML character data (CDATA) is assumed to be processed directly at
parsing level so it does not require any formal treatment."
    I think it's a bad idea for the FS to assume that the parsing phase
    does anything but parse. Instead, I don't see any problem with the FS
    treating CDataSections the same way it treats CharRefs and
    PredefinedEntityRefs.

"The normalization rule for a contiguous sequence of characters assumes:"
    1. boundary whitespace handling
    2. non-literal character resolution
    Rather than just assuming that this processng has occurred (at some
    stage and in some way that's disconnected from the formal semantics),
    it would be better to explicitly hook it into the formal semantics.
    See below.

Norm / rule 5
fn:codepoints-to-string((Char | "{{" | "}}" | CharRef | PredefinedEntityRef)+)
    You can't just plop down a hunk of element content as the argument in
    a function call: it isn't well-formed syntax. E.g., you could get
    something like
        fn:codepoints-to-string(-0A )

    Instead, I suggest:

        [[ DirCharsUnit ]]_ElementContent
        ==
        text { [[ DirCharsUnit ]]_DirCharsUnit }

    where []_DirCharsUnit is defined (in prose) to:
        a. normalize line-ends?
        b. handle boundary whitespace
        c. resolve non-literal characters (CharRefs, PredefinedEntityRefs,
           CDataSections, and escaped-braces)
        [reference XQuery 3.7.1.3]
        and then express the result as a StringLiteral (or any other
        Core Expr that yields the same value, I guess).