Re: DOM conformance tests

[Andy Heninger]

The use of  unsigned values for the counts come straight from the IDL in the W3C DOM interfaces.  The use of signed values in the DOM Java bindings is because of the limitations of the Java language; there's no point in having signed counts in C++.   int vs long for the C++ counts is a question we flip-flopped on a couple of times.  IDL longs are 32 bits; C++ compilers that are current and would be reasonably able to build xerces all have 32 bit ints.  16 bit ints are history,  gone with the PDP-11 and 286.  As more 64 bit processors appear on the scene, an increasing number of C compilers have 64 bit longs.   Here's the IDL interface for CharacterData from the DOM spec   http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-FF21A306:   interface CharacterData : Node { attribute DOMString data; // raises(DOMException) on setting // raises(DOMException) on retrieval readonly attribute unsigned long length; DOMString substringData(in unsigned long offset, in unsigned long count) raises(DOMException); void appendData(in DOMString arg) raises(DOMException); void insertData(in unsigned long offset, in DOMString arg) raises(DOMException); void deleteData(in unsigned long offset, in unsigned long count) raises(DOMException); void replaceData(in unsigned long offset, in unsigned long count, in DOMString arg) raises(DOMException); }; Andy Heninger IBM, Cupertino, CA [EMAIL PROTECTED]       Curt Arnold wrote, The other two conformance issues were with negative values for the count argument of characterData.substringData() and characterData.deleteData().  The DOM spec states that negative values for the count value should throw an INDEX_SIZE_ERR exception.  In Xerces-C, the arguments are defined as unsigned int which results in the negative values in the tests being interpreted as very large values.   In a perfect world, it would probably be best to remove the unsigned qualifiers from the arguments so that the behavior would parallel that of the Java implementation.