About the OM classes in FGL:
The OM library is there for historical reason and is optimized for AUI tree management. It was extended to manipulate XML files and do basic XML processing. In this context we don't see the need to implement a huge XML lib with external lib dependencies.
Regarding the encoding produced in the <?xml ?> header:
This is a STANDARD XML IANA character set name, resolved from the (LANG/LC_ALL) conversion file FGLDIR/etc/charmap.alias.
http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EncodingDecl http://www.iana.org/assignments/character-setsIf the third party tool reading the XML file generated from FGL is not able to support a standard encoding specification in the <?xml > declaration, it's a bug in that software.
If you are sure you are writing only pure ASCII characters, you can argue that you want only to write an ASCII encoded file that does not need encoding specification in the header (actually it defaults to UTF-8, but since ASCII is a sub-set of UTF-8 it's ok), or you may want to set the "ANSI_X3.4-1968" / "ASCII" encoding by hand... The problem is that the FGL runtime system will not check if the bytes written are valid ASCII characters, and this can be dangerous. Other customers could then complain that the VM generates ASCII XML files with invalid characters... new bug for us.
So far the only workaround I can see it to patch the generated file after it's finished, replacing [encoding="windows-1252"] by [encoding="ANSI_X3.4-1968], but again this makes only sense if you are using pure ASCII chars, we have no charset conversion library like iconv build in the VM.
Seb