Attribute Validation error messages contain incorrect/incomplete location paths

[brianpos]

Describe the bug
The location included in error messages are different for resources parsed from xml/json or created as objects
These should be consistent and use the fhir definitional paths (which are in the FhirElement attribute on the properties)
And if there is no positional information, then the line/position data should be excluded.
The current code returns a message such as ..., At Patient.Text.DivElement.Value, line , position

firely-net-sdk/src/Hl7.Fhir.Base/Validation/CodedValidationException.cs

Lines 90 to 97 in c32024b

	// Bit of a hack. The location returned by GetLocation() will be different depending on
	// whether this validation is run within the deserializer or the DataAnnotations.Validator.
	// In the latter case, the MemberName will be set, and GetLocation()
	// will return the parent, so we need to add the MemberName.
	if (context.MemberName is not null)
	{
	path = $"{path}.{context.MemberName}";
	}

To Reproduce
Check this unit test:

 public void TestXhtmlValidation()
 {
     var p = new Patient
     {
         Text = new Narrative() { Div = "<div xmlns='http://www.w3.org/1999/xhtml'><p>should be valid</p></div>", Status = Narrative.NarrativeStatus.Generated }
     };
     DotNetAttributeValidation.Validate(p, true);

     p.Text.Div = "<div xmlns='http://www.w3.org/1999/xhtml'><p>should not be valid<p></div>";
     validateErrorOrFail(p, true);

     p.Text.Div = "<div xmlns='http://www.w3.org/1999/xhtml'><img onmouseover='bigImg(this)' src='smiley.gif' alt='Smiley' /></div>";
     validateErrorOrFail(p, true);
 }

The error message produced will have a location of Patient.Text.DivElement.Value where the actual location should be Patient.text.div
It also currently includes empty line/position info
"... At Patient.Text.DivElement.Value, line , position"
this extra empty data should be excluded,

Expected behavior
The location should be accurate, and missing information should be absent from the message.

Possible discussion
Should these paths actually be different?

p.s. I've got code that resolves these issues, though I haven't checked if there are any other side effects as yet.

Version used:

• FHIR Version: R4
• Version: 5.11.1

[brianpos]

p.s. Would like to see this in a 5.11. 2 or 3 release - hoping you're still doing patches while the 6.x alpha/beta stream is underway.

[brianpos]

@ewoutkramer Meant to tag you for review, not assign to work on.

[ewoutkramer]

Yes, we are surely still doing updates to 5.x!

The location is a bit of a pain indeed, and it's on my list to review the system a bit anyway, since in 6.0, because of the nw overflow features, some validations are no longer done by the parser (as overflow allows new kinds of invalid data to be captured by the POCO itself), but by the attribute validation, and as such it should integrate a bit better with the parser errors. Due to the limitations of dotnet built-in attribute validation, we might need to look for other ways though....

[brianpos]

Shall I create a PR for this to review then?