A little OT here, but maybe it helps A&H:
No, we are not working on an offline editor for Qu at this time. That’s not to say we never will, and it will definitely be considered again in future (as it has been a number of times in the past).
Instead of developing an offline Editor for all the consoles in the house, A&H could try to make use of the Internet Community in that point by creating an open and mostly standardized Show File Format that the Mixers can store and load (if necessary even by using the Mixpad App for that so there’s no need to implement the format itself on the FPGA).
I am relatively shure that there are enough Qu and SQ Users with software development know-how out there. So if an Open Source Editor Project could be founded this likely could get by far more dynamic than A&H could ever reach by doing all the work alone.
Just have a little look outside your “corner” into the XML World. There are already many things there that could be useful.
Starting with XSD to not only simply (and if necessary by using already available development tools) define sophisticated XML Sublanguages that can represent almost any data, but also validate and analyze any Data to conform to such a Definition with common Services, free tools and freely available libraries. That means: you don’t have to develop a check for correctnes of an Input File - there is already widespread available free Software can do that for you (even in your own App, in a Webservice or as a batch tool).
Further on, XSLT could be used to migrate show files and functional block templates between Mixer Models. So Customers can upgrade their hardware and import existing Shows on the new one. Or Bands can E-Mail their Show to the Sound Engineer without knowing the exact mixer Model and I/O Modules he has - the Sound Engineer can migrate the Show to his Hardware by using a provided XSLT Stylesheet (which contains nothing more than transformation rules for the different XML Nodes) and check what additional gear may be necessary or what features/plugins might be missing or if he needs a bigger Console - long before the Event.
Oh, and of course XSLT could also be used to generate Documentations - for Customers, for Discussion, for archiving or whatever needs a documentation about the used audio processing. Or to generate a Monitor Mixer Config Template from an FoH Configuration (and vice versa). Or check if both can be used together on one splitting Stagebox. All you nedd is the corresponding processing rule file.
DOM Libraries like xalan, libxml or JAXB (almost any software development environment has at least 2 or 3 of it available) can be used to load XML Files into Memory as Object Trees or processing Streams and to store such Data into XML Files within a handful lines of Code. So you won’t have to write a Parser for the files - that is already done!
XInclude can be used to manage modularization (like creating Libraries of Channel Templates to combine into Show Files or splitting Show Files up to several logical parts) - and there are Converters from/to JSON which can be used mostly (but not completely) equivalent to XML.
The most common ressentiment against such things is “we will not be able to support Users with Shows created by unknown Software” - but in an XML World, that is not really true. XML was made to address especially such a case by having a simple contract: what validates must be processed correctly without Crash. So any Show File either validates - then your App/Console /has/ to process it in a senseful manner (it may of course give an unwanted result because of dumb settings in it, there is no User IQ Filter 
- or it doesn’t validate, then the Software that created the file has to be fixed before your mixer/app can be blamend for anything.
It may look a bit strange on the first sight for a Company that depends heavy on its intellectual property to release such things. But the first Manufacturer that manages to set a widely accepted open Standard here could gain massive benefits since the whole Rest of the Market will obviously get in strategical pressure to support that Standard too - likely within a short time.
Also you might wonder about suggesting XML (which is more known as a Document Management Tool) for a more technical Software. But in structure, the Show and Configuration Data of your mixer can be seen as nothing different but a kind of hierarchically structured Document or a Tree of Data Objects. So that is perfectly the thing that XML was made for.