Take the 2-minute tour ×

Regarding to my other question: XML deserialize null elements?

I've got elements like these from a third-party server for API testing:

<Taxable />
<DefaultPurchasePrice />

I just realized that now I am confusing myself about whether elements like that represent null object or empty.

Talking about objects, they are same, null object normally means empty object reference right? But trying to map a XML element to a datafield/value, they could be different i.e null string is empty string, but for Decimal price or Boolean value, they are undefined which equal to empty, but will not be null, unless they are defined as nullable.

Again, the problem with my XmlSerializer is that wouldn't handle transfer an empty element like that. could I easily fix that in my code. Or should I ask people provide the XML have a well defined XML? Because seems that an empty XML element like that is undefined: it is here, but could be either null or empty doesn't matter for XML element itself? But for that element my code need figure out how to deal with that, unless I set all my C# class datafield as string type. Otherwise, if my code trying to directly map an empty or null XML element to a certain datafield, it will fail for sure.

I have to ask this question because I encountered XML have lots of those elements and for those special elements, my .NET XMLserialization code need to mapped those field as string and if the string is not empty, I case them into correspondent datatype, otherwise I set them to null. And I end up remove those empty element before I do my deserialization because it is much easier. But I do wandering: "What am I really doing in my code? Did I just remove null elements or empty elements? Because they are clearly different! But people writing that XML think they are same, because XML itself don't have concept of 'null', and some people argue that it is my responsibility to decide whether it is null or empty. But XML do enable you to represent 'null' elements in a clearer way


In the example I presented, those two elements clearly should be null rather than empty elements. XML don't really have a concept of null, but those elements could either be omitted (if they are null, don't put them into XML) or using better representation as mentioned be @svick. Or in other cases, empty elements should be used when they make sense. But not for Decimal or Boolean.

share|improve this question
An empty element tag is valid XML. How you interpret, null, empty or whatever, it is entirely up to you. –  fpmurphy1 Aug 30 '11 at 3:40
@fmurphy: that should be an answer... I'd upvote it –  Jim Garrison Aug 30 '11 at 3:42
@fpmurphy, so it is an empty element then? –  Paul L Aug 30 '11 at 3:48
@pstar: fpmurphy was quite clear. You have to decide, there is no standard interpretation. –  Jim Garrison Aug 30 '11 at 3:59
The XML specification doesn't define the semantics of your data. That's up to the specification of the particular vocabulary you are using. If that specification doesn't say what this construct means, then yes, it is ambiguous. If you don't have such a specification, then EVERYTHING in your XML is ambiguous. –  Michael Kay Aug 30 '11 at 8:08

2 Answers 2

up vote 8 down vote accepted

<Taxable />
<DefaultPurchasePrice />

what is this: null or empty element?

It is empty. It is semantically the same as:


The only "null" concept that exists in XML itself is a missing element. You can't specify an element and say that it is null, using XML's semantics. You must have some sort of schema (an explicit schema, such as DTD, XSD, or Schematron, or an implicit/logical schema) to do this.

This does not restrict an application that interprets the XML, though, or official XML-related technologies. For example, XSD has an xsi:nil="true" attribute. Even though you can apply some of these schema attributes to the XML, those attributes aren't "pure" XML; They are an addition supplied by XSD schemas.

This is a case where XSD was free to build its own semantics on top of the basic XML structure, and add an explicit nil where one didn't exist. This flexibility is considered an advantage of XML.

share|improve this answer
An another excellent explanation. Almost agree word by word. But 'xsi:nil = 'ture'' is a built in declarations for Xml schema, and you can using that to present a 'null' element. It is sort kind of like of saying that without any libraries, C# couldn't do anything. But again, my XML understanding is limited :D –  Paul L Aug 30 '11 at 23:39
@pstar: Clarified and corrected a bit. Please let me know if this is better, worse, or the same :) –  Merlyn Morgan-Graham Aug 31 '11 at 0:17
thank you, seems clearer. But I got one more question now. I am not sure about relation of xmlns:xsi and XSD, do I have to have xmlns:xsi as minimum to use XSD, and thus get xsi:nill and few other built-in attributes for free? –  Paul L Aug 31 '11 at 0:42
@pstar: Yes, you must add the namespace alias to use those. Here's a description straight from the standards recommendation document: w3.org/TR/xmlschema-1/#Instance_Document_Constructions –  Merlyn Morgan-Graham Aug 31 '11 at 18:41

I think this comes down to the fact that there is no default mapping between XML and the object model of your favorite language. Consider the following XML:

<Person Name="John">
        <Person Name="Jim" />
        <Person Name="Jenny" />

Does Person have properties (or fields) Father and Mother? Or does Person represent a collection that can contains objects of types Father and Mother (perhaps inheriting from abstract base type FamilyMember)? This is not clear from the XML, and it's up to you how you represent this in your object model. (The presence of schema would change that somewhat, but it still leaves room for interpretation.)

Similarly, the concept of null is not present in XML. On the other hand, the concept of empty element does not map directly to object model. And they are not the same, empty element still can have attributes and it has a “type” (element name).

Generally, I think good solution is to have a special XML element representing null (<Null />), but another solution might make more sense in your specific case.

share|improve this answer
Explained really well. What is another solution you mentioned in the last paragraph? –  Paul L Aug 30 '11 at 20:54
You could use the empty elemens like you mentioned. Or you could leave out that property completely. Or maybe even something like an attribute: isEmpty="true". –  svick Aug 30 '11 at 21:01
There is actually another good solution to representin 'null' (' xsi:nil="true"'), see this: stackoverflow.com/questions/774192/…. –  Paul L Aug 30 '11 at 21:10

Your Answer


