This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3895 - [FS] editorial: 4.7.1 Direct Element Constructors
Summary: [FS] editorial: 4.7.1 Direct Element Constructors
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard: consider third point for 1.1
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-30 20:52 UTC by Michael Dyck
Modified: 2008-09-01 00:11 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2006-10-30 20:52:00 UTC
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
Comment 1 Michael Dyck 2006-10-30 21:44:37 UTC
Also:
Norm / rule 5
[]_DirCharsUnits
    That should be []_DirCharsUnit (without the final 's'), the name I
    originally suggested back in Bug 1629, because it deals with a single
    element-content unit.
Comment 2 Jim Melton 2007-02-26 00:22:30 UTC
The fix for this bug does not appear in the Recommendation of 23 January 2007. 
It will be considered for a future publication (either an Errata document or
some possible future version of the specification). 
Comment 3 Michael Dyck 2008-08-25 02:38:22 UTC
(In reply to comment #0)
> 
> 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
> 

That was folded into the fix for E029.
Comment 4 Michael Dyck 2008-08-31 07:11:00 UTC
(In reply to comment #0)
> 
> "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."

That would probably be an improvement, but it isn't really erratum-worthy.
However, I'll consider it for FS 1.1.

Comment 5 Michael Dyck 2008-08-31 07:24:14 UTC
(In reply to comment #0)
> 
> Norm / example (3|4)
> <example>{ 1 }{ 2 }</example>
>     ...

These two examples were removed as part of the fix for FS erratum E029.
Comment 6 Michael Dyck 2008-09-01 00:11:11 UTC
The remainder of this issue has been entered as FS erratum E052, and the
proposed fixes have been committed to the source files for the next edition
of the FS document.  Consequently, I'm marking this issue resolved-FIXED,
and CLOSED.