Binary resource returned from Update will throw a Null reference error trying to SerializeToXmlString

[brianpos]

Describe the bug
When serializing a Binary resource to XML a Null reference is thrown.
This is due to the children() function returning all the children without considering the version of fhir being processed.
Data and Content hold the same data, but are apprpriate in different versions, and the ReadBinaryFataFromMessage in the HttpContentParsers sets both.

firely-net-sdk/src/Hl7.Fhir.Base/Rest/HttpContentParsers.cs

Line 203 in 963660e

result.Data = result.Content = await message.Content.ReadAsByteArrayAsync().ConfigureAwait(false);

Hence when hit in the PocoElementNode constructor the element definition for one of them isn't found and crashes.

Note: Create does not do this... as it doesn't detect that the resource type was for a Binary!
(so create is done using the resource format rather than a binary stream)

To Reproduce
Steps to reproduce the behavior:

        [TestMethod]
        public void SerializeBinaryXml()
        {
            // This test verifies that the serialization of a resource with changed between
            // fhir versions can be serialized correctly
            var binResource = new Binary
            {
                ContentType = "text/plain",
                // yes this is the wrong field for R4 (should use data there)
                Content = System.Text.Encoding.UTF8.GetBytes("some random content")
            };
            var xml = new FhirXmlSerializer().SerializeToString(binResource);
            // the above throws a null reference exception
            // once that passes probably want to actually check the content that came through
            // Assert.AreEqual(metaXml, xml);
        }

Use this unit test to check that the serialization doesn't throw the issue, but would be preferable if the update functionality doesn't set both fields

Better to udpate TestCreatingBinaryResourceHttpClient to also check the fields are appropriate

                var binary = new Binary() { Data = arr, ContentType = "image/png" };
                Assert.IsNull(binary.Content);
                var result = await client.CreateAsync(binary);
                Assert.IsNull(result.Content);

                var xml = new FhirXmlSerializer().SerializeToString(result);
                result = await client.UpdateAsync(result);
                Assert.IsNull(result.Content); // Fails here
                xml = new FhirXmlSerializer().SerializeToString(result); // or here due to the content being not null

Expected behavior
Unit test should pass, and XML is created correctly.

Version used:

• FHIR Version: R4B
• Version: 5.8.1

Additional context
The only workaround is to request the resource response format in the client settings.
clientFhir.Settings.BinaryReceivePreference = BinaryTransferBehaviour.UseResource;

[ewoutkramer]

The philosophical question is: "is a renamed property still the same property".

• If yes ("conceptually the same thing, just renamed"): we need to distinguish between the "internal name" (e.g. we pick the R4 name) and the "external, serialized name" (differs from version to version). Requires the user to understand that we needed to compromise, and that the property is called differently from the R3 name. R3 will slowly die, so that is acceptable. IReadOnlyDictionary will return the new name as well. But it also complicates the mental model. We need to keep in mind that the name of the property in the POCO is not necessarily the name on the wire, or in ITypedElement. We need to augment the PropertyMapping with a "real name" and an "external name". Furthermore, it's easy to set the one and not the other in the POCO model - should they not always be the same? Should IReadOnlyDictionary support both? What would it return?
• If "no" ("in the world of programmers, a property with a different name is a different property"), we have two properties, so the IReadOnlyDictionary returns both if they are both set. R3 developers may wonder what that other property does and why it is there. But we could document that (in fact, I think we already do). If you set both, it will be unknown in one of the two versions (leading to this bug). If you set one or the other, everything will work fine.

Another point to consider: when we add support for having unknown properties in resources (added to a dictionary, but not available via a code-generated property) in preparation of R6 ("allow unknown elements"), having properties that do not exist in that version's metadata will become more common.

No answers here, just a braindump of stuff to consider.