Use of "unsigned" for non-enumeration values

Except when there is need for that extra bit of range, it seems undesirable
to make integer arguments or writable attributes that are not enumerations
"unsigned".  It doesn't matter in Java or JavaScript, since neither supports
the concept of unsigned numbers.  It does, however, make implementations in
other language either fail differently or incorrectly succeed, since C and
C++ will transparently convert a negative signed number into a large
positive number.

Obviously, it is too late to change the existing L2 and below methods, but
we should avoid adding any more problems.

There did not seem to be any examples in Core, Load/Save.

In ASLS:

minOccurs and maxOccurs in ASModel.createASContentModel()
ASObjectList.length 
ASObjectList.item(index)
ASNamedObjectMap.length
ASNamedObjectMap.item(index)
ASContentModel.minOccurs
ASContentModel.maxOccurs
CharacterDataEditAS.*(offset,count)

In Xpath:

XPathResult.snapshotItem(index)
XPathResult.snapshotLength   
  not really necessary since it is read-only, but for consistency

In none of these cases does it appear that range is an issue.  Java and
Javascript implementions will have to raise an appropriate exception when
negative values are passed.  Encouraging other bindings that support
unsigned numbers to silently treat negative values are large positive values
isn't beneficial.

Using signed values for maxOccurs would have the benefit of allowing the
more accessible -1 to be used for "unbounded" instead of Integer.MAX_VALUE.

Received on Thursday, 28 March 2002 18:33:21 UTC