I've been thinking about the above problems.
A standard for generating and validating XML files is XSD. This describes the format of the XML file, the datatypes and imposes constraints on how they are put together. If we set up such an XSD, we can validate all airframe files against this definition and trap errors a bit early, or trap issues where certain config items no longer have effect as support disappeared, or whatever. So it's not only useful to validate what exists now, but also in cases where new airframe files are being developed and add this as a pre-validation stage prior to compilation.
For the editor: I thought about this in detail and in all paths I considered I think we end up writing a fully blown editor which takes a lot of effort and I don't think it's justified considering the frequency at which new airframe files are made.
A wizard like application is something that comes close. The XSD will contain a large amount of choices that can be made (rotorcraft | fixedwing), etc. So for some of the choices we allow the user to specify what subelements should be inserted and then reapply the element factories to rebuild the document so far, eventually leading to a document that contains a general layout of the user-specific configuration. The XML is then generated and the user can tweak the generated values by hand (or remove them?). The choices offered will have to be picked by us, because it requires custom code to be inserted.
I think for getting the development environment figured out, we could consider using xpath to see if specific special rules apply that need to update the environment. This could be a simple "update_environment" script that reads the airframe being considered and then launches rules to pull things from git or "git update" submodules or whatever.
What do you think? Does this sound too complicated?
Rgds,
Gerard