Ecma 376 often relies on “application-defined” behaviors to support important functionality that should be documented or supported via existing standards. The reliance upon application-defined formats inhibits the goal of interoperability and prevents the exchange of valuable information contained within a document. Examples include: * Section 6.1.2.19 defines the “equationxml” attribute of “shape” elements, “used to rehydrate an equation using the Office Open XML Math syntax”. This information is apparently intended to allow mathematical equations in drawings to be edited and interpreted based on their underlying mathematical structure rather than as simple graphical objects, a critically important feature for users of equations in illustrations and presentations. However, the “actual format of the contents of this attribute are application-defined”, which makes them impossible to exchange between applications. (Even though “they shall contain Office Open XML Math”, this could be arbitrarily and unnecessarily obfuscated by the presence of other application-specific information, application-specific encodings, and so on.) * “gfxdata” attribute for the “shape” elements, which “contains DrawingML content” that is “base-64 encoded”. However, the “contents of this package are application-defined”, so even though they “shall use the Parts defined by this Standard whenever possible” there is not sufficient information for an independent implementation to read this data or display the “DrawingML content” contained therein. (The stated rationale for this attribute is to allow “VML to represent graphical content while still persisting DrawingML for consuming applications that support DrawingML” — but this only highlights the duplicative nature of Ecma 376, which defines two new vector-graphics XML formats, VML and DrawingML, instead of using a single standard one such as W3C SVG.) * Section 6.2.2.14 defines an “ink” element which stores “ink annotations in an application-defined format.” This is apparently intended to store Microsoft Ink annotations, used with tablet input devices to add hand-written annotations to documents. These annotations are often a vital part of documents and their specification is undefined in Ecma 376. Moreover, the use of unspecified formats is entirely unnecessary, as the W3C PNG specification could be used for transparent raster image data and the W3C SVG specification could be used for vector or mixed vector/raster data. Microsoft, in contrast, reports that it uses one of two proprietary formats for Ink content: an Ink Serialized Format (ISF) encoding the user’s pen-stroke information as well as other metadata (using an undocumented compressed format), as well as a “fortified” GIF format including ISF meta-data. * Numerous elements are not required by the standard, but if omitted lead to “application-defined” default behaviors—a completely unnecessary barrier to interchange between applications (causing the same document with “default” styles to appear completely different in two conforming programs), as opposed to simply defining the defaults in the standard. For example, sections 2.7.4 defines elements to specify default paragraph and run properties (docDefaults, pPr, pPrDefault, rPr, and rPrDefault); if these are omitted “the defaults are therefore application-defined”. VML should be maintained in the specification solely for backwards compatibility reasons and it should be maintained that the usage of VML is “deprecated”. We strongly suggest that future versions of DrawingML should be extended to become a full superset of VML and subsequently no distinct parts of the specification should rely on VML, but instead utilize this extended DrawingML.

Proposed Disposition of DIS 29500 Comment DK-0150 (Modified: 2008-01-04) Agreed; the use of application-defined content inhibits interoperability. This will be corrected as follows: Regarding the equationxml attribute: This is handled by the disposition of comments BR-0055, CA-0059, CL-0207, CO-0225, CZ-0035, DE-0111, FR-0371, GB-0483, GR-0014, MY-0020, PT-0110, and US-0154. Regarding the gfxdata attribute: This is handled by the disposition of comments BR-0056, CL-0009, CL-0208, CO-0226, CZ-0036, DE-0112, FR-0372, GB-0484, GR-0088, and US-0155. Regarding the deprecated nature of VML: This is handled by the disposition of comments CA-0076, CL-0025, CL-0206, CO-0076, CO-0223, CZ-0004, CZ-0011, DE-0018, DE-0020, DE-0021, DE-0115, DE-0116, DK-0058, DK-0095, DK-0150, DK-0155, FI-0008, GB-0177, GB-0190, GB-0476, GB-0477, GR-0087, IE-0009, JP-0030, KE-0047, KE-0064, MX-0006, US-0092, US-0152, UY-0002, VE-0013, and ZA-0016. Regarding the ink element: This is handled by the disposition of comments BR-0057, CL-0209, FR-0373, GB-0485, PT-0111, and US-0157. Regarding WordprocessingML defaults: This is handled by the disposition of comment VE-0016.