- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 8 Sep 2003 08:34:39 +0000
- To: "ext Jos De_Roo" <jos.deroo@agfa.com>
- Cc: "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>
The bottom line is this: 1. It is reasonable to expect folks to interpret the XML Schema spec such that spaces are not relevant for xsd:integer. After all, that was *our* interpretation to date, after alot of study. 2. It is for the XML Schema folks to clarify the interpretation of their spec. 3. If it is possible that our test cases are not correct, that the tests in question should in fact be positive tests, we should remove them until/unless we can be sure of their correctness (and that is what the WG decided to do during the telecon two Fridays ago). and *especially* 4. Whether or not " 3 " is or is not a valid lexical form for xsd:integer and/or whether or not whitespace processing is/may be a part of the L2V mapping of xsd:integer, that has *no* relevance to our spec as presently defined (with the changes agreed two Fridays ago, removing the fudge and test cases) and it is *not* for our spec to address the specific mehanics of XML Schema datatypes, even if it is in our charter to provide a compatible datatyping solution (which we have done). -- Our only actions should relate to the test cases. If the XML Schema WG says " 3 " is in fact a valid lexical form for xsd:integer, then our test cases are broken and should be fixed. If the XML Schema WG says that it isn't a valid lexical form, then the implementations which fail the tests are broken and should be fixed. If the XML Schema WG cannot provide an official clarification in a timely manner insofar as our process is concerned then the test cases *must* be removed. In *no* case is our design broken nor lacking, nor should *any* mention of whitespace processing be added normatively to our specs. Such issues are out of scope for our design, rightfully encapsulated in the abstractions of the RDF datayping model. Interoperability will be as consistent, precise, and easy to implement insofar as each datatype specification is clear and unambiguous. The XML Schema WG needs to clarify their own spec. Patrick _____________Original message ____________ Subject: Re: about " 3 "^^xsd:integer Sender: ext Jos De_Roo <jos.deroo@agfa.com> Date: Mon, 8 Sep 2003 08:10:09 +0000 Dan Connoly 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. Nothing about spaces, that's true. I have to admit that from an implementation point of view lexical spaces don't matter that much... -- Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/ PS In xerces-2_5_0 it is now possible to use an IntegerDV instead of DecimalDV for all numbers (to avoid Patrick's "1.0"^^xsd:integer case) but I will wait till Jena has it - my tests with replacing the /Jena-2.0/lib/xercesImpl.jar were successful, but my AskJena is otherwise not downwards compatible.
Received on Monday, 8 September 2003 01:35:46 UTC