Draft: Input Parsing Refactor / Generic Input Extension Mechanisms

[untereiner]

Hello @wrtobin , I was looking at you draft and I don't understand the objective of the modifications for xml inclusions. Why are the included xml files more inlaid in the Group concept ? What is the concept of Generic Input Extension

I think this work is also related to this discussion https://github.com/GEOS-DEV/GEOS/issues/3073

I would be in favor of keeping things separated:

• on one side xml files (even splitted files), the entire xml tree can be reconstructed and validated
• on the other side the elements of the tree that can be instantiated as objects by geos.

[wrtobin]

Part of this work is attempting to separate input file format dependence / parsing from internal group/attribute instantiation and definition.

There is still work to do (clearly) but this includes abstracting inclusion to the point that files of arbitrary (but supported) hierarchical input formats can include other files of arbitrary (but supported) hierarchical input formats.

Whether we want to fully allow that is a different concern from designing a system that is componentized in such a way to facilitate trivially supporting that.

To accomplish that inclusion needs to be independent of document type, where it sits right now ( the current implementation ) is mostly a result of iteratively removing it from the xmlwrapper, rather than a hard decision of how we should actually accomplish this.

[untereiner]

The separation of file format / groups is a very good idea But, file inclusion is a file thing and is more or less supported depending on the chosen format. It should then be handled at the file level IMHO. The input parser should take as input a complete document to parse.

If follow you remark I'd say it should be possible to include yaml files in json files and theses files in xml files. But that's a bit weird.

And yes the work sits in the xmlwrapper but I am concerned about the handling of these includes.

[wrtobin]

The inclusion modification is currently the part of this work I like the least, yeah.

While I don't necessarily want to support inclusion of files of different formats, my intent is to implement things in a generic enough way that such a thing is possible (though not supported), since really we're just working with a bunch of abstract trees in all cases.

I'm amenable to reworking it and seeing if putting inclusion processing into document abstractions makes things cleaner.