Say we are on a hypothetical platform where double's maximum value was 1E100
but the user either not interested in the value (just validation) or was
bringing the textual representation into a
symbolic math processor or into a MathML presentation document.
The schema author is unaware of this platform and writes a constraint like
<datatype type="someval" source="double">
<!-- for some physical reason the value can't exceed 1e200 -->
<maxInclusive value="1e200"/>
</datatype>
If you did conversion on a platform that used IEEE double or used the approach
that I described, then you would expect 0.9E200 to be legal and 1.1E200 to not
be legal.
However, if you used conversion on a platform where double ranged was limited
to 1E100, then there is no way have a different result for the range check for
0.9E200 and 1.1E200. You either have to
reject both or accept both.
A text comparision would avoid rounding issues. For example, if the schema
author indicated that there was a minExclusive limit of 1.0, a text comparison
would allow
1.00000000000000000000000000000000000000001 where conversion to a double would
have lost that trailing 1 and indicated that the value violated that range.
Avoiding use of the C RTL floating point facility should be a major plus. It
appears that Xerces-C on VC 6 is currently built to suppress initialization of
C RTL floating point since I have not been
able to coerce any of the text to double routines to work properly.
Definitely if we were needing to do any other floating point operations, then
conversion to a numeric type would be necessary. However, for validation, all
that is necessary is comparision and that
should be fairly simple to write robustly.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 06, 2000 12:40 PM
To: [EMAIL PROTECTED]
Subject: Re: PROPOSAL: Perform min/max validation of numeric types
without con verting to numeric type
I understand your objectives here; but, looking further down the road,
there might be complicated issues. One of the big advantages of Schema is
that the client program can know that say an attribute is an integer value
between -31.38913 and +34.1233. In many instances, they are going to use
this knowledge to convert that number to a binary themselves. If that
result does not agree with the result gained via the lexical comparison,
things could get wierd, right? So the lexical comparison of any text
encoded binary values would have to absolutely match the results that would
occur when the value is actually converted, or you might get conflicting
results.
So I guess a question is whether it is more important to be consistent on a
particular platform or not. If it is, then doing the conversion, warts and
all, would insure that consistent results are gained. By the time you write
the code to insure that you've handled all the platform specific rounding
issues in the lexical comparison, might you not have come back to the same
place you were attempting to avoid, just with more work?
For integral or cardinal values of course this is not such a big deal and a
lexical comparison would work. But if Schema ever allowed a statement like
(10 / 3) as a value in a range check, then similar issues would come up
again.
I don't know that any of will really be a big deal in the end. I'm just
playing Devil's Advocate so people will consider all the wierd angles.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/06/2000 09:26:38 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: PROPOSAL: Perform min/max validation of numeric types without con
verting to numeric type
I would recommend that when someone starts working on implementing min/max
validation of integers and reals that we attempt to implement the
comparision operation without converting the string into a
primitive numeric type. This would avoid problems with the C RTL has not
been initialized and avoid different validation behavior on different
machines. I also believe that it may be faster than
conversion to a numeric type and a numeric comparision. I think something
like the following would be effective (unchecked C++ code). If this type
of approach was successful, the XML Schema could be
greatly simplified by removing all the details of the implementation of
IEEE 754 from Schema and leave the binding to a specific implementation
type to the type-aware DOM initiative.
//
// the same class could be used for both real and integer types
//
class ValidationNumeric
{
public:
//
// string is assumed to stay valid for lifetime of this object?
ValidationNumeric(const XMLCh* string);
inline long getExponent() const { return m_exponent; }
bool getIsPositive() const { return m_isPositive; }
bool getIsNaN() const { return m_isNaN; }
bool getIsInfinity() const { return m_isInfinity; }
const XMLCh* getMostSignificantDigit() const { return
m_mostSignificantDigit; }
enum compareResult { isEqual, isLess, isGreater, isInvalid };
compareResult compare(const ValidationNumeric& other)
//
// first shot, logic might not quite be right
if(getIsNaN() || other.getIsNaN())
{
if(getIsNaN() && other.getIsNaN()) return isEqual;
return isInvalid;
}
if(getIsPositive())
{
if(!other.getIsPositive()) return isLess;
if(other.isInfinity())
{
if(isInfinity())
return isEqual;
else
return isGreater;
}
if(getExponent() > other.getExponent()) return isLess;
if(getExponent() < other.getExponent()) return isGreater;
//
// walk through both strings starting with most
significant digit (skipping over .'s)
}
...
}
bool operator>=(const ValidationNumeric& other)
{
compareResult result = compare(other);
if(result == isEqual || result == isGreater) return true;
return false;
}
private:
const XMLCh* m_mostSignificantDigit;
bool m_isPositive;
bool m_isNaN;
bool m_isInfinity;
long m_exponent;
};
