[Bug 2970] Datatypes 2006-02-17 WD: merge precisionDecimal and decimal

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2970





------- Additional Comments From davep@iit.edu  2006-03-03 02:44 -------
(In reply to comment #0)
> Adding xs:precisionDecimal is clearly a big change for 1.1. But given that, why be so conservative 
with 
> xs:decimal? Like adding a new datatype, expanding the value and lexical spaces for xs:decimal (e.g., 
> INF, 2.1E-2) doesn't impact existing uses. Old valid decimals are still valid.

Agreed, this part would be be relatively easy--although there are technical details that would, for 
example, require recasting a number of facet functions, and the limits we set for minimum partial 
implementations.

> Furthermore, why not have xs:precisionDecimal be the base type of xs:decimal? This requires 
widening 
> the xs:decimal value/lexical spaces, as above, and having the xs:decimal mapping choose a 
particular 
> value for the precision property. 

We did work out completely the necessary description of the way the mapping could be defined, and 
the specialized facet(s) that would have to be introduced to cause this kind of derivation, but we 
decided there was too much machinery and too much disruption to the organization of our datatypes.  
At least that is my perception of why the WG chose not to do this.  At least I can assure you that the 
idea was carefully considered; it was not accidental that it wasn't done.

> I know it is undesirable for a type to have a different lexical mapping than its base type, but nearby 
> xs:integer already has that defect. 

I don't believe integer has anything unusual any more in its lexical mapping.  The only magic is in the 
canonical mapping, which is strictly advisory and no longer used in schema processing.

>                                               One could even argue that many xs:string types also have the same 
> issue via the whitespace facet. For instance, some lexical representations will produce different 
values 
> for xs:token than they produce for xs:string.

Not true.  You're thinking of character strings like ' a ', but that character string is *not* in the lexical 
space of token.  If that character string occurs between the start- and end-tags of an element that is 
typed token, the leading and trailing whitespace will be stripped first, and then the resulting string ('a') 
is the lexical representation.  Whitespace processing happens before candidacy as a lexical 
representation is considered.

Received on Friday, 3 March 2006 02:44:56 UTC