FhirJsonParser Removing Leading Spaces

[MLuebbers]

I have a FHIR JSON string I wish to deserialize to a Resource object. There is an identifier in the resource that has a leading space and must remain that way but when inspecting the resulting Resource POCO from the parser that space is gone. I was under the impression the parser should leave JSON string fields exactly as they are without removing any leading or trailing whitespace. The SerializationSettings by default seem to remove the whitespace but I couldn't find an equivalent for the ParserSettings. I couldn't find any documentation about this behaviour, is this intended?

[alexzautke]

Hi @MLuebbers, we apply the same rules as for XML here: "Implementers SHOULD trim leading and trailing whitespace before writing and SHOULD trim leading and trailing whitespace when reading attribute values (for XML schema conformance)" (see https://build.fhir.org/xml.html). There is no setting for this as it confuses all kinds of tooling.

[MLuebbers]

@andrzejskowronski @alexzautke. Is there a timeline for these changes to be released in 5.12.3?

[alexzautke]

We'll try to put out a new release in the next two weeks.

[mikemassa84]

@alexzautke , @andrzejskowronski It looks like the change for this is not included in the 6.0 release. Was that intentionally omitted or a miss when cutting the new version?

[alexzautke]

This should be released with https://github.com/FirelyTeam/firely-net-sdk/releases/tag/v5.13.0. All changes there should have also been merged forward to 6.0. We can double check.

[andrzejskowronski]

For 6.0, FhirJsonParser uses the new poco serializer under the hood, which will always keep data as-is.
If you want to use old SourceNode/TypedElement parsers, you can do so with
FhirJsonNode.Parse(json, settings: new() { PreserveWhitespaceInValues = true }).ToPoco<Patient>()
Likewise the default json serializer will keep string data as-is during serialization, and in SourceNode world we have the ToJObject to specify to preserve whitespaces during serialization.

Nevertheless, we would encourage using new stack, as the performance should be overall improved compared to parsing then processing!