[Bug 3895] [FS] editorial: 4.7.1 Direct Element Constructors

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3895

           Summary: [FS] editorial: 4.7.1 Direct Element Constructors
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


4.7.1 Direct Element Constructors

Intro

"are specified on the equivalent"
    s/on/in terms of/ ?

Notation 2

"a maximal contiguous sequence of literal characters (including character
references, escaped braces, and predefined entity references)"
    This sentence says that CRs, escaped braces, and PERs are "literal
    characters", but the FS's four other uses of the phrase indicate that
    these are not literal characters. For consistency with that usage, you
    could drop the parentheses and change "including" to a comma.

    Anyhow, the list should include CDataSections.

Norm

"We can now give rules for normalizing a direct element constructor's
content."
    Actually, from here to the end of the section properly belongs in
    4.7.1.3 Content. I suggest you move it there, and replace it with
    something like:
        "4.7.1.1 defines []_Attribute, 4.7.1.2 defines []_NamespaceAttrs,
        and 4.7.1.3 defines []_ElementContent."

"Adjacent element-content units are convenient because they permit ..."
    Sounds odd. Maybe delete "are convenient because they".

Norm / example (1|2|3|4)
    The Core CompElemConstructors are missing the
        "{" NamespaceBinding* "}"
    required by [67 (Core)] in 4.7.3.1.

Norm / example (3|4)
<example>{ 1 }{ 2 }</example>
    I think a better example would be
        <example>{1,2}{3,4}</example>
    which XQuery tells us is equivalent to
        <example>1 23 4</example>
    (and thus simultaneously shows spaces between items from the same
    enclosed expr, and no spaces between the contributions of adjacent
    enclosed exprs).  If we were to normalize it as
        element example { 1, 2, 3, 4 }
    then we would lose the information that allows us to insert spaces
    properly. Instead, we normalize it as
        element example { 1, 2, text{""}, 3, 4 }

before rule 5
"The following normalization rule takes the longest consecutive sequence
of individual characters"
    This makes it sound like, "of the many sequences of characters, the
    rule is only applied to the longest one". Instead, use the same
    phrase as earlier:
        "... takes a maximal contiguous sequence of ... "

"in boundary whitespace is processed"
    s/in boundary/in which boundary/ ?
    Maybe after "processed", say "as specified in 3.7.1.4^XQ"

Norm / rule 9
[[ { Expr1, ..., Exprn } ]]_ElementContentUnit
    The syntax of an EnclosedExpr is just { Expr }
    One fix would be to change each Expri to ExprSinglei,
    but it would be simpler to just say:
        [[ { Expr } ]]_ElementContentUnit == [[ Expr ]]_Expr

Received on Monday, 30 October 2006 20:52:52 UTC