(In reply to comment #0)

> While 3.3.3.1 goes to some lengths to give a respectably formal definition of
> the value space of xs:decimal, 3.3.4.1 makes no serious attempt to do so for
> xs:precisionDecimal.

This comment surprises me, since decimal's value space is described as a
subset of the real numbers, and precisionDecimal's value space is described
as a specific set of constructed objects, whose properties are carefully defined.

>                              Part of the problem, I think, is that there is a hint that
> the data type has "floating point" characteristics, which isn't actually
> carried through in the definition. If the value space contains all decimal
> numbers with trailing zeros considered significant, a "floating-point"
> implementation is likely to restrict this infinite space to a subset containing
> say N consecutive non-zero digits anywhere, while a "fixed-point"
> implementation is likely to restrict it to a subset containing N digits before
> and F digits after the decimal point.

Traditional "fixed-point" datatypes are isomorphic to the result of fixing the
maxScale and minScale at the same value, thereby essentially fixing the
number of fractional digits in lexical representations (or perhaps in the
base-two representations used in the computer).  Traditional "floating-point"
datatypes fix the number of "significant" digits in lexical representations.
We have provided for such a restriction using the totalDigits facet; we believe
that a "minTotalDigits" would not be useful often enough to be worth
implementing.

The precision we call "arithmetic" refers to precision sometimes expressed
by "plus or minus some specific amount"; for some precision systems it
can be expressed by the fractional digits of a decimal numberal.  OTOH,
the precision that might be called "geometric" refers to precision sometimes
expressed by "plus or minus some percentage"; it is not easily expressed
with a single numeral that also specifies the value of the approximation.
But closely related is what, for want of a better name, might be called
"floating-point precision", and is specified by the total significant digits
used in the numeral; it is "arithmetic in the small but geometric in the
large".  In traditional "floating-point" datatypes, this floating-point
precision is fixed or at least limited; in traditional fixed-point datatypes
the arithmetic precision is fixed.  In precisionDecimal, neither arithmetic
nor floating-point precisions are fixed or limited.

I think the main thrust of this point is that whereas xs:decimal refers to "the set of numbers that can be obtained by dividing an integer by a non-negative power of ten, i.e., expressible as i / 10n where i and n are integers and n ≥ 0", xs:precisionDecimal refers to a number of properties of the value, one of which (the most important of which!) is simply "a decimal number", not further elaborated.

The other part of the problem, I think, is that defining the infinite value space doesn't aid our understanding of the semantics of the data type all that much. We need to understand something of the mechanisms used to restrict the value space, and of the operations that are applicable to the data type.

(There's a real procedural problem here in trying to define a data type in XML Schema and then lobbing it over the fence to QT to define some suitable operations. I personally have no idea how to define an arithmetic that is sensitive to the "precision" component of these values, yet that is presumably what QT are expected to do.)

Mike Kay writes:

> (There's a real procedural problem here in trying
> to define a data type in XML Schema and then
> lobbing it over the fence to QT to define some
> suitable operations. I personally have no idea how
> to define an arithmetic that is sensitive to the
> "precision" component of these values, yet that is
> presumably what QT are expected to do.)


Yes in principle, but in practice we're defining this type with the full intention that it be (nearly) isomorphic to the one being defined in IEEE754r, and as with binary floating point, the ieee draft does provide a useful suite of operations (see http://754r.ucbtest.org/drafts/754r.pdf), and in fact a high level but useful overview is available in the 754 wikipedia page:  http://en.wikipedia.org/wiki/IEEE_754r#Operations.  Note that the draft specification itself says:

" Each of the computational operations specified by this
standard, except those identified as reduction operations, shall be performed
as if it first produced an intermediate result correct to infinite precision and with unbounded range, and then coerced this intermediate result to fit in the destination's format (see Sections 4 and 7). Section 6 augments the
following specifications to cover ±0, ±, and NaN; Section 7 enumerates
exceptions caused by exceptional operands and exceptional results."

I think the implied relationship covers both the question of the general motivation and intended tie to real world semantics for the type, as well as the more formal specifics of what an appropriate suite of operations would be.

This seems to me to be a situation that's at least as good as for the Schema 1.0 types such as float.

Noah

(In reply to comment #2)
> I think the main thrust of this point is that whereas xs:decimal refers to "the
> set of numbers that can be obtained by dividing an integer by a non-negative
> power of ten, i.e., expressible as i / 10n where i and n are integers and n
> ≥ 0", xs:precisionDecimal refers to a number of properties of the value,
> one of which (the most important of which!) is simply "a decimal number", not
> further elaborated.

Ah, I see.  Perhaps we should note somewhere that a decimal number is a number
that can be so represented.  I didn't think we had to explicitly define it, but I'm
sure the editors will consider doing so.  Do we need also to define integer?

> The other part of the problem, I think, is that defining the infinite value
> space doesn't aid our understanding of the semantics of the data type all that
> much. We need to understand something of the mechanisms used to restrict the
> value space, and of the operations that are applicable to the data type.

The mechanisms that we provide to restrict the value space are the various
applicable facets.  They are all well-defined, I believe.  Recognizing that any
infinite datatype cannot be fully represented in a finite machine, we prescribe
that implementations can be partial, and provide that a partial implementation
must make it known that it cannot handle a given value when it tries to do
something that requires knowing that value precisely.

> (There's a real procedural problem here in trying to define a data type in XML
> Schema and then lobbing it over the fence to QT to define some suitable
> operations. I personally have no idea how to define an arithmetic that is
> sensitive to the "precision" component of these values, yet that is presumably
> what QT are expected to do.)

I've seen several different ways of handling precision in calculations, none of
which are best for all applications.  Barring some extremely complicated
mechanisms, QT might simply compute the operation on the numericalValues
as would be done for (non-precision) decimal values, then use some specific
algorithm to impute a precision for the result.  It is my impression that most
users that want to be able to handle precision nonetheless tend to ignore it
when calculating.  They want it mostly for recording uncomputed values, such
as measurements taken in the real world.

(In reply to comment #2)

> The other part of the problem, I think, is that defining the infinite value
> space doesn't aid our understanding of the semantics of the data type all that
> much. We need to understand something of the mechanisms used to restrict the
> value space, and of the operations that are applicable to the data type.

Well, specifying operations isn't something we pretend to do; we don't even say you must have an addition on decimal, for example.  We leave that to users who have their own semantics tied to the name of the datatype.  Mostly, we only care about an order.

More to the point, however:  the precisionDecimal datatype captures aspect of both "fixed precision" and "floating-point precision":  If you lock the fraction-digit count to one value, you have a traditional fixed-point datatype; putting a max on the total-digit count makes it finite.  If you put a max on the total-digit count, you get a floating-point datatype; a max and min (not the same) on fraction-digit count makes it finite.  (Locking the total-digit count to a single value would produce the "normalized numbers for that max--754 terminology--but we haven't see any value in doing so.)  Were we working with radix-2 digit counts, we could get the value spaces of float and double by using appropriate limits (the only thing missing would be the rounding of lexical representations to the nearest value in the value space).

The WG discussed the following at the June 2007 f2f:

We will outline our possible plan to QT.

WG suggestion from the June 2007 f2f meeting:

(the previous note should have been...)

We accept this issue, and expect that we will make the spec crisper
with regard to what's required to implement, and possibly move supporting
material to either an appendix or a note.

This comment has three components:

1.  Precision needs better explanation.  This is covered in bug 3248; further discussions will be there.

2.  "decimal number" needs better explanation.  This is related to bug 3226; further discussions will be there.

3.  Question how other users can figure out how to implement appropriate operations.  This part of the original bug will remain under this bug number.

It appears (I could be wrong) that the essential point remaining here
concerns the clarity of exposition, not the conformance rules for
precision decimal.  Appearances could be deceiving, but on the strength of them
I am marking this issue editorial.  This will have the effect that we
may be able to deal with it after going to Last Call.

The WG approved the fix in http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.dp090225.html with one amendment.  The amendment has been incorporated in the XML master, and is awaiting republishing of a status quo document.

The wording proposal mentioned in comment 10 has been integrated
into the status-quo version of the Datatypes document, so I'm marking
this issue RESOLVED / FIXED.

Michael, if you would convey this result to QT and close or reopen the
issue accordingly, it would be helpful.  If we don't hear from you by
the end of the week, we'll assume you and they are happy.