Re: about " 3 "^^xsd:integer

>Dan Connolly wrote:
>>
>>  On Fri, 2003-09-05 at 10:15, Jos De_Roo wrote:
>  > > http://www.w3.org/TR/xmlschema-2/#integer says
>>  > [[
>>  > integer has the following ·constraining facets·:
>>  > ...
>>  > whiteSpace
>>  > ...
>>  > ]]
>>
>>  I don't see how that's relevant.
>>
>>  The lexical space of the integer datatype is specified thus:
>>
>>  [[[
>>  3.3.13.1 Lexical representation
>>  integer has a lexical representation consisting of a finite-length
>>  sequence of decimal digits (#x30-#x39) with an optional leading sign. If
>>  the sign is omitted, "+" is assumed. For example: -1, 0, 12678967543233,
>>  +100000.
>>  ]]]
>>
>>  Nothing about spaces.
>>
>
>Moreover (and this may simply be rehashing all the previous discussion,
>but it's news to me), the definition of the whiteSpace facet says:
>
>"4.3.6 whiteSpace
>
>[Definition:]   whiteSpace constrains the ·value space· of types
>·derived· from string such that the various behaviors specified in
>Attribute Value Normalization in [XML 1.0 (Second Edition)] are
>realized. The value of whiteSpace must be one of {preserve, replace,
>collapse}.
>
>preserve: No normalization is done, the value is not changed (this is
>the behavior required by [XML 1.0 (Second Edition)] for element content)
>
>replace:  All occurrences of #x9 (tab), #xA (line feed) and #xD
>(carriage return) are replaced with #x20 (space)
>
>collapse: After the processing implied by replace, contiguous sequences
>of #x20's are collapsed to a single #x20, and leading and trailing
>#x20's are removed.
>
>...whiteSpace is applicable to all ·atomic· and ·list· datatypes. For
>all ·atomic· datatypes other than string (and types ·derived· by
>·restriction· from it) the value of whiteSpace is collapse and cannot be
>changed by a schema author;..."
>
>So the whiteSpace facet is defined as constraining the *value space*,
>not the lexical space.

True; but XML Schema part 2 is often rather fuzzy 
about this distinction. For example, it remarks 
casually that applying a restriction to the value 
space 'thereby' restricts the lexical space 
(exactly how is not specified), and it does 
things like restricting the value space *by* 
restricting the lexical space (eg see the 
'pattern' facet).  And since it simply does not 
make mathematical sense to apply whiteSpace to 
the value spaces of most of the primitive 
datatypes, yet it is listed as a constraining 
facet on all of them, one might charitably think 
that what they must have meant here is that it is 
a constraining facet on the value space by virtue 
of being applied to the lexical space.  On the 
other hand, it is hard to see how the whiteSpace 
facet can possibly constrain the lexical space if 
that space is defined in the way that it actually 
is defined, as Dan C. points out, ie so that no 
whiteSpace is allowed in any case; and even if 
white spaces were allowed, it seems clear that 
the only coherent account of the lexical-to-value 
mapping would require that it make no difference 
to the value, so constraining the lexical space 
would not impose any constraint on the value 
space. Note also that the definition of 
whiteSpace starts by referring to "types derived 
from string"  - where it does make sense - but 
then without any explanation or discussion 
announces that it is applicable to all atomic 
datatypes.

In fact, overall, this entire discussion in XML 
Schema Part 2 does not make the slightest sense, 
rather like a lot of the rest of that document. 
Which is why I would prefer that we make as 
little reference to it as humanly possible.

>Assuming that's not a typo, it's not clear to me
>how any of the actions specified replace and collapse can be applied to
>the value space of xsd:integer, since the value space of xsd:integer has
>no occurrences of things like #x20's and so on.

Quite.

>What am I missing here?

You aren't missing anything, Frank. Welcome to XSD.

Pat
-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 8 September 2003 13:11:21 UTC