6. VML Reference Material
From OOXML-Wiki
[edit] General
OOXML specifies here a markup language called Vector Markup Language (VML) which, in addition to DrawingML, specifies a vocabulary for describing graphical objects. Section 6.1 says, “The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML” The need to support VML by OOXML consumers, in addition to DrawingML, would come at great implementation expense (the VML specification is over 600 pages) , would disadvantage all vendors but Microsoft, and would hurt interoperability.
Proposed change: Remove VML from OOXML. Vendors who have access to the legacy binary format documentation, such as Microsoft, are free to convert the VML to the “newer and richer” DrawingML at the same time they convert the document to OOXML. (See also 5.3 DrawingML - Legacy Compatibility)
[edit] All subsections
All subsections of Section 6 describe deprecated only material, making Section 6 deprecated as a whole. A new standard should not contain deprecated parts.
Proposed change: Remove Section 6.
[edit] 6.1 [p4343, 4 and 5]
What does 'This namespace' refer to? There is no obvious namespace in the context of that sentence.
Proposed change: Clarify the namespace reference.
[edit] 6.1 [p4343, 5]
The relationship of 'Other VML namespaces' to the OOXML proposal is unclear.
Proposed change: If the said other namespaces are related to OOXML, clarify the relationship, else remove the reference to them from the text.
[edit] 6.1 [p4343, 8]
The reference to 'millions of documents' is an unsupported assertion. Furthermore, it is irrelevant in the context of a standard proposal.
Proposed change: Remove the marketing fluff from the text.
[edit] 6.1 [p4343, 9]
The reference to the specific commercial product 'Office 2000' brings no value to the proposal.
Proposed change: Remove the reference to Office 2000.
[edit] 6.1.2.7 [p4444, tableproperties]
This element uses a bitmask to specify VML table properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations.
Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
[edit] 6.1.2.19 [p4653, equationxml]
This describes the "equationxml" attribute of "shape" elements, "used to rehydrate an equation using the Office Open XML Math syntax". However, the "actual format of the contents of this attribute are application-defined", which makes them impossible to exchange between applications. If we're going to have a new math markup language in XML, and ignore the existing MathML, let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways.
Proposed change: Define equations in an interoperable way.
[edit] 6.1.2.19 [p4655, gfxdata]
Describes a "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. If we're going to have a new graphics markup language in XML, and ignore the existing SVG, let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways.
Proposed change: Define this in an interoperable way.
[edit] 6.2.2.14 [p4813]
This describes an "ink" element which stores "ink annotations in an application-defined format." This is apparently intended to store 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 OOXML. We are opposed to standardizing placeholder elements for entirely application-dependent proprietary formats without also specifying an interoperable format for those who with to create interoperable formats.
Proposed change: Specify the “ink” format or remove the element from OOXML and make this an application extension using the extensibility mechanisms of OOXML.
[edit] 6.4.2.4 [p4925, AutoFill ]
The text says, “This element specifies that the object is an AutoFill object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoFill object” defined.
Proposed change: Define the behaviour of an “AutoFill object”
[edit] 6.4.2.5 [p4925, AutoLine ]
The text says, “This element specifies that the object is an AutoLine object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoLine object” defined.
Proposed change: Define the behaviour of an “AutoLine” object”
[edit] 6.4.2.6 [p4926]
The text says, “This element specifies whether the object's size is formatted automatically by the application. If this element is specified without a value, it is assumed to be true. This is a general-use element for objects that use an image representation, such as OLE objects, Embedded controls, cameras, and signature lines.”
The objects listed after the words "such as ..." must be interpreted as an exhaustive or partial list ? What ST_ObjectType's object types (6.4.3.2) correspond to "OLE objects", "Embedded controls" or "signature lines"?
Proposed change: Define the applicable objects for this element according to the ST_ObjectType type.
[edit] 6.4.2.7 [p4926, AutoScale]
The text reads, “This element specifies whether the object's font is automatically scaled by the application when the object is resized. If this element is specified without a value, it is assumed to be true. This element is used for attached text.” “attached text” is not one of the allowed values of the ST_ObjectType type.
Proposed change: Define the applicable objects for this element according to the ST_ObjectType type.
[edit] 6.4.2.8 [p4926, Camera]
The text reads, “"This element specifies that the object is a camera object. A camera object shows a live view of another part of the spreadsheet. If this element is specified without a value, it is assumed to be true. This element is used for cameras." However, a “camera” is not defined in this context, nor its behavior.
Proposed change: Define the behaviour of this “camera object”.
[edit] 6.4.2.10 [p4927]
The CF element is defined as providing a, “general-use element for objects that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.” However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given.
Proposed change: Provide a proper external normative reference for the allowed formats containable within this element.
[edit] 6.4.27 [p4938, FmlaMacro ]
The text reads, “This element specifies the custom function associated with the object” But no objects are listed for this element.
Proposed change: List what ST_ObjectType objects this element can be applied to.
[edit] 6.4.3.1 [p4955]
The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats. No allowance seems to have been made for use by other operating systems. For example, in Linux images are typically copied on the clipboard in an open standard format like PNG.
Proposed change: Several options here, but the desire is to allow cross platform interoperability.
