I have an XML file that contains configuration information for a system. I can serialize/deserialize the XML into a hierarchy of objects that describe the configuration (and no more) and then pass those objects to a task which performs work based on the data in the objects.

What I want to do is to build a specialized editor for my XML to allow a user to construct the configuration file via point and click as opposed to opening it up in a text editor and manually changing things. The idea being to provide consistency and error checking when the configuration information is entered (as opposed to the run time system saying FU and having to figure out what you did wrong). Because of the normalization of data in the XML there would be almost a 1 to 1 correspondence of XML elements/attributes to user edit fields on the screen.

However when I think of this in MVVM terms, it seems I have two choices, neither of which I like.

1. A separate View Model hierarchy duplicates all of the fields in the XML model while adding error checking and everything else needed (such as data binding and property updates etc) to couple a View Model to a view in WPF using MVVM.

2. The XML model sucks in everything that a separate View Model would do, but I end up having a single (albeit horrendous), consistent object hierarchy.

So it seems either I duplicate the hierarchy, creating consistency issues, or I violate having separate view and domain models and create a big ball of code.

Is there another way that I can structure my editor that avoids these two designs and their pitfalls?

This question from 2012 asked what may seem be a duplicate, but the answers are inconsistent to say the least.