RE: about " 3 "^^xsd:integer

I repeat again, as I said in 
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/0097.html
that since it is not clear whether " 3 " is or is not in the lexical
space of xsd:integer, we should remove all XSD specific test cases
and leave our design unchanged.

It is up to the XML Schema WG to clarify these issues, and applications
will be interoperable insofar as the XML Schema specifications can be
made clear and are consistently interpreted/understood by implementors.

*Our* design is IMO the right one, and whatever clarifications might
come from the XML Schema WG on this and similar issues will not force
any change to our design at all. Rather, our design highlighting the 
need for XML Schema to be clearer on these issues is a positive 
contribution to the XML community.

Patrick


> -----Original Message-----
> From: ext pat hayes [mailto:phayes@ihmc.us]
> Sent: 08 September, 2003 20:11
> To: fmanola@mitre.org
> Cc: w3c-rdfcore-wg@w3.org
> Subject: 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 Tuesday, 9 September 2003 02:03:37 UTC