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 1627 - [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: Last Call drafts
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Jerome Simeon
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-15 10:08 UTC by Michael Dyck
Modified: 2007-01-16 17:29 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-15 10:08:47 UTC
4.7.1 Direct Element Constructors

Norm

"We start with the rules for normalizing a direct element constructors'
content."
    You'd get a more logical flow (top-down) if you started with rules
    3 and 4 (and most of the paragraph that precedes them).

"a direct element constructors' content."
    s/s'/'s/

"Literal XML character data (CDATA)"
    It would be better to say "CDataSections", if that's what you mean.
    (And if that's not what you mean, what *do* you mean?)

"is assumed to be processed directly at parsing level so it does not
require any formal treatment."
    It's not entirely clear what "processed" means.

"An element-content unit is ..."
    Make the sentence a definition?
    At least emphasize the phrase "element-content unit" somehow.

"a contiguous sequence of literal characters"
    Note that "contiguous" doesn't mean "maximal", which I think you want.

"literal characters (character references,"
    Insert "including" after open paren.

Example: "<name>Dizzy Gillespe</name>"
    "Gillespie", if you mean the trumpeter.

"After boundary-space is stripped"
    s/boundary-space/boundary whitespace/
    ("Boundary-space" is the name of the declaration and the policy, but
    not the stuff that gets stripped.)

"It contains one XML comment, followed by one enclosed expression ..."
    Occurrences of "one" in this sentence sound odd. Change to "a"/"an".

Norm / rule (1|2)
[[]]_ElementContent-unit
    This construct only appears on the LHS of mapping rules, so how would
    it ever be invoked? Perhaps, in Norm / rule 3 / RHS, the
    'ElementContent' subscript should be 'ElementContent-unit'.

    Use of the normalization-subscripts 'ElementContent-unit' and
    'ElementContent' seems to be backward.  That is, I would expect the
    'unit' subscript to be concerned with normalizing content units, and
    the other with normalizing the whole content. Swap 'em!

    Also, 'Unit' would be more consistent than '-unit'.

Norm / rule 2
"n > 1"
    This uses undeclared syntax for tacking a premise onto a normalization
    rule.

Norm / rule 2
"fs:item-sequence-to-node-sequence( ... )"
    The declaration for this function says that it takes a single
    argument (of type item*), so there should be an extra pair of
    parentheses around its current args. (As in the example following the
    rule.)

"We need to distinguish between multiple element-content units ..."
    If this is supposed to hark back to the second sentence of the
    previous para, change it to something like:
        "We need to distinguish the results of consecutive
        element-content units ..."

"the rule for converting sequences of atomic values into strings apply"
    s/apply/applies/

Norm / rule (3|4)
    Change "AttributeList" to "DirAttributeList".

    Also, change "[[ QName ]]_Expr" to just "QName".
    (The only LHS that the former matches is 4.2.4 / Norm / rule 3,
    and you don't want it to.)

"2. that character references have been resolved to individual characters
and predefined entity references have been resolved to sequences of
characters"
    Why would a PER resolve to a *sequence* of characters?  Change to:
        "2. that character references and predefined entity references
        have been resolved to individual characters"

    But actually, rule 5 looks like it *doesn't* assume this, since it
    includes mention of CharRef and PredefinedEntityRef.

"3. that the rule is applied to the longest contiguous sequence of
characters."
    This makes it sound like, "of the many sequences of characters, the
    rule is only applied to the longest one".

    Anyhow, this assumption appears to forget that the element's content
    has already been partitioned into element-content units, which
    guarantees that the assumption holds. So you can delete it.

Norm / rule 6
    Italicize 'DirPIConstructor'.

Norm / rule 7
    Italicize 'DirCommentConstructor'.

(completeness)
    You're missing a rule for [[ DirElemConstructor ]]_ElementContent,
    which probably just maps to [[ DirElemConstructor ]]_Expr.
Comment 1 Jerome Simeon 2006-04-16 19:47:44 UTC
Fixed as suggested. Among the main changes into the section:

* Now defines ElementContentUnit, with the corresponding grammar and examples at the beginning.
* Starts the normalization using rules 3/4 as suggested, then following with normalization rule for element content.
* Removed cases 2. and 3. in the bulleted list. Integrated 1. into the text.
* Aligned the notations with the section on attributes.

- Jerome
Comment 2 Michael Dyck 2006-09-20 08:00:38 UTC
In the 2006-06 CR, 'DirCommentConstructor' in Norm / rule 7 still needs to be italicized.
Comment 3 Jerome Simeon 2006-11-09 22:39:09 UTC
Fixed.
- Jerome