Re: PROPOSAL: Perform min/max validation of numeric types without con verting to numeric type

[ro...@us.ibm.com]

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
roddey@us.ibm.com



"Arnold, Curt" <Cu...@hyprotech.com> on 01/06/2000 09:26:38 AM

Please respond to xerces-dev@xml.apache.org

To:   "'xerces-dev@xml.apache.org'" <xe...@xml.apache.org>
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;
};