Things my mother never told me about types and equality...

...or "Q. When is a float not a float? A. When it's a double"

Doubtless this has been the subject of other discussions before but it has
become important for developing the XBRL standard. Because of the way XML
Schema has defined its various types it seems it is not possible to use the
XML Schema specification directly to compare values of different numeric
types for equality even though such a comparison might seem intuitively
obvious. (For example I can't see how the XML Schema float 1E0 can be
compared against the XML Schema double 1E0). Maybe I am missing something
deep in the referenced IEEE spec on this but the link from the XML Schema
specification takes me to a table of contents at the IEEE site from which I
can get no further. In XBRL, however, it has become essential to know when
two items are equal.

I have prepared the attached discussion paper on which I would be grateful
to recive feedback from the XML Schema cognoscenti. You can safely ignore
the complications around "precision" and "decimals" that are mentioned but I
would really appreciate any comments about the proposed approach. I think
that, in a way, it goes some way towards coalescing the disparate numeric
XML Schema types. Of course, I may have reinvented the wheel here and, if I
have done so, I would appreciate any pointers to other work on the subject
since I would far rather reuse existing standards than invent possibly
diverging ones.

I haven't thought this all the way through yet but it seems to me that if we
have a properly defined notion of equality between values from different
value spaces then we also have an ordering or at least we are very close to
one. Any comments anyone?

Many thanks

Hugh Wallis


************************************************************************

If you received this e-mail in error please delete it and notify the sender as soon as possible. The contents of this e-mail may be confidential and the unauthorized use, copying, or dissemination of it and any attachments to it, is prohibited.

Internet communications are not secure and Hyperion does not, therefore, accept legal responsibility for the contents of this message nor for any damage caused by viruses. The views expressed here do not necessarily represent those of Hyperion.

For more information about Hyperion, please visit our Web site at www.hyperion.com