From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED]
Sent: March 30, 2006 18:40 PM
To: dev@xmlbeans.apache.org
Subject: RE: Nil vs. Null
I understand what you are saying. One principle that we followed in the XmlBeans APIs was that similar methods should have the same behavior regardless of the underlying Schema used. In other words, setNil() would always do the same thing, remove() would always do the same thing when present etc. It's much easier to explain it too: "what does setXXX(null) do? It removes the content of the element and adds an xsi:type attribute", rather than "well, if the Schema declares the element as not nillable and the element has maxOccurs <= 1 and minOccurs < 1, then do this, otherwise if maxOccurs > 1 and minOccurs < 1the do the other etc". In addition, remove() is also the only API that, well, deletes elements; also, we do not have a goal of generating valid documents regardless of what method calls are issued, that would be impossible.If you look at it through this perspective, I think that the decision to do what the code is currently doing seems reasonable. On the other hand, I also appreciate the fact that the usability of the generated classes is diminished in your case and that that is a very common case. I don't know yet what is the best way of addressing this issue though. We can't change the default way the generated classes behave at this point, because of backwards-compatibility concerns. Adding an option to generate the code differently is certainly an option, but it would be the first one that can influence the way the code is generated, so I am not keen on that either....Radu
From: McMillan, DouglasC [mailto:[EMAIL PROTECTED]
Sent: Monday, March 27, 2006 11:38 AM
To: dev@xmlbeans.apache.org
Subject: Nil vs. NullThere have been several posts over the last few years about the handling of nil and null values. The part of it that I was never fond of was the assignment of nil to non-nillable elements when a null was passed, as it causes the resulting object to fail validation. The only workaround for this seems to be manual field by field testing for null assignments.
After doing this for a few projects, I got a little irritated and updated SchemaTypeCodePrinter to unset a non-nillable element when a null value is passed. Is there any chance of this being included in the next release of the code, and if so, how would I go about submitting it?
An alternative thought would be to make the functionality switchable using the command line options, since it only affects generated classes. Thoughts?
Professional squirrel. Closed course. Do not attempt.
_______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
