Dictionaries with null values crash serializer about yaxlib

[304NotModified]

PS @axunonb Nice logo!

[axunonb]

Looks like a duplicate to https://github.com/sinairv/YAXLib/issues/45 which was fixed and closed.

[304NotModified]

Any idea which version it has been fixed?

[sinairv]

I'm not quite sure. It's probably gone out with 2.14 or 2.15.

[axunonb]

In version 2.15 the following test would not throw a NullReferenceException any more but it would fail. It's not part of the unit tests.
Expected: null
But was: <System.Object>

[Test]
public void DictionaryWithNullValue()
{
    const string theKey = "TheKey";
    var d = new Dictionary<string, object>() {{ theKey, null}};
    var serializer = new YAXSerializer(typeof(Dictionary<string, object>), YAXExceptionHandlingPolicies.DoNotThrow, YAXExceptionTypes.Warning, YAXSerializationOptions.SerializeNullObjects);
    var got = serializer.Serialize(d);
    var gotDes = serializer.Deserialize(got) as Dictionary<string, object>;
    Assert.AreEqual(d[theKey], gotDes[theKey]);
}

[304NotModified]

@axunonb do you mean it's fixed in 2.15 and unit tested? Or is the unit test not yet in the code?

[axunonb]

Unfortunately not yet part of the unit tests.

[304NotModified]

Ah well so if you could PR this unit test, then we can for sure close this one :)

Test looks good :)

@sinairv or should YAXExceptionHandlingPolicies be set to something else?

[sinairv]

The test is failing in the build. See AppVeyor logs.

[axunonb]

Regarding this issue and https://github.com/sinairv/YAXLib/issues/50 I'd like to open a discussion about introducing an YaxIsNullable attribute (similar to this).

The idea expressed in pseudo code was:

Case 1:

Serialization:

if (class member has value of null) && !typeof(string) && !typeof(NullableValueType)
{
    if YAXDontSerializeIfNull
    {
	    do not serialize
    }
    else if YaxIsNullable
    {
        serialize with xsi:nil = "true"    
    }
}

Deserialization:

if ((element for class member is missing) || ((element has xsi:nil = "true") && (member IsNullable))
{
    deserialize as null
}

Case 2

Serialization:

if (class member has value of null) && (typeof(string) || typeof(NullableValueType))
{
    if YAXDontSerializeIfNull
    {
        do not serialize
    }
    else if YaxIsNullable
    {
        serialize with xsi:nil = "true" 
    }
    else
    {
        serialize as empty
    }
}

Deserialization:

if ((element for class member is missing) || (element for class member is empty) || (element has xsi:nil = "true"))
{
   if (member is (typeof(string) || typeof(NullableValueType || has YaxIsNullable))
   {
       deserialize as null
   }
   else
   {
       throw exception
   }
}

For classes implementing IList which have the new YaxIsNullable attribute, null values would be serialized explicitly with xsi:nil = "true", and be deserialized like above.

What do you think?

[sinairv]

This seems quite reasonable to me. I particularly liked usage of standard xsi:nil here. I just have a couple of questions/concerns:

1. I didn't quite get why it should allow strings and nullable value types to produce empty elements, but not for other complex types.
2. We need to have a strategy for members serialised as attribute. For the case of those members serialised as an XML element adding the xsi:nil attribute is possible. But it's not the case for attributes. One possible strategy (that I personally have mixed feelings about it) is once an attribute is nullable and null, it's going to be turned into an XML element to accomodate the xsi:nil attribute. Not ideal but a possible approach. What do you think?

[304NotModified]

I like this discussion but IMO it should be in a new issue as it was hard finding it again. This issue should be closed.

Also what about NOT serializing anything for null values? (no element at all)

[axunonb]

@sinairv

why it should allow strings and nullable value types to produce empty elements

Good point. The idea was that only the YaxIsNullable attribute and null strings should produce the xsi:nil = "true".

But it's not the case for attributes.

Yes, unfortunately, and I share your mixed feelings about turning attributes into elements.

[axunonb]

Alternative:
What if we dropped decoration with YAXDontSerializeIfNull completely and follow @304NotModified's comment: Turn the default behavior upside down and never serialize null, neither as an element, nor as an attribute. Looks clean and simple, and I really like it. But it would be a breaking change - for a good reason, though.

For those who wanted to serialize null explicitly (which could be appreciated by humans editing XML), following the "upside down" strategy sth. like YAXExplicitlySerializeIfNull could be introduced for elements, leading to serialization with attribute xsi:nil = "true". And for attributes: Making xsi:nil = "true" a "special value" feels as "mixed" as turning attributes into elements, doesn't it? I'd rather have no explicit null for attributes, because it's not covered in XML definition.

[304NotModified]

@axunonb I see the test DictionaryWithNullValue now succeeds nowadays. I'm doubting if we should close this one

[axunonb]

@axunonb I see the test DictionaryWithNullValue now succeeds nowadays. I'm doubting if we should close this one

To good to be true - null requires some devotion, see #50 (comment) - leave open for now

[axunonb]

@304NotModified Serializing to/from this XML

<DictionaryOfStringObject>
  <KeyValuePairOfStringObject>
    <Key>TheKey</Key>
  </KeyValuePairOfStringObject>
</DictionaryOfStringObject>

works. Value is missing in XML, thus treated as null. All okay, so let's close this issue.