<?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>6695</bug_id>
          
          <creation_ts>2009-03-13 08:27:50 +0000</creation_ts>
          <short_desc>whiteSpace=collapse</short_desc>
          <delta_ts>2009-04-20 15:46:51 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>XML Schema</product>
          <component>Datatypes: XSD Part 2</component>
          <version>1.0/1.1 both</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Windows NT</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>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Michael Kay">mike</reporter>
          <assigned_to name="David Ezell">David_E3</assigned_to>
          <cc>cmsmcq</cc>
          
          <qa_contact name="XML Schema comments list">www-xml-schema-comments</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>24224</commentid>
    <comment_count>0</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2009-03-13 08:27:50 +0000</bug_when>
    <thetext>According to a message from Dieter Guthmann on xmlschema-dev today, at least one product (Liquid XML Studio) has interpreted the rules for whiteSpace=collapse to mean that if the input consists entirely of space characters, it is normalized to a single space.

The definition of &quot;collapse&quot; in 4.3.6 relies on the interpretation of the undefined terms &quot;leading&quot; and &quot;trailing&quot;, which means that this reading of the spec cannot be dismissed as perverse. (Can one be a leader if one has no followers?)

A more rigorous definition might be:

collapse:
  After the processing implied by replace, contiguous sequences of #x20&apos;s are collapsed to a single #x20, and any #x20 at the start or end of the string is then removed.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24369</commentid>
    <comment_count>1</comment_count>
    <who name="Dave Peterson">davep</who>
    <bug_when>2009-03-22 00:45:25 +0000</bug_when>
    <thetext>(In reply to comment #0)

&gt; A more rigorous definition might be:
&gt; 
&gt; collapse:
&gt;   After the processing implied by replace, contiguous sequences of #x20&apos;s are
&gt; collapsed to a single #x20, and any #x20 at the start or end of the string is
&gt; then removed.

I gather the question is whether an input of whitespace only (and at least one) should collapse to a single space character or to the empty string.  I don&apos;t think that proposed definition answers the question any better than the status quo version.  Assuming we *want* to have one space character remain, we should say something explicit, like &quot;; if the original string consisted of only whitespace, the final result is one space character&quot; (added just before the final period).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24697</commentid>
    <comment_count>2</comment_count>
    <who name="Dave Peterson">davep</who>
    <bug_when>2009-04-13 17:27:42 +0000</bug_when>
    <thetext>It appears that &apos;leading&apos; and &apos;trailing&apos; can be interpreted to require something &quot;in between&quot;, or not.  It&apos;s clear that the WG intended &quot;not&quot;:  E.g., consider hexBinary which has whiteSpace = collapse.  The element

   &lt;gorp xsi:type=hexBinary&gt;
   00
   &lt;/gorp&gt;

has its [actual value] the single-byte bit-string 00000000.  It would be very counterintuitive if

   &lt;gorp xsi:type=hexBinary&gt;
   
   &lt;/gorp&gt;

was invalid rather than having the empty bit-string as its [actual value].  (Note that if all whitespace were removed from each example, their [actual value]s *would* be 00000000 and the empty bit-string, respectively.)

Accordingly it appears clear that the intent in the spec is to interpret &apos;leading&apos; and &apos;trailing&apos; as *not* requiring something in between.

The editors propose to add, after the serntence beginning &quot;After the processing implied by replace&quot;:

    This means a string consisting entirely of whitespace is
    first replaced with a single space character (#x20) and
    then that character is removed, since it is considered to
    be both a leading and trailing character; the final result
    is the empty character string.

</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24852</commentid>
    <comment_count>3</comment_count>
    <who name="Dave Peterson">davep</who>
    <bug_when>2009-04-20 15:33:36 +0000</bug_when>
    <thetext>On 17 Apr the WG agreed to adopt the wording proposed in comment #0

&gt; collapse:
&gt;   After the processing implied by replace, contiguous sequences of #x20&apos;s are
&gt; collapsed to a single #x20, and any #x20 at the start or end of the string is
&gt; then removed.

to insure that there was no question whether or not collapsing a whitespace-only string resulted in an empty string.

Mike Kay, assuming you concur (since the fix is from your comment), please mark this issue CLOSED.

I will respond to the question raised by Dieter Guthmann on xmlschema-dev answering that the above is the correct result.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>