Consider cleaning up our ISourceNode+ITypedElement XML ppipeline

[ewoutkramer]

Our XML pipeline is flexible enough to parse non-FHIR formats like CDA and even others. This can be controlled by the StructureDefinition.

Although this is fine in theory, we have not yet really encountered a real use for this, and even for CDA we might want to generate POCO's and use the faster POCO parsers in the end. On the other hand, the flexibility we have causes extra complexity in our Class/Property mappings, ISourceNode parser (it needs to allow almost anything) and ITypedElement parser (it needs to understand XML annotations on the source node), it requires CDA specific attributes like default types etc.

I suggest we take this flexibility out, making our parsers faster and easier to understand. We can then also align the error messages better with the json/xml parsers, since the same things will be wrong in all (less flexibility allowed). This will also allow us to clean up metadata and thus attributes in our generated C# - which will make handwriting custom poco's easier.

[brianpos]

What are you considering retiring here?
I may be using it in my mapping language engine
https://github.com/brianpos/fhir-net-mappinglanguage
(ported from the Java engine)