Gray Knowlton brought up the issue of binary printer stuff in Open XML which is a potential security issue according to India-79 et alii
Security hole. OOXML allows the inclusion of arbitrary binary blobs of data in ways that could be abused my malicious document authors. For example: Part 1, Section 15.2.14 recommends that print settings be stored in the binary DEVMODE format used by Windows printer drivers. However, if someone were to change this DEVMODE binary data it would be loaded into the printer driver the next time a user tried to print. Since a printer driver operates at a higher level of privilege than a user, this may allow a hacker to take control of a user's machine by crafting a specific document
What does ECMA say?
Agreed; One of the primary design goals for the Office Open XML formats was to provide open and XML- conformant independence from proprietary formats and features. DEVMODE structures are found in the large corpus of existing binary documents, and DIS 29500 defines a format for high-fidelity representation of those documents. As such, it allows for storage of the DEVMODE structure within the package, to preserve the content of those structures in existing binary documents. The members of Ecma TC45 felt that failure to preserve this existing content would be perceived as a loss of fidelity and interoperability by persons who have found the presence of this structure useful in existing documents.
We note that there are many types of non-XML content allowed in common office document formats, including image and media formats. In the case of printer settings, there does not currently exist an ISO/IEC standard for storing this information in an XML-based format. If and when such a format becomes available, DIS 29500 will be able to use that format for storage of printer settings, and implementers may then choose to convert existing DEVMODE structures to an XML-based alternative if so desired.
In short it means ECMA finds Open XML shall remain an incomplete specified and inconsistent format. Some elements are still (in the spec undocumented) binary. It is hard to understand why DEVMODE structures cannot be transformed to XML for consistency reasons. Ah! "High-fidelity" of course which means everything but in particular that your XML format is a projection of the binary format, also by some referred to as a "dump" of the old legacy format. Even more fidelity is guaranteed when you just take the binary. In wonder why the drafters of the format started this WordprocessingML and didn't add support for the highest fidelity of the doc format inside the open packaging zip container.
http://msdn2.microsoft.com/en-us/library/ms535771.aspx
My guess in this case is: The DEVMODE structure is very idiosyncratic - transformed to XML and fully specified it would immediately conflict with existing ISO norms. A trade-off. Duck and cover is ECMA's defense strategy. Because that didn't seem to be what the standard bodies expected they added some fluff.
For instance the appeasement hack:
Example: The following SpreadsheetML Worksheet part-relationship item contains a relationship to a Printer
Settings part, which is stored in the ZIP item ../printerSettings/printerSettings1.binxml:
<Relationships xmlns="…">
<Relationship Id="rId4"
Type="http://…/printerSettings"
Target="../printerSettings/printerSettings1.bin"/>
</Relationships>
where the contents of PrinterSettings.xml could contain the following XML:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PrinterSettings xmlns="…">
<PrinterSetting name="PropertyName" value="PropertyValue" />
</PrinterSettings>
Got it? As I told you before one of the websites which thrill me is http://thedailywtf.com/