<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>1627</bug_id>
          
          <creation_ts>2005-07-15 10:08:47 +0000</creation_ts>
          <short_desc>[FS] editorial: 4.7.1 Direct Element Constructors</short_desc>
          <delta_ts>2007-01-16 17:29:03 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>XPath / XQuery / XSLT</product>
          <component>Formal Semantics 1.0</component>
          <version>Last Call drafts</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>CLOSED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>minor</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Michael Dyck">jmdyck</reporter>
          <assigned_to name="Jerome Simeon">simeon</assigned_to>
          
          
          <qa_contact name="Mailing list for public feedback on specs from XSL and XML Query WGs">public-qt-comments</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>4705</commentid>
    <comment_count>0</comment_count>
    <who name="Michael Dyck">jmdyck</who>
    <bug_when>2005-07-15 10:08:47 +0000</bug_when>
    <thetext>4.7.1 Direct Element Constructors

Norm

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

&quot;a direct element constructors&apos; content.&quot;
    s/s&apos;/&apos;s/

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

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

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

&quot;a contiguous sequence of literal characters&quot;
    Note that &quot;contiguous&quot; doesn&apos;t mean &quot;maximal&quot;, which I think you want.

&quot;literal characters (character references,&quot;
    Insert &quot;including&quot; after open paren.

Example: &quot;&lt;name&gt;Dizzy Gillespe&lt;/name&gt;&quot;
    &quot;Gillespie&quot;, if you mean the trumpeter.

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

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

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
    &apos;ElementContent&apos; subscript should be &apos;ElementContent-unit&apos;.

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

    Also, &apos;Unit&apos; would be more consistent than &apos;-unit&apos;.

Norm / rule 2
&quot;n &gt; 1&quot;
    This uses undeclared syntax for tacking a premise onto a normalization
    rule.

Norm / rule 2
&quot;fs:item-sequence-to-node-sequence( ... )&quot;
    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.)

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

&quot;the rule for converting sequences of atomic values into strings apply&quot;
    s/apply/applies/

Norm / rule (3|4)
    Change &quot;AttributeList&quot; to &quot;DirAttributeList&quot;.

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

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

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

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

    Anyhow, this assumption appears to forget that the element&apos;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 &apos;DirPIConstructor&apos;.

Norm / rule 7
    Italicize &apos;DirCommentConstructor&apos;.

(completeness)
    You&apos;re missing a rule for [[ DirElemConstructor ]]_ElementContent,
    which probably just maps to [[ DirElemConstructor ]]_Expr.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>9266</commentid>
    <comment_count>1</comment_count>
    <who name="Jerome Simeon">simeon</who>
    <bug_when>2006-04-16 19:47:44 +0000</bug_when>
    <thetext>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
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11882</commentid>
    <comment_count>2</comment_count>
    <who name="Michael Dyck">jmdyck</who>
    <bug_when>2006-09-20 08:00:38 +0000</bug_when>
    <thetext>In the 2006-06 CR, &apos;DirCommentConstructor&apos; in Norm / rule 7 still needs to be italicized.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12892</commentid>
    <comment_count>3</comment_count>
    <who name="Jerome Simeon">simeon</who>
    <bug_when>2006-11-09 22:39:09 +0000</bug_when>
    <thetext>Fixed.
- Jerome
</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>