You need to decide whether you are thinking about XML as XML, or whether you are thinking about XML as a way to transmit Java (or other) object from here to there.
In XML, nillable permits the construction <myelement xsi:nil='true'/>
as an indicator of an explicit absent value, like an SQL NULL. This is semantically different from just <myelement/>
. And both are distinct from nothing at all. So, when looking at XML, you have to distinguish four cases:
<!-- nothing -->
<myElement attr1='true'>some content</myElement>
<myElement/>
<myElement xsi:nil='true'/>
If, on the other hand, you are primarily concerned with Java -- perhaps because you are using SOAP, then you need to think about how Java object map back and forth.
For any Java item that inherits from Object, JAXB and other mapping technologies need a way to deal with null values. Nillable is the way to do that. If you forbid nillable on something that can be an object, toolkits will annoyingly use an array to find a way to represent absence.
On the other hand, if you have an array, keep in mind that the array itself is an object, and can be null. So, every toolkit has to distinguish a zero-element array from a null.
On the other hand, if you have a primitive type (e.g. int
), nillable will lead to problems, since there is no mapping from xsi:nil to a primitive.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…