views:

431

answers:

4

I'm implementing IXMLSerializable in one of my classes. It contains a few numeric properties that are nullable (int? double? etc..)

What is the correct way to serialize/serialize these through IXMLSerializable? Here's what I'm doing now, which works, but obviously does not seem like the correct way to do it.

void IXmlSerializable.WriteXml(XmlWriter writer)
{
    ...

    if (this._PropName == null)
    {
        writer.WriteElementString("PropName", "NULL");
    }
    else
    {
        writer.WriteElementString("PropName", this._PropName.ToString());
    }
    ...
}

void IXmlSerializable.ReadXml(XmlReader reader)    
{
    string tempStr;
    ...

    reader.ReadStartElement("PropName"); 

    if (tempStr != "NULL")
    {
        this._PropName = double.Parse(tempStr);
    }
    else 
    {
        this._PropName = null;
    }
    ...
}

Update: It was asked that I give a little background as to why I am implementing IXmlSerializable. I'm working on a program for architectural design, where I need a class that represents a collection of Floors. Each Floor has properties such as Floor.Area area, Floor.Height etc. The elevation of the floor, however, is defined by the sum of the floor heights below it. So whenever a Floor.Height property changes or the FloorCollection is modified the elevations of the Floors are re-cacluated.

My FloorCollection class, which I need to serialize, inherits from BindingList. If I try to serialize this class directly it will serialize the collection of floors, but not any properties or fields in the class. See my previous post on this.

Now I'm trying to add the ability to restrict the maximum height, maximum top elevation, and minimum bottom elevation of the building floors in the collection. So I'm using nullable doubles to represent these restrictions, where a null value means unrestricted. The elevation properties can be positive, negative, or zero. So there needs to be an alternate state, null, that identifies when there is no restriction.

Now that I think about it might be easier overall to just have a separate Boolean value that identifies if there is a elevation/height restriction, and then a regular double property that identifies what the restriction is if it is enabled.

+2  A: 

Omit the element if it's null.

edit

Consider what would happen if you made a new version that added a property. If you then deserialized a copy of an old version, the new element containing the new property would be missing, so you would correctly leave the property uninitialized, as null. This is the same logic, extended to cover the present tense.

edit

For information on how to tell XmlSerializer to omit a null property without writing a custom serializer, check out this. Also, given the background information, while I still prefer omission to xsi:nil, I now think the latter is an acceptable solution.

Steven Sudit
A: 
void IXmlSerializable.WriteXml(XmlWriter writer)
{
  if (this._Foo == null)
  {
    writer.WriteStartElement("Foo");
    writer.WriteEndElement("Foo");
  }
  else
  {
    writer.WriteElementString("Foo", this._Foo.ToString());
  }
}
Tullo
+1  A: 

You can write a null:

writer.WriteElementString("Test", null);

It will just result in an element like <Test/>

Or to be a little more specific about the null value you can use the xsi:nil attribute:

const string xsiNs = "http://www.w3.org/2001/XMLSchema-instance";
using (XmlWriter writer = XmlWriter.Create(Console.Out))
{
  writer.WriteStartElement("Test");
  writer.WriteAttributeString("xsi", "nil", xsiNs, "true");
  writer.WriteEndElement();
}

which will result in <Test xsi:nil="true"/>

STW
+1 for bringing up xsi:nil. I probably wouldn't use it in internal serialization, but I've certainly used it as part of more formal, external data exchange, particularly over SOAP.
Steven Sudit
I think <Test/> is just fine. But how do I read that back in as either a value or null?
Eric Anastas
You'd need a custom deserializer, which sounds like too much trouble.
Steven Sudit
+1  A: 

You want to always write the XML for the property, but if the property value is null you want to include an xsi:nil="true" attribute.

void IXmlSerializable.WriteXml(XmlWriter writer)
{
    ...

    if (this._PropName == null)
    {
        writer.WriteStartElement("PropName");
        writer.WriteAttributeString("xsi", "nil", "http://www.w3.org/2001/XMLSchema-instance", "true");
        writer.WriteEndElement();
    }
    else
    {
        writer.WriteElementString("PropName", this._PropName.ToString());
    }
    ...
}

You are also probably going to want to write an xsi:type="xsd:datatype" attribute, where xsd is the http://www.w3.org/2001/XMLSchema namespace. This will allow you to read the data type back in during deserialization to know if (and how) to convert the value.

Scott Dorman
+1 for xsi:nil, -1 for insistance on xsi:type. There's certainly a place for fully self-describing data, but serialization often isn't it.
Steven Sudit
@Steven Sudit: I disagree. Look at any datacontract serialized XML and you will almost certainly see type information.
Scott Dorman
@Scott: To be honest, I'm really not sure what Eric's intent here is. I went on the assumption that they wanted to flatten a type down to a string for persistence, as in a database. If so, then null=omitted is a good answer. But if they're using the class in WCF, your answer makes more sense. I asked Eric what his goals were; maybe that'll help sort this out.
Steven Sudit
See my update above. I'm writing a plug-in for a program where I can write data to strings attached to the native object in the file. So any of my custom objects need to be able to be serialize to a string so it can be saved to and reinitialized from the file the user is working in.
Eric Anastas
For what it's worth, I still don't see the value of xsi:type here, but I'm fine with xsi:nil.
Steven Sudit