Hi, According to xsd specifications (http://www.w3.org/TR/xmlschema-0/), an element can be nil in XML only if a 'nillable="true"' attribute exists for that element in the xsd.
While attempting to de-couple Scout and jUDDI, we noticed that jUDDI data types do not (directly) obey this attribute. As a result, values can be set to null even though the xsd says otherwise. Due to the way code is marshaled in jUDDI, this is not noticed. For example: org.apache.juddi.datatype.setValue() can take a null value, and does not complain. The error gets masked however, because DescriptionHandler.marshal() simply doesn't create a description element if the description is null. Due to the way things are handled presently, as demonstrated above, the code using the Description class would still pass tests despite having attempted to set a non-nillable value to null. This is precisely what is happening in Scout. Scout calls setXXX() methods at times without checking if they are null. In many of the cases, the values ARE null, but this goes unnoticed because jUDDI masks the problem. Ideally, jUDDI datatypes should throw some kind of exception when the caller code attempts to set a null value where it is not allowed. Scout in turn, should have 'xyz != null' checks before setting something to xyz, if that something is non-nillable. Comments? Cheers, Deepak
