I just encountered a problem with JUCE’s XML implementation, exercised by the KnownPluginList. The background is this: Electromagix’s 32-bit Ambience AU plugin (here) uses an AudioComponentDescription subType which contains unprintable, XML-illegal characters (specifically an ASCII 7 at the beginning). That’s legal for an OSType, though.
Since JUCE’s PluginDescription for AudioUnit plugins uses the subType as part of the “file path”, the XML representation cannot legally contain the file attribute for Ambience. However, JUCE’s XML writer doesn’t actually care and writes illegal XML (nor does the reader care about reading it). For ASCII chars < 0x20, only 0x9, 0xA and 0xD are legal XML.
So there are (at least) two issues. First, it would be great if the XML writer/reader could be relied upon to generate valid XML. Second, the AudioUnitPluginFormat might need to be proactive about wildcarding XML-illegal characters, since those will always exercise this problem when the KnownPluginList is exported. Finally, maybe it would make sense to offer a JSON export/import for the KnownPluginList to avoid the issue (although the legacy XML i/o will still need a fix).
For the moment, I’m performing XML-safety validation on my KnownPluginList and removing entries which fail, but it’s not an ideal solution.