This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
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).
(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.
(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.
(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.
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.