Hi Peter,
of it's direct readability.... maybe it's a good middle ground... but in all honesty, I would prefer a Json like syntax over XML.... or more exactly... When people suggest that every thing should be encoded as an XML file... I tend to concur with those in t crowed who just role there eyes...
please don't mistake Genode's reliance on XML as our only and all-encompassing solution to everything. XML is not necessarily the user-facing configuration front end. To draw an analogy, XML is to Genode's configuration concept what an intermediate representation (IR) is to a compiler. While it is possible to write programs in LLVM's IR, programmers usually use a front-end language like C.
We picked XML as our "intermediate representation" as it is easy to parse, easy to generate, expressive, has no ambiguities, comes with no surprises, and is human-manageable. Whether XML or json or S-expressions or something else would be the "best" syntax is debatable. It ultimately comes down to personal taste so that there is no conclusive answer. However, what is not debatable is the need for a _coherent_ concept throughout the system. So we had to make a choice and apply is consequently. We picked XML and it delivered exactly what we expected. In fact, I have never heard a compelling argument against using it for our purpose - other than personal taste (which is actually not a compelling argument).
Personally, I am not a friend of editing XML by hand. But I am also no friend of editing LaTeX by hand. Still I am a huge fan of LaTeX. To make using LaTeX more convenient for me, I'm using a preprocessor (GOSH). The same idea can be applied for the configuration of a Genode system. It is entirely possible to come up with domain-specific languages for different configuration needs. The "compiler" of such a language would output XML as the intermediate format understood by Genode's components.
Conceptually, such a transformation tool that transform a convenient domain-specific language to a XML-formatted configuration of a Genode component is simply a configuration front end. Its role within the system would be not any different from a GUI-based configuration front end. When deciding where to put our efforts in near future, I would opt for the GUI direction for two reasons: Even though I don't find the editing of XML files super convenient, I am perfectly okay with it for the time being. I don't feel that it stands in my way. Second, a GUI-based means to configure Genode makes Genode approachable for a wider user base (another textual front end won't achieve that). E.g., coming back to the example of a throw-away Tor browser OS, it is crucially important that the user can join to a wireless network by a few easily discoverable mouse clicks.
Cheers Norman