W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 1999

More on Datatypes

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Thu, 24 Jun 1999 17:01:11 -0600
Message-ID: <61DAD58E8F4ED211AC8400A0C9B468731AADD4@THOR>
To: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>

It should be possible for a derived datatype to indicate that group
separators (commas) are not allowed and that parenthesis may not be used to
indicate negative numbers.  Basically, a schema author should be able to
restrict the allowable lexical representation so that it is compatible with
Standard C or FORTRAN conversion routines.

I don't think it is possible to have one datatype support multiple
locale-specific representation of numbers.  I'm not aware of any standard
manner for a processor to determine what locale the document was authored
for (which could be different than the locale of the current machine) and
the processor would not know if "1.000.000,00" is an error unless it knew
what locale the document was intended for.  If it was allowed, there should
be a mechanism to suppress localization.

However, it would be good to be able to produce locale-specific datatype
files and to produce locale-specific schemas by simply changing the URI
associated with a schemaAbbrev (A one line change vs a Global-Search and

One approach a document author could take on this is to use a strongly-typed
and fixed locale attribute to specify the value used accessed for
calculations and use an string typed element content for the presentation
form that could follow the locale of the intended reader.  I.e.

<value val="3.1415926">3,1415926</value>


The presence of the E and exponent should be optional (at least by default).
I think that the use of group separators and negative number format should
have the same default as decimal and integer, but could be made more or less
restrictive by additional elements in the lexicalRepresentation element.
Received on Thursday, 24 June 1999 19:02:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:45 UTC