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 3233 - Space-separation in lists
Summary: Space-separation in lists
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard: medium, easy
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-09 10:07 UTC by Michael Kay
Modified: 2007-09-18 02:56 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-05-09 10:07:22 UTC
In 2.6.1.2, in the paragraph after the first example, it might be useful
to replace "space" by "whitespace", since we're talking about value spaces
and lexical spaces in the same breath. In fact, the way the spec explains
that the lexical representation of a list value is a whitespace-separated
sequence of literals representing the items is pretty obscure: the paragraph
that precedes the second example should come earlier in the section.
Comment 1 Dave Peterson 2006-05-19 22:42:42 UTC
(In reply to comment #0)
> In 2.6.1.2, in the paragraph after the first example, it might be useful
> to replace "space" by "whitespace", since we're talking about value spaces
> and lexical spaces in the same breath.

I don't know how that would help.  The sentence saying "space-separated"
is talking solely about the lexical space, and lexical representations of list
values *always* have multiple item lexical representations separated by one
space character, not arbitrary whitespace.  For better or for worse, whitespace
processing occurs *before* the literal is considered for membership in the
lexical space.  (Lists always have whitespace "collapse".)

>                                                 In fact, the way the spec explains
> that the lexical representation of a list value is a whitespace-separated
> sequence of literals representing the items is pretty obscure: the paragraph
> that precedes the second example should come earlier in the section.

Perhaps that sentence should read "Since ·list· items are separated at
space characters before the ·lexical representations· of the items are mapped
to values (and separating space characters are the only whitespace that can
occur), no whitespace will ever occur in the ·lexical representation·
of a ·list· item, even when the item type would in principle allow it."
Comment 2 Michael Kay 2006-05-22 12:29:58 UTC
These comments were editorial. I think that in the phrase "datatype whose ·lexical space· allows space " it's unreasonably demanding on your readers to use the word "space" twice within three words with totally unrelated meanings.
Comment 3 Dave Peterson 2006-05-22 13:48:03 UTC
(In reply to comment #2)
> These comments were editorial. I think that in the phrase "datatype whose
> ·lexical space· allows space " it's unreasonably demanding on your readers to
> use the word "space" twice within three words with totally unrelated meanings.

Ah!  We can certainly consider "datatype whose ·lexical space· allows space
characters".
Comment 4 Dave Peterson 2007-03-26 20:03:42 UTC
(In reply to comment #3)

> Ah!  We can certainly consider "datatype whose ·lexical space· allows space
> characters".

It has been pointed out to me that, since we are here talking about the item datatype rather than the list datatype, the datatype we are talking about may well (e.g., string) allow other witespace characters than the space character in its lexical space, so we are going with "allows whitespace."  I expect this will be approved at the FTF this week.
Comment 5 Dave Peterson 2007-03-31 04:17:45 UTC
On 30 March the WG agreed to change 'datatype whose ·lexical space· allows space' to 'datatype whose ·lexical space· allows whitespace' (i.e., simply changing the unadorned 'space' to 'whitespace') in the paragraph after the first example in 2.6.1.2.

This bug should have the Keyword 'decided', but it appears I don't have the authority to do so.  Bugzilla says "only the assignee or reporter of the bug, or a sufficiently empowered user may change that field".
Comment 6 C. M. Sperberg-McQueen 2007-09-18 02:56:20 UTC
The change proposed above was approved by the WG on 30 March 2007
at its face to face meeting in Cambridge.  It is now reflected in 
the status quo version of the Datatypes spec.  Accordingly, I am 
setting the disposition of this issue to RESOLVED / FIXED.

If the originator of the issue would examine the change and let 
us know whether it satisfactorily resolves the problem or not, 
we'd be grateful.   To signal that the resolution is acceptable, 
change the status of the issue to CLOSED.  Otherwise, to signal 
that it's NOT acceptable, change the status to REOPENED (and 
tell us what's wrong).

If we don't hear from you in the next three weeks, we'll assume 
that silence betokens consent, and close the issue ourselves.