1 2 (3) 4 5 (6) (7)
Høringssvarfra 1 
Clause No./ 
Subclause No./ 
Annex 
(e.g. 3.1)
Paragraph/ 
Figure/Table/Note 
(e.g. Table 1)
Type of com-ment2 Comment (justification for change) by the MB Proposed change by the MB Secretariat observations 
on each comment submitted

DK-00 DIS 29500   Ge Danish Standards will support the publication of ISO/IEC DIS 29500 OOXML as an ISO standard provided that our comments DK 01 to DK 41 are fully addressed and the proposed changes implemented. Our comments will of course be amplified at the BRGM meeting which is scheduled to take place 25-29th February 2008 in Geneva.

Danish Standards appreciates the fact that other NBs have proposed other solutions for the same elements, and we are prepared to consider an implementation of these solutions instead.

Danish Standards wishes all other Danish comments, DK 42 to DK102, to be considered at the BRGM meeting.

This means that we will change our vote to a vote of approval if the above conditions are met.

   
DK-01 DIS 29500   Ge Preamble

The proposed changes to the DIS 29500 standard by the Danish NB would increase interoperability, portability and cultural and linguistic adaptability reflecting the common strategic characteristics of standardisation in ISO. 

These changes do not preempt the concerns of the Danish NB. These concerns can be summarized beneath understanding that the process of standardisation of document formats in ISO will take notice of them.  

Open standards

Implementation of an XMLstandard should be schema based avoiding any ties to the application.    

Overlapping standards

It is a serious concern that the current specification of DIS 29500 OO XML does not offer a high and adequate interoperability with existing ISO document standards, including ISO 26300. 

We strongly recommend that any further development of Document Formats should be coordinated in the widest possible way to ensure the goal of one document standard in ISO (see beneath).

Convergence towards one standard per domain should guide the standardisation process. 

Reuse of existing standards

Developers process of learning to use a new standard would benefit from making reuse of standards where applicable. Further, de facto standards should be replaced by de jure standards.    

Legal issues

In the standard, the legal framework for handling proprietary technologies should not exclude individual developers from access to technologies that are required for implementing functionalities in the standard, only allowing corporations access.  

Legacy technology

Technologies deemed necessary to reference in the standard for reasons of backwards compatibility are not expected to be continued in the development of the standard. Such technologies should be phased out (discontinued) in the foreseen standardisation process.    

Esthetics

The DIS 29500 OOXML document contains instances of layout, terminological and editorial inconsistencies with ISO guidelines. Examples do not always illustrate the content of the previous paragraph but add new material to the document. Naming convention in XML schema definitions has been subject to an intense debate. Best practice guidelines are in demand in the domain of document formats.   

General suggestions  

ISO has already established one standard for a document format, which is ISO/EIC 26300 OpenDocument format (ODF). This fact needs influence the development of both standards, which requires collaboration between ECMA and OASIS. Establishing such a ”joint-venture” should be decided as part of the future maintenance of the present specification.  

Maintenance of these standards would seem to need an active participation by ISO/JTC1 to conquer severing interoperability and portability of the standards within the same domain. This is particularly sensitive for DIS 29500 OOXML since it contains a substantial amount of informative and optional specifications that tends to overshadow the normative parts. The balance between normative and optional part needs be changed towards the former to increase and assure interoperability and portability.  

Interoperability backwards is the main motivation for DIS 29500 OOXML. We suggest in due course the removal of items from the specification. Rather than delegate to proprietary extensions, it might be acceptable to define a new conformance profile that collects together these legacy and proprietary features. As such, the current application conformance point could be divided into two, where basic application conformance does not require these legacy features, and the additional conformance profile supports basic conformance plus the legacy features.

ISO would need to address the question of standard compliance, particularly in this domain of standards, to counter steps that would jeopardize interoperability and portability.  

The Danish government has decided to conduct interoperability field tests of applications based on ODF and OOXML in the period 2007-9. The Danish U-34 committee expect that results from these tests will be assessed for the benefit of development of the standards. Compliance testing is expected to be an integral part of the process.

   
DK-02 Part 1

Annex A

Page 162

line 7

Te The reference to .ZIP file do not give any precise version information. This could lead to confusion for the Implementation. The specification should reference a specific version of the .ZIP specification.  
DK-03 Part 4

Section 2

  Te ECMA-376 Office Open XML specification lack  the feature to for image to be absolute position within a frame.

This feature should be include to ensure interoperability with other Office productivity application, which use the international standard ISO/EIC 26300 Open Document format.

The absence of this feature makes it impossible to achieve full interoperability between office productivity applications.

The feature would also allow for a more free position of image inside a text-document, and give the author full control for placing images on a text page. The current Office Open XML does only allow for placement of image-frames in position to text. This ability would then be dynamic depending of the individual users WYSIWYG configuration, which often depend on platform specific printer-drivers.

Future versions of OOXML should adapt functionality for facilitating interoperability to existing ISO standards, specifically standards within the document specification domain, such as ISO/IEC 26300.  
DK-04 Part 4

Section 2

  Te ECMA-376 Office Open XML specification lack  the feature to protect a cell within a text table in the wordprocessingML

This feature should be include to ensure interoperability with other Office productivity application, which use the international standard ISO/EIC 26300 Open Document format.

The absence of this feature makes it impossible to achieve full interoperability between office productivity applications.

The feature is valuable when interchanging word-processing document for editorial review and approval, which ensure, that user don't change content of specific part of the document.

Future versions of OOXML should adapt functionality for facilitating interoperability to existing ISO standards, specifically standards within the document specification domain, such as ISO/IEC 26300.  
DK-05 Part 4

Section 2.2.1

Page 27

line 4

Te The definition is using VML instead of the newer and richer DrawingML to define. Since Part 4, section 6. page 4343 indicate, the VML is “deprecated” and shouldn't be used in the ECMA-376 Office Open XML specification, it is of major concern that the specification actual is encouraging the adoption of VML specification for specific features

We would expect a more rigid adoption of the best practice implied by ECMA, and would expect a wider usage of the DrawingML to provide a more stable realization of the specification.

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..  
DK-06 Part 4

Section 2.3.3.19

Page 261

line 21

Te The  element encourage adoption of the VML notations despite the fact, that the ECMA-376 Office Open XML itself label VML as a “deprecated” notation, which should be replaced with DrawingML

The continue adoption of VML in the ECMA-376 Office Open XML specification lead to the perception, that VML is actually the preferred notation for implementation of ECMA-376 Office Open XML

The need for all application developers to actually adopt the VML specification to be able to deliver a complete implementation of the ECMA.376 Office Open XML specification seem unnecessary, and it is not best practice to include “deprecated” parts into a new specification.

ECMA should do the effort to convert any remaining VML notation into DrawingML or SVG notation.

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.  
DK-07 Part 4

Section 2.3.3.21

Page 264

line 9

Te This is yet another adoption of VML in a place, which could have adopted DrawingML or SVG notation 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.  
DK-08 Part 4

section 2.9.23

Page 804

line 7

Te This is yet another adoption of VML in a place, which could have adopted DrawingML or SVG notation 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 VML, but instead utilize this extended DrawingML  
DK-09 Part 4

Section 2.15.3.6

Page 1378

line 12-17

Te There is no formal definition of the element autoSpaceLikeWord95

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-10 Part 4

Section  2.15.3.26

Page 1416

line 14-17

Te There is no formal definition of the element footnoteLayoutLikeWW8

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-11 Part 4

Section 2.15.3.31

Page 1426 te There is no formal definition of the element lineWrapLikeWord6

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-12 Part 4

Section 2.15.3.32

Page 1427 te There is no formal definition of the element mwSmallCaps

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification  
DK-13 Part 4

Section 2.15.3.41

Page 1442 te There is no formal definition of the element shapeLayoutLikeWW8

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-14 Part 4

Section 2.15.3.51

Page 1462 te There is no formal definition of the element suppressTopSpacingWP

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification  
DK-15 Part 4

Section 2.15.3.53

Page 1467 te There is no formal definition of the element truncateFontHeightsLikeWP6

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification  
DK-16 Part 4

section  2.15.3.54

Page  1469 te The element uiCombat97to2003 is a construct which is intended to “disable UI function that is not compatible with word 97-2003”

Since the only company who have the actual knowledge about, which UI function isn't compatible with Microsoft Word 97 is the owner of the application, this element  only make sense  for that owner.

Since Word97-2003 is not clearly defined, i guess this means Microsoft Word 97, since the introduction declare, that backward compatibility with Microsoft Office application is one of the intended goals of the ECMA.376 Office Open XML specification.

This means that the element uiCombat97to2003 is a specific element, which only purpose is to let Microsoft, the owner of Microsoft office, build features in the specification, which can't be delivered by any other application developer.

If this is correct, then Microsoft is the only company who can provide a complete and correct implementation of the ECMA-376 Office Open XML specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.

Also insert information used in other compability settings, eg:

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which

involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML

Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those

applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated

due to issues with its output, and is maintained only for compatibility with existing documents from that

application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

 
DK-17 Part 4

2.15.3.63

Page 1481 te There is no formal definition of the element useWord2002TableStyleRules

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-18 Part 4

Section 2.15.3.64

  te There is no formal definition of the element useWord97LineBreakRules

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-19 Part 4

Section 2.15.3.65

  Te There is no formal definition of the element wpJustification

The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-20 Part 4

section 2.15.3.66

  Te There element for wpSpaceWidth is a simple boolean type as defined in ST_OnOff, but it doesn't described any intended behaviour impact based on this boolean value

The element seems to be a place holder, but lack any effect on the document beside eating up disk space

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.  
DK-21 Part 4

Section 2.17.1.1

Page 1615

line 16

Te It is against the described best practice of ECMA-376 Office Open XML to adopt VML functionality within the WordprocessingML. As described in part 4 Section 6.1 page 4343 line 12, the VML is considered “deprecated”

This could raise confusion, since the specification state one thing ( don't use VML), but actually do the oppesit itself ( applying VML to construct, which could be done using DrawingML)

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 VML, but instead utilize this extended DrawingML.  
DK-22 Part 4

section 2.18.4

  Te The include picture for the individual border design offer insufficient information to ensure a correct implementation. The individual bitmaps is blurred and lack the required details, which is required to deliver the intended interoperability Should provide the design specification needed in a format, which ensures that it is possible to construct a correct implementation.  
DK-23 Part 4

section 2.18.52

Page 1748 Te The introduction of the ST_LangCode type seems unnecessary since it is just a abbreviated form of what can already be deducted from the definition of ST_Lang type. The proposed effect achieved with the ST_LangCode type could be easier achieved by redefining the ST_Lang type to include all of ISO 639 specification instead of only the ISO 639-1 elements

it appear that the type have been introduced to have a place holder for the initial application developers own language description, which is different from the language description as they appear in the ISO 639 standard.

Should add a normative comment that ST Lang (2.18.51) is the preferred language code representation.

The reference to ST_LANGCODE in the z-switch in 2.16.5.35 should be changed to references to language code - i.e. 2.18.51.

 
DK-24 Part 4

section 2.18.59

Page 1761 Te The available option, which is indicated as ST_MailMergeDataType appears to be a placeholder with significant platform dependencies, since it only allow for windows platform specific interpretations. While the text indicate it is only suggested value, which can be ignore, it appear to be required to deliver a complete implementation of the specification.

If this is the case the specification suggest platform depended technologies to be included in the specifications

it also appear that several of these suggested technologies as either patent or IPR copyrights pending, which could lead to the assumption, that patent technology is required to implement the specification.

If the table is an example, then mark it as an example

The current example dosen't offer an easy way to adopt e.g a JDBS driver or a SOAP connection as possible access description.

Specify how to use XML data using query  
DK-25 Part 4

Section 2.18.66

Page 1771 Te The type definitions is no precise enough to insure an unambiguously implementation, as most of the sequence only indicate the starting point i gives no information about  how the series continues, it only provide suggestion as example 

E.g consider the series for cardinalText, does it go on as

one two three ....... ten eleven twelve

or

one two three ....onezero oneone onetwo

and consider the national specialities of the individual countries. Since the series appear to be e.g character specific, which means different series depending on language. From Denmark eg what should we expect ?

A B C D ..... Æ Ø Å AA AB AC AD

or

A B C D E ... Æ Ø Å AA BB CC DD ...

or

A B C D E ... X Y Z AA BB CC

or

A B C D E ... X Y Z AA AB AC

Provide an unambiguously algorithm for the full interpretation of the suggested numeration series.  
DK-26 Part 4

Section 2.18.67

Page 1779 Te The definition of ST_OnOff type is  appears to be an attempt to break the official definition of boolean values as they are specified in the XML specification

According to the specifcation or XML Schema for boolean type as defined at http://www.w3.org/TR/xmlschema-2/ section 3.2.2 the only allowed values for boolean operations is

"An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0}"

The introduction of the values “on, “off” as defined in the type ST_OnOff, and the widespread adoption of assigned this type to boolean value across the specification would most likely impose additional constrains on application developer, since it means they can't rely on standard XML behaviour to evaluate ECMA-376 Office Open XML files, because they need to take into account the extended/broken specification of boolean-like data types

This is an example of misguided adoption of XML notation, and should be change  across the whole specification.

Strongly suggest to use XML boolean values.  
 
DK-27 Part 4

Section 2.18.85

Page 1800 Te The definition of shading pattern is represented using a series of blurred pictures, which offer limited help to support an unambiguously implementation of this feature. The definition also represent a limited possibility, which makes it impossible for application developers to expand the suggested set of graphics and shading patterns Provide an unambiguously definition of shading patterns.  
DK-28 Part 4

Section 3.2.2

Page 1876 Te The text for the calcCompleted boolean value is in conflict with the definition af boolean type according to the XML Schema definition at http://www.w3.org/TR/xmlschema-2/ which only allow the values {true, false, 1, 0}. , the values “on”, “off” is not allowed

This mistake seem to be widespread across the whole specification, which indicate a more carefully review should be conducted

a text search through part 4 of the specification reveals 978 reference to the phrase “XML Schema boolean datatype” where we didn't find any specific definition about the expected level or adoption.

This also indicate the need for a more rigid quality assurance of the specification.

Refer  to existing definition of boolean type ST_ONOFF. Refer to part 4  2.18.67.  
DK-29 Part 4

Section 3.2.29

Page 1916 Te The whole attempt to provide a specification for workbookProtection is an important feature but flawed in several ways, which render it unusable

the attempt to build you own hashing algorithm instead of using standard FIPS-180 algorithm appears to be in vain

The attempt to convert password into singlebyte representation for manipulation can't cover all national setting, since it only operates across a limited set of character sets

The included pseudo code example only suggest using the “WindowsBestFit” mapping table, which seem to indicate that the windows platform have preferences for implementation of the suggested pseudo code

The pseudo code is missing specific type definitions which imply possible cross-platform issues between 32-64 bit platforms for doing text operations

Mark pseudo code as informative (used as an example).  
DK-30 Part 4

Section 3.14.8

Page 2485 Te The element represent an OLE link, which rely on technology, which is platform specific, and is potential inflected by patent right from Microsoft.

This would mean the specification can only be completely implemented and adopted by applications, which support the OLE-depended platforms like Microsoft Windows

It also imply that the could be potential patent restriction on the implementation and adoption of the ECMA-376 Office open XML specification, since the specification rely on platform specific technologies

While not impossible to define links to elements other than OLE (and the others specified in §3.14.8) in the current specification with “extLst (Future Feature Data Storage Area)”; adding Kpart and Bonobo as specific types in §3.14.8 would make linking to these types of elements more clear for implementers.

From the discussion of this subject it was recognized that the optimal solution would be that there existed a standard for “smart linking” that could be used across platforms. To our knowledge such a standard does not exist at this point in time.

The support for available Object linking technologies should be expanded to support Object linking technologies from Linux platform, This should include support for KParts and Bonobo technologies as know from KDE desktop environment and GNOME linux graphical user interfaces.

Eg. expanding the complexType CT_ExternalLink with:

  • kparts (KParts Link)
  • bonobo (Bonobo Link)
 
DK31 Part 4

Section 3.14.11

Page 2487

line 2

Te The  element is used to  represent an OLE2 connection link. The utilization of OLE connection and OLE technology, would  imply limitation on the specification, since this technology is only available on a subset of platforms. e.g Microsoft Windows.

This imply that the complete specification can only be accomplish by adoption of OLE technology for embedding of external information

If OLE connection is a requirement to implement an application which can handle the complete  ECMA-376 Office Open XML specification, the adoption would be limited to platforms, that support OLE technology

A partial implementation of the ECMA-376 Specification in Office productivity application would break the goal of accomplishing interoperability between Office productivity applications

It should be clarified that OLE technology is not required for conformance nor implementation of the OOXML specification and usage of OOXML documents. This applies also to DDE  and OLEDB. OLE, DDE and OLEDB is a part of a long list of communication technologies.

(See part 3)

 
DK-32 Part 4

Section 3.17.4.1

Page 2523 Te The introduction of two different date base system, and suggestion to mis-handled date calculation to preserve error calculation from earlier version of Microsoft Excel seem the worst possible choice for retention of backward compatibility.

It serve no purpose to duplicate the errors of the past by encapsulating them into a new specification, and this way  miss the opportunity to set things right.

Instead of duplicating the mistake and bring it forward, one should instead find a smarter way to do it the correct way, instead of encourage application developers to continue making the same mistake

The obsession to provide backwards compatibility by continuously adopt “deprecated” specification like VML and re-implement the mistake of the past doesn't provide a viable methodology for introducing a new specification.

It also impose unnecessary additional work both for implementation and maintenance of the specification, since it enforce adoption of cumbersome construct to work around the old mistakes

We strongly suggest to add an addtional new date base system with a NULL date being 1899-12-30 and with the options to use negative serial values. Any future use of functions with date parameter should conform to www.w3.org/TR/2001/REC-XMLschema-2-20010502/   section 3.2.7 and 3.2.9.

Existing date base systems are to be kept for backward compatibility.

 
DK-33 Part 4

Section 3.17.6.7

Page 2529

line 29

Te The phrase “ as accurate as possible” more implies a hope than a request. It is ambiguously and should come with a precise description, which accuracy is need, Is it fine if it is within the same century, only a 10-year spread  or do we require sub-second accuracy

Accuracy usually depends on the context, and the application

Specify the minimum precision requirements  
DK-34 Part 4

Section 3.17.7.78

Page 2606 Te There is no clear definition about the meaning of “ a “Gregorian day”, and the example illustrate the confusion by giving different result based on the broken base date system, as described earlier

As the concept of a Gregorian day is adopted from astronomy calculation or is there any other special meaning in this context

Define more precise and unambiguously, what this function should work

Refer or describe to the intended definition of a Gregorian day

 
DK-35 Part 4

Section 6.4.3.1

Page 4955 Te The definition of ST_CF only specify a limited number of accepted clipboard formats, which are windows specific formats. The limitation in clipboard format is a constrains, which will effect the possible cross-platform adoption of the specification.

Some of the required format is patented and adoption of these format could impose possible patent restriction on the adoption of the ECMA-376 Office Open XML

Relevant   additional enumeration values should be added to SF_CF e.g. TIFF, PNG, HTML, JPG or others well-established formats.  
DK-36 2.8.2.16 
2.3.1.18 
2.4.7 
2.4.8 
2.4.51 
2.4.52 
2.15.1.86 
6.1.2.7
  Te Many element attributes in Ecma 376 are defined as bitmasks. For example:

2.8.2.16 "sig (Supported Unicode Subranges and Code Pages)" describes the <w:sig> element whose attributes are all bitmasks. For example, take the attribute csb1:

"Specifies a four digit hexadecimal encoding of the upper 32 bits of the 64-bit code-page bit field that identifies which specific character sets or code pages are supported by the parent font"

This attribute takes the following values:

Bit Description

0-15 Reserved for OEM  

24 IBM Turkish

16 IBM Greek  

25 IBM Cryillic

17 MS-DOS Russian  

26 Latin 2

18 MS-DOS Nordic  

27 MS-DOS Baltic

19 Arabic  

28 Greek (former 437G)

20 MS-DOS Canadian French  

29 Arabic (AMSO 708)

21 Hebrew  

30 WE/Latin 1

22 MS-DOS Icelandic  

31 US

23 MS-DOS Portuguese  

The other attributes of <w:sig> have similar definitions as bitmasks.

Many other element attributes in Ecma 376 have similar definitions as bitmasks. For example:

* Section 2.3.1.18, Paragraph conditional formatting.

* Section 2.4.7, Table cell conditional formatting.

* Section 2.4.8, Table row conditional formatting.

* Section 2.4.51, Table style conditional formatting settings.

* Section 2.4.52, Table style conditional formatting settings exceptions.

* Section 2.15.1.86, Suggested filtering for list of document styles .    * Section 2.15.1.87, Suggested sorting for list of document styles (page 2036)

* Section 6.1.2.7, tableproperties attribute of shape group.

The specification should use XML stylesettings instead of bitmaps.  
 
DK-37 Part 4

6.4.3.1

Page 4955 Te The reference to EMF and WMF files do not give any precise version information. This could lead to confusion for the implementation. The specification should include a normative reference to a specific version of the EMF and WMF specification.  
DK-38 Part 4:

Section 6.1.2.10

Page 4480 Te The VML Reference Material (Part 4 Section 6) contains a number of proprietary references. These include Microsoft specific namespaces, references to Windows

meta file formats, and dependency on specific versions of Internet Explorer.  

On the later, the "target" attribute (Hyperlink Display Target) of several elements has values "_media" and "_search". The description for them is as follows respectively

(refer to p4371 of OOXML Part 4, for example);

• "_media" : Specifies that the linked document is loaded into the Media Bar. Available in Microsoft Internet Explorer 6 or later. 

• "_search": Specifies that the linked document is loaded into the browser's search pane. Available in Microsoft Internet Explorer 5 or greater

The reference to Internet Explorer should be made informative (i.e. as an example) to avoid confusion, because other browser implementations than Internet Explorer are also free to utilize the _media and _search attribute.  
DK-39 Part 4

Section

6.4.3.1

6.2.3.17

3.14.4

3.14.7

3.14.11

3.14.8

  Te Removal of Dependencies on Proprietary Technologies

The VML Reference Material (Part 4 Section 6)

contains a number of proprietary references.

These include Microsoft specific namespaces,

references to Windows meta file formats, and

dependency on specific versions of Internet Explorer. On the later, the "target" attribute (Hyperlink Display Target) of several elements has values "_media" and "_search". The description for them is as follows respectively (refer to p4371 of OOXML Part 4, for example); · "_media" : Specifies that the linked document is loaded into the Media Bar. Available in Microsoft Internet Explorer 6 or later. · "_search": Specifies that the linked document is loaded into the browser's search pane. Available in Microsoft Internet Explorer 5 or greater.

Such explicit proprietary dependencies have no place in an international standard therefore consideration should be given to remove section 6. 
 

Should VML remain, XML fragments need to be specified for both ST_CF (Clipboard Format Type), section 6.4.3.1, and ST_OLELinkType (Embedded Object Alternate Image Request Types), Section 6.2.3.17, so that the enumeration of all permissible string values are made explicit. 

Also the shortlist fails to mention that we have pointed not only to the dependencies of Internet Explorer but ALSO to specific namespaces, references to Windows meta file formats.

 
DK-40 Part 4, Section 2.15   Te
  • Under-Defined Attributes. Throughout Part 4, Section 2.15 a number of compatibility setting are defined:
 
useWord2002TableStyleRules, useWord97LineBreakRules, wpJustification,

autoSpaceLikeWord95, footnoteLayoutLikeWW8, lineWrapLikeWord6,

mwSmallCaps, shapeLayoutLikeWW8, suppressTopSpacingWP, truncateFontHeightsLikeWP6, useWord2002TableStyleRules.

The semantics of these tags are not defined and thus it is not possible to implement these without knowledge that exists outside of the specification. This is not acceptable for an international standard. 

Furthermore, given the possible complexity of implementing these tags, there is no option to ignore the tags. In other words if they are present in a document the application must behave according to the tag (which of course is not defined). 

At the very least text should be added to say that applications may ignore these tags but must preserve them in documents if they are present (i.e. must not remove them).  

Either the semantics of these tags must be defined, or the tags must be allowed to be ignored, or they must be removed from the specification.

 
DK-41 Various –

see

proposed

change for

detail.

  Te Missing Normative

References: We expects to at least see XML

1.0, XML Schema (parts 1, 2 and 3), and .Zip File

Format Specification in the normative references.

Furthermore the version of Zip needs to be defined as per JTC1 directives (the current informative

reference effectively points to "the latest version" which can change.) Under JTC1 directives, any normative references that are not International standards, must either come from an Approved Referencing Organization (ARO), or must be accompanied by a Referencing Explanatory Report (RER). Note that as of January 2007, W3C is an

ARO.

These are the references from each part's bibliography that need to be defined in the relevant Normative References. All ISO references and W3C and Unicode Consortium references can be directly moved - the later two coming from Approved Referencing Organizations (ARO) In addition, RER descriptions should be prepared for

specifications originated by IANA, IETF and Dublin Core and they should be moved to Normative References. Similarly, specifications such as PANOSE by Hewlett

Packard, ZIP format by PKWARE, Inc are one of the few vendor-dependant  specifications. These are necessary in terms of OOXML implementation and should be included in Normative References with RER description. 

Not included are wmf and emf, which would be needed as Normative References should VML remain.

 
DK-42 Office Open XML Overview   Ed The Document isn't listed in the specification overview of the ECMA-376 specification in the Forward part to Part I “Fundamentals”, and the status is unknown, as well as it's purpose. The overall impressions is as that of an promotional whitepaper Overview document change status to informative in an annex.  
DK-43 Part 1  “foreword” page Vii, line 9 Ed The “Foreword” state a “number of Annexes” without a precise indication of the actual number of annexes. During the initial acceptance of the paper it was discovered that several annexes was missing from the specification, which indicates the need for a precise and correct statement about the exact number of annexes, which is included in the specification. The precise number, and a unique identification should be stated about every annex, which is included in the ECMA-376 specification.  
DK-44 Part  2 “Foreword” page Vii,

line 9

Ed The “Foreword” state a “number of Annexes” without a precise indication of the actual number of annexes. During the initial acceptance of the paper it was discovered that several annexes was missing from the specification, which indicates the need for a precise and correct statement about the exact number of annexes, which is included in the specification. The precise number, and a unique identification should be stated about every annex, which is included in the ECMA-376 specification.  
DK-45 Part  4 “Foreword” page Vii,

line 9

Ed The “Foreword” state a “number of Annexes” without a precise indication of the actual number of annexes. During the initial acceptance of the paper it was discovered that several annexes was missing from the specification, which indicates the need for a precise and correct statement about the exact number of annexes, which is included in the specification. The precise number, and a unique identification should be stated about every annex, which is included in the ECMA-376 specification.  
DK-46 OfficeOpenXML-DrawingMLGeometries.zip   Ed This annex, which was missing in the initial evaluation of the ECMA-376 specification, is not provided in a humanly readable format. This is required according to JTC 1 Directives 8.3.5 & Annex H.  The absence of  prober line-numbering, and deliverables in a accepted readable file-format, makes it impossible to give correct clarifying input to the annex. This means  it isn't possible to provide accurate comments to this annex Alter references from electronic annexes to unambiguous and readable print format.  
DK-47 OfficeOpenXML-RELAXNG.zip   Ed This annex, which was missing in the initial evaluation of the ECMA-376 specification, is not provided in a humanly readable format. This is required according to JTC 1 Directives 8.3.5 & Annex H.  The absence of  prober line-numbering, and deliverables in a accepted readable file-format, makes it impossible to give correct clarifying input to the annex. This means  it isn't possible to provide accurate comments to this annex Alter references from electronic annexes to unambiguous and readable print format.  
DK-48 OfficeOpenXML-SpreadsheetMLStyles.zip   Ed This annex, which was missing in the initial evaluation of the ECMA-376 specification, is not provided in a humanly readable format. This is required according to JTC 1 Directives 8.3.5 & Annex H.  The absence of  prober line-numbering, and deliverables in a accepted readable file-format, makes it impossible to give correct clarifying input to the annex. This means  it isn't possible to provide accurate comments to this annex Alter references from electronic annexes to unambiguous and readable print format.  
DK-49 OfficeOpenXML-XMLSchema.zip   Ed This annex, which was missing in the initial evaluation of the ECMA-376 specification, is not provided in a humanly readable format. This is required according to JTC 1 Directives 8.3.5 & Annex H.  The absence of  prober line-numbering, and deliverables in a accepted readable file-format, makes it impossible to give correct clarifying input to the annex. This means  it isn't possible to provide accurate comments to this annex Alter references from electronic annexes to unambiguous and readable print format  
DK-50 OpenPackagingConventions-RELAXNG.zip   Ed This annex, which was missing in the initial evaluation of the ECMA-376 specification, is not provided in a humanly readable format. This is required according to JTC 1 Directives 8.3.5 & Annex H.  The absence of  prober line-numbering, and deliverables in a accepted readable file-format, makes it impossible to give correct clarifying input to the annex. This means  it isn't possible to provide accurate comments to this annex Alter references from electronic annexes to unambiguous and readable print format.    
DK-51 OpenPackagingConventions-XMLSchema.zip   Ed This annex, which was missing in the initial evaluation of the ECMA-376 specification, is not provided in a humanly readable format. This is required according to JTC 1 Directives 8.3.5 & Annex H.  The absence of  prober line-numbering, and deliverables in a accepted readable file-format, makes it impossible to give correct clarifying input to the annex. This means  it isn't possible to provide accurate comments to this annex Alter references from electronic annexes to unambiguous and readable print format.  
DK-52 Part 1

Section 2

page 2,

line 2

Ed The section states” unless documented otherwise, any feature shall be implemented as specified in the Nominative text describing that feature in this Standard”

We have indicated above, that this can be overruled by annexes without any precise description in the ECMA-376 specification.  See e.g. Part 2, Annex D, p 81 line 5-6. “If discrepancies exist between the electronic version of a schema and its corresponding representation as published in this part, Part 2, the electronic version is the definitive version.”

These seems to also include the possible changes, which can be introduced using the  mechanism described in Part 5 “Markup Compatibility and Extensibility” Se part 5 p. 9 line 25-26 “Markup consumers shall ignore elements and attributes from namespaces that are both non-understood and ignorable, and shall not treat their presence as errors”

As the behaviour for compatibility don't require “markup-consumers” to include e.g namespaces which is “non-understood” this could lead to compatibility confusion.

In the event, that all future version of the specification is implemented using “Markup Compatibility and Extensibility” features as described in Part 5, and modification to unknown annexes. This would lead to   significant marked confusion around the version-handling” of the specification.

Delete Part 2, Annex D, p 81 line 5-6. ““If discrepancies exist between the electronic version of a schema and its corresponding representation as published in this part, Part 2, the electronic version is the definitive version”.  
DK-53 Part 2   Ed The specification as described in part 2 contain more material than actually necessary for implementation of support for the ECMA-376 specification, according to the description in Part 1 section 9.1. This lead to some confusion, as the Part 2 of the specification covers more material, than actually is need as stated in part 1 Section 9.1

This should be resolved as it also overload the current specification with un-exposed nominative information, which  lead to unnecessary work for would-be implementer.

To the extend there are elements that are necessary for implementation those shall be included as part of the normative Part 1.  
DK-54 Part 4   Ed The missing “Office” when referring to “Office Open XML”  or “OpenXML” is confusing, as all XML is expected to be open. Replace “OpenXML” with the more precise abbreviation “OOXML” or use the full name  “Office Open XML”  
DK-55 Part 4

Section 3.17

Starting on page 2507 Ed Several financial functions depends on the accuracy of the “day count basis” value, which is not defined in the specification. Potential implementers would need a consistent definition of this “value” to produce an accurate and uniform implementation of these functions.

The absence of a definition could mean, that different implementation could deliver different results, providing the same input, this would mean, that there is no compatibility between different implementation of the specification.

Unambiguous definition of day count basis is necessary.  ISO/IEC 15022 and part 4  3.17.4.  
DK-56 Part 4

Section 3.17.2

Page 2508

line 28

Ed The sentence “All arithmetic terms in an expression is real numbers” will give some problems, as we deal with quite a few perceived infinite real numbers in arithmetic, like PI and “e”

The specification of PI is according to section 2.7.17.249 is accurate to the 15 significant figures, which then contradict the above sentence ( page 2745, line 15)

Section 3.17.5.2 ( page 2524) also state the expected precision about, how numbers are expected to be handled within the value space.

A more precise statement, which gives, if we demand “real numbers” or which precision is recommended. As it is described here i recommend that the section 3.17.5.2 is kept, and the sentence on page 2508 is rewritten to reflect this.  
DK-57 Part 4

Section 6

  Ed The inclusion of VML, and the additional comments, that the utilization of VML should be avoided is contradictory. Since the overall purpose of standardization is to capture and promote best practice this section should be removed Suggest to include VML functionalities ref. Part 4  sec. 6.1 in DrawingML  
DK-58 Part 1 “Fundamentals” “Foreword” p Vii, line 2 Ed The sentence specify, that this is a “Multi-part Standard.” This is not correct it is a Multi-part document.. The individual parts is not specified as a standard.

This is also repeated in the introduction “Foreword” to several other parts of the specification.

Correct the mis-understanding of terminology to correctly reflect the actual nature of the ECMA-376 Specification.  
DK-59 Part  2 “Open Packaging Concentions” “Foreword” p Vii, line 2 Ed The sentence specify, that this is a Multi-part Standard. This is not correct it is a Multi-part document.. The individual parts is not specified as a standard.

This is also repeated in the introduction “Foreword” to several other parts of the specification.

Correct the mis-understanding of terminology to correctly reflect the actual nature of the ECMA-376 Specification.  
DK-60 Part 3

“Primer”

“Foreword” p Vii, line 2 Ed The sentence specify, that this is a Multi-part Standard. This is not correct it is a Multi-part document.. The individual parts is not specified as a standard.

This is also repeated in the introduction “Foreword” to several other parts of the specification.

Correct the mis-understanding of terminology to correctly reflect the actual nature of the ECMA-376 Specification.  
DK-61 Part  4 “Markup Language Reference” “Foreword” p Vii, line 2 Ed The sentence specify, that this is a Multi-part Standard. This is not correct it is a Multi-part document.. The individual parts is not specified as a standard.

This is also repeated in the introduction “Foreword” to several other parts of the specification.

Correct the mis-understanding of terminology to correctly reflect the actual nature of the ECMA-376 Specification.  
DK-62 Part  5

“Markup Compatibility  and Extensibility”

“Foreword” p Vii, line 2 Ed The sentence specify, that this is a Multi-part Standard. This is not correct it is a Multi-part document. The individual parts is not specified as a standard.

This is also repeated in the introduction “Foreword” to several other parts of the specification.

Correct the mis-understanding of terminology to correctly reflect the actual nature of the ECMA-376 Specification.  
DK-63 Part 1

Section 2.3

Page 3

line 14-15

Ed The description get  confusing because of the additional editorial note. The word “whenever” is confusion, because  there is no clear way to decide, “whenever” this is the rule Clarify if this means, that all syntax constrains is nominative  
DK-64 Part 1

Section 2.3

Page 3

line 16-17

Ed The description becomes confusing, as the word “element” is ambiguous.. What kind of “element” is intended here  “ Could be an XML-element, or an element of the ECMA-376 specification Clearly state, which kind of element is referred here  
DK-65 Part 1

Section 2.6

Page 3

line 33-34

Ed The requirements for public available documentation is overstated. If a company wasn't to use the specification for a non-public, internal-use only application, it shouldn't be necessary with public available documentation More clearly state the purpose of the documentation, and refrain from dictation of the business relationship under which the specification is adopted  
DK-66 Part 1

Section 2.6

Page 4

line 1-2

Ed The use of element in “Document element”  read ambiguously. What kind of element is referring to If the  XML-element, is intended clarify the specification, but it could be more specific parts character content or similar  
DK-67 Part 1

Section 2.6

Page 4

line 15

Ed The document reads as it actually expect and accept this kind of behaviour Probably should add an paragraph stating if the standard recommend this kind of behaviour.  
DK-68 Part 1

Section 4

Page 6

line 13

Ed The notation “Behavior, Unspecific” is confusing, since section 2 clearly state that compliance is syntactic, so no behaviour is required, or are all behaviour unspecified ? Clarify the definition to state if this is regarding behaviour, for which the specification have no recommendation.  
DK-69 Part 1

Section 4

Page 7

line 1-3

Ed The definition seem to try and deliver two definition of the same thing, which is confusing, It both try and define Office Open XML as a special way to package files, and  rendition, which imply behaviour.  Need clarification of definition  
DK-70 Part 1

Section 9.1.7

Page 17

line 10

Ed Somehow confusing, since section 9.1.1 state H as a hexadecimal digit, while h is a hexadecimal value. Either use alternative notation, or more precise indicate the case-sensitiv nature of the specification.  
DK-71 Part 1

Section 9.1.9

Page 17

Line 25

Ed Confusing... Producers can't by nature  “roundtrip”  because in that case, they also become consumers. The meaning is either nonsense, or should be clarified If the concept is for a producer, to also act as consumer towards  external sources in a publish/subscribe relationship or a request/response relationship, it need a clarification, which part the producer is responsible for.  
DK-72 Part 2

Section 1

Page 1

Line 9

Ed The phrase “well-defined naming guidelines” is confusing since the ECMA-376 specification uses “guidance” as an informative marking of the specification. Suggest using “naming rules”  as an alternative  
DK-73 Part 4   Ed Several of the example used through-out the specification fail to validate accordingly to the specification, while this seem minor issues, it reflect the overall quality of the document.

To the extend that the specification is trying to address a wide audience from implementer, academics and application programmers, it should appear more correct in its presentation and quality.

I recommend, that the specification should undergo a significant editorial review, which should be conducted by the ECMA organisation  
DK-74 Part 4   Ed Several tables used for description  elements and attributes through-out part 4 lack the upper border. I have found no explanation to this, and while the problem doesn't interfere with the understanding of the specification, the sheerer amount of this problem indicate yet another quality-problem and the appearance of the specification. It gives a “sluppy” impression, and reflect back on the quality of the whole documentation I recommend a thorough review of the whole text, and to apply a consistent style to tables  
DK-75 Part 4   Ed According to ISO Directives part 2, fifth Edition 2004, Annex H page 65, it is not recommended to use “must” as an alternative to “shall”. A text search an inspection of part 4 reveals 370 instance, where the specification have used “must” as an alternative to “shall”

This evaluation should also be conducted on the remaining parts of the specification. The initial investigation shows, that only part 5 seems to error-pruned for the word “must”

While this could be perceived as a minor error it indicates the lack of basic prof-reading of the specification, and add to the overall impression of an unfinished document, which have been submitted before basic editorial work was conducted on the specification. While we understand the time-pressure, in which the ECMA TC-45 have finished a document in such large proportion we find it unacceptable that the review-period is used to identify such minor but important error-correction. One would expect a professional organisation like ECMA to conduct a more rigid quality-review before submitting specification to ISO/EIC fasttrack processing, but it appears that this is not the case with the ECMA-376 specification.

I recommend a thorough review of the whole text, and to ensure, that the text is in line with ISO/EIC recommendation and requirements, as described in ISO/EIC Directives Part 2, fifth Edition 2004, Annex H page 65  
DK-76 Part 4   Ed Part 4 include several pictures, where a high proportion of these is blurred, and some degree of “unreadable”.

In some cases this could lead to misunderstanding the specification, which is addressed separately. It again reflect back to the appearance and quality of the document. It gives it an “unfinished”  appearance which I wouldn't expect from a finished specification.

The higher quality and clearer appearance would improve the “readability” of the specification.

Each case is a matter of a minor editorial adjustment, but the magnitude of the problems seems to call for general attention to the overall quality & appearance of the document.

I recommend the whole documentation undergo a thorough review, where the need for actual picture is re-evaluated and replaced by text where appropriate.  Many of the included XML Schema fragments appears to have these problems, recommend  these to be typed, for higher quality and better appearance.  
DK77 Part 4

Section 2.2

Page 26

line 24-28

Ed The introduction of the most important subpart is confusing, as it imply, that other parts can be neglected, and it would be harmless to remove everything else. Which is not the case. Remove reference to “most important” and reconsider the message, that need to be placed here. Is it the “top-element” the initial element the core-element, what is the story here  
DK-78 Part 4

Section 2.2.1

Page 28

line 1

Ed The line regarding presented colour is unsolicited in a specification, which focus on definition of content and not the presentation. Refer to as defined colour  
DK-79 Part 4

Section 2.2.1

Page 28

line 1

Ed The example is to illustrate the possible suppression of “documentwide” settings. The Example is overloaded with funny calculation examples, that add only to the confusion. Rewrite the example  
DK-80 Part 4

Section 2.16

  Ed This section include several definition of field, according to part 1 section 5 all new term is expressed in Italics. It seems that there is a mixed between capital letters and italic capital letters in the definitions section 2.16 As this section indicates it is the definitions-section it should either have all field definitions in italic capital letters, or otherwise adhere to the convention described in part 1 section 5  
DK-81 Part 4

section 2.16.5

Page 1507 Ed In the descriptions “document automation” user correct pluralis “ replace “run” with “runs”  
DK-82 Part 4

Section  2.16.5.35

Page 1539 Ed The Screencapture in the exmaple for the /h field argument is in poor quality Rewrite the example  
Dk-83 Part 4

Section 2.16.5.36

Page 1540 Ed The Screencapture in the example for the /k fiel argument is in poor quality Rewrite the example  
DK-84 Part 4

Section 2.16.5.77

Page1570 Ed The function is USERINITIALS, but the example uses USERNAME Correct the example  
DK-85 Part 4

Section 3.2.3

Page

Line 19

Ed The sentence “You can create more than one view of the same workbook without saving separate copies of the workbook” is a reference to dynamic behaviour, which as stated in Part 1, section 2.3 is outside the scope of the specification Remove the Sentence  
DK-86 Part 4

Section  3.10

Page 2236 Ed The  Screencapture is blurred and in poor quality Replace with a better looking picture  
DK-87 Part 4

Section 3.17.7.249

Page 2745

line 113

Ed The Sentence read “significant figures”  I had expected it to read “significant digits” Replace “significant figures” with “significant digits”  
DK-88 Part 4

Section 3.17.7.343

Page 2820 Ed The screencapture of the equation is in poor quality an unreadable, Replace with a readable version  
DK-89 Part 4

Section 3.18.95

Tabel Ed The listes URL-link is missing “:” so they wouldn't work Replace “http//” with “http://”  
DK-90 Part 4

Section 6.1

Page 4343

Line 3

Ed The reference to “this namespace”  is without any reference in the sentence.

Best guess is the VML  namespace, but could also be the SpreadsheetML og DocumentML mentionen in the sentence before

Clarify either by giving the excat name of the namespace in reference.  
DK-91 Part 4

Section 6.1

Page 4343

line 5

Ed It is not clear what is the relationship between  “this namesapce” and  “other VML namespaces” Where does this fit into the OOXML namespaces as defined elsewhere. And are there different relationsshipd If these other VML namesspace are related to the ECMA-376 specification it should be clarified how this relationsship is, otherwise remove the reference to “other VML namespaces”  
DK-92 Part 4

Section 6.1

Page 4343

line 9

Ed The sentence specify the legacy origin of the format, and reference  Office 2000, The history of the VML development have no meaning in the context of a ECMA-376 Specification Remove reference to Office 2000  
DK-93 Part 4

Section  6.1.2.1

Page 4352 Ed The attribute dmglayout is stated as not to be meaningfully for the “arc” element, as they only apply to organization chart.

It is confusing that the definitions is placed in this context as it fail to connect toi the meaning of the section. To define a segment of an arc.

The provided drawing in explanation doesn't reveal any additional context

Most like we would recommend removing the explanation, as it do no help to description  
DK-94 Part 4

Section 6

  Te The Introduction note to Section 6 mention in itself, that the VML part is “Deprecated”, and the DrawingML described in Part4, Section 4 is a newer and richer format, created for eventual replacing VML.

It makes no sense to create an international standard of a specification, which is clearly described as being  “predicated” the whole idea with the standardization is to promote best practice, and “predicated” specification is in nature. “not best practice”. It should be necessary with only one drawing specification.

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.  
DK-95 Part 1

Introduction

Page xii

line 7

Ed The phrase about “.. Fully compatible” is not possible within the current specification since it in some portions don't give a specific description or definition os required parts of the specification “ e.g  Part 4 page 1378 line 12-17) which state that the implementer should do there best effort to  imitate a behaviour, which could have several outcomes. This indicates that there is no unambiguous way to archive the goal of “Fully compatible” Replace “Fully compatible” with high fidelity.  
DK-96 Part 1

Section 2.4

Page 3

line 22-23

Ed It is contradicting statements about the versions of Unicode standard is required. Part 1  Annex A page 161 , line 19-20 refer to version 4, while the XML 1.0 specification uses Unicode version 2 Provide an explicit Unicode version in part 1,  section 2.4 “Document Conformance”  
DK-97 Part 1

Section 9.1.1

Page 16

line 11

Ed The reference to ASCII characters should include a version reference, since there exist several version, which could apply. A precise version reference would eliminate any confusion from the implementation. It is crucial to the implementability of the specification that it is precise and thorough when it reference other standards. The ASCII is not defined in Part 1 Section 4 Include a precise reference to the actually ASCII version, which is intended e.g ISO/EIC 646:1983  
DK-98 Part 1

Section 9.1.5

  Ed This section clearly state, that interleaving is not allowed in Office Open XML packages, while Part 2 section 9.1.4 (page 30 , line 2) describe how Interleaving is implemented in the OPC. Since interleaving is not allowed in Office open XML, but clearly defined in Part 2, this would probably be missed by implementer and could lead to confusion and “incompatibility” Not a necessary part of the information specification.  
DK-99 Part 1

Section 10.1.2

Page 23

line 20

Ed This section refer to part 5 Clause 12 for additional information, while this clause does exist it is marked informative, and contain no information about the extensibility of a specific markup language Suggest change clause to ref. to clause 11 in part 5.  
DK-100 Part 1

Section 11.3.1

Page 28

Line 15-17

Ed This sentence require the application to do an interpretation of legacy-text like RTF and MHTML, as specified in line 3, and expect all consumers to understand these proprietary specification.

As i understand this element, as the place holder for any additional import filter which an implementer would like to build in there “Office Open XML consumer” application. There shouldn't be any specific reference to proprietary format, as this would mean that any implementation should support these proprietary format. This could lead to some confusion around patent rights of the application.

Remove the references in line 3 towards specific application formats. This would allow any implementer to decide, which “import-format” they would like to provide additional support from.  
DK-101 Part 1

Section 12.3.5

Page 68

line 22

Ed This binary element is intended to store “arbitrary user-defined data”, but give no details about the actions, that actually initiate the usage of this binary element. This seem to introduce a large “unknown” container into which any binary information can be stored. Without any detailed definition it is impossible to implement any kind of interoperability to such a “construct” Suggest that the custom XML mapping part shall only be used when no other mapping parts in ISO/IEC 29500 OOXML apply.  
DK-102 Part 1

Section 15.2.6

Page 142

line 3

Ed The sentence “This part shall have no content”  lack a definition of “no content” does this mean a zero-byte file, or only contain “spaces” or an “End_of_line” char or a “CR/LF” or... Be precise to  what is meant by “no content”, and have a clear definition, what is expected from a “no content” file  
DK-103 Part 1

Section 15.2.6

Page 142

Line 4

Ed The sentence fail to give the definition of the Digital Signature origin part as it state “ ...it shall the target of a relationship...” but the “traget” is missing Give a proper definition, seems like some words is missing here or something else is missing  
DK-104 Part 1

Section 15.2.12

Page 154

line 12

Ed The specification for application/x-font-ttf  expect either a TrueType or Opentype format, but lack a precise indication of which specification of  TrueType or OpenType format is expected. This could lead to confusion, if it is expected to support all version or a specific version of these specification of both TrueType or OpenType font's Provide a precise definition.  
DK-105 Part 1

Section 15.2.14

Page 155

Line 23

Ed The specification of the Printer setting is “application defined”, which will introduce in its current crude implementation will become a issue for Cross-platform implementation. If the Print-setting is included in the files as a binary object as described n the examples, it will become a limitation for cross-platform adoption of the specification. The reference to using DEVMODE structure example from windows offer several problems and concern to the cross-platform abilities of the specification. We recommend a platform neutral description of the print settings, it should be evaluated if such technologies could be replaces, which would offer a true Cross-platform printer specification  
DK-106 Part 2

Section 3

Page 4

line 1-3

Ed This definition describe interleaving parts, but from part 1 Section 9.1.5 ( page 16 line 27) we have, that Office Open XML files are not interleaved, and from Part 2 Section 1 ( page 1 line 2-3) we, have the scope of part 2 is the specification set that are used by Office Open XML, so it should not include any reference to “interleaving” Not a necessary part of the information specification.  
DK-107 Part 4

Section 2.3.1.8

Page 59 Ed The cnfStyle element is presented as a bitmask, which isen't  considered best practice, when representing setting in XML-specification. The adoption of XML-manipulation using XSLT is increased, which appear to place an unnecessary implementation burden on would-be application developers Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-108 Part 4

Section 2.4.7

Page 302 Ed The cnfStyle element is presented as a bitmask, which isen't  considered best practice, when representing setting in XML-specification. The adoption of XML-manipulation using XSLT is increased, which appear to place an unnecessary implementation burden on would-be application developers

Apperantly there is no difference between cnfStyle from section 2.3.1.8 and cnfStyle from section 2.4.7 cnfStyle it should be considered, if only one of these definitions is sufficient

Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-109 Part 4

Section 2.4.8

Page 304 Ed The cnfStyle element is presented as a bitmask, which isen't  considered best practice, when representing setting in XML-specification. The adoption of XML-manipulation using XSLT is increased, which appear to place an unnecessary implementation burden on would-be application developers

Apperantly there is no difference between cnfStyle from section 2.3.1.8 and cnfStyle from section 2.4.7, and 2.4.8 cnfStyle it should be considered, if only one of these definitions is sufficient

Suggest change the word bitmask to something that better represents the term. E.g. flag-list  
DK-110 Part 4

Section 2.4.51

Page 428 Ed The tblLook element is presented as a bitmask, which isen't  considered best practice, when representing setting in XML-specification. The adoption of XML-manipulation using XSLT is increased, which appear to place an unnecessary implementation burden on would-be application developers Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-111 Part 4

Section 2.4.52

Page 430 Ed The tblLook element is presented as a bitmask, which isen't  considered best practice, when representing setting in XML-specification. The adoption of XML-manipulation using XSLT is increased, which appear to place an unnecessary implementation burden on would-be application developers Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-112 Part 4

Section 2.8.2.2

Page 739 Ed The definition of charset and the description appears ambiguously, as there are adoption a free language form instead of a specific notation.

E.g the specification like ANSI, could cover several version and “Eastern Europe..” could mean several different things

altos from a local point of view a “Nordic language” could be considered, which should cover both Scandinavian Icelandic and Faero island specific character set

Provide a nominative specification of the intended coverage of the individual setting  
DK-113 Part 4

Section 2.15.1.28

  Ed This section goes into lengthy detail to describe the algorithm for algorithm for an attempt to secure the document. While such security features is preferable, it should rely on a  well-know and interoperable algorithm like e.g SHA-256 for document protection. The description of the hash algorithm shall be made informative. We suggest that in the first section of this part of the document a recommendation is made to use existing security hash algorithms e.g. FIPS 180 compliant algorithms. It should be emphasized that the described hash algorithm is for backwards compatibility only.  
DK-114 Part 4

Section 2.15.1.29

Page 1172

line 9

Ed The option to provide a classification of document gives some interesting possibilities. Unfortunately is the provided  options: “letter” “email” or “notSpecified” so weak, that it makes no sense .   The feature should either provide universal value, which expect a wider adoption of text document beyond letters and E-mail, e.g manual, reports, handbook etc etc Suggest to expand in the future.  
DK-115 Part 4

Section 2.15.1.86

Page 1251

line 8

Ed The adoption of bitmask for provide content filtering is a “first of it's kind” in XML definitions. The adoption of bitmask operation is a vell-know concept used id different programming disciplines, but the tools for manipulating and operating on XML files like XSLT is not design for bitmask operation, as this is an methodology adopted from CPU-kind of operations.

The adoption of bitmask for filtering also induce unnecessary constrains on the specification, as it is difficult to expand it beyond the current definitions

Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-116 Part 4

section 2.15.1.87

Page 1253

line 4

Ed The adoption of bitmask for provide content filtering is a “first of it's kind” in XML definitions. The adoption of bitmask operation is a vell-know concept used id different programming disciplines, but the tools for manipulating and operating on XML files like XSLT is not design for bitmask operation, as this is an methodology adopted from CPU-kind of operations.

The adoption of bitmask for filtering also induce unnecessary constrains on the specification, as it is difficult to expand it beyond the current definitions

Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-117 Part 4

Section 2.15.2.32

Page 1337 Ed This element seem to be defined with specific browser in mind, and dosen't offer the ability to adopt to the dynamics and development of web-browser market.

It only support a very limited set of functionality, which is most likely obsolete, sine it support very old browsers, and don't allow for neither current browser-set or provide options for adoption of future browsers.

The element seems  limited in its definition compared to some of the more dynamic behaviour we see from browsers to day. The four parameter specified seem to only cover a part of what is possible

Suggest that the table is made informative.  
DK-118 Part 4

Section 2.16.1

Page 1689

line 17

Ed The definition refer to “ one ot two Latin letter” without any strict definition what is meant by .. “Latin letters”

This lead to possible ambiguously interpretation of the rules. As the means of definitions doesn't offer any explanation  or any direct hint of the actual notation, it should be clarified.

Suggest definition of “Latin Letters”.  
DK-119 Part 4

section 2.16.5.5

Page 1512

line 11-12

Ed According to the text this element is not expected to be used, since the recommendation is to use the element LISTNUM (2.16.5.40),

for this reason there should be no need to include the element in the specification, as the field is just a “place holder” for legacy reason to older version of Microsoft Office file formats

It appears that LISTNUM includes the same as AUTONUM why the latter seems superfluous.  
DK-120 Part 4

section 2.16.5.23

Page 1531

line 12

Ed The FILENAME field assumes, that all file are stored at disk, and the /p extension assumes that this disk is a permanently attached disk.

While this would have been the expected behaviour in the past, the current technology offer a wide variety of ways to store file, using other means that a physical disk-systems. This specification doesn't account for the possibility to store information in CMS solutions, different kind of container applications or dynamic storage content management systems.

Evolving and future requirements like “internet-storage”  or  close proximity is not possible with the limited definitions as described here

This feature seems to mimic old-days storage of files, and doesn't offer support for any future directions. What about the suggest part like  https://getmyownfiles.org/fetch_bestfile(test.docx)

Clarify path is inherited from the location of the file.  
DK-121 Part 4

Section 2.16.5.31

Page 1536 Ed The HYPERLINK offer several field-specific-switches, which is open for interpretation, which should be clarified in this context

the \n option indicate, that the destination site is open in a new window. Would than mean a new application window, or a “default browser window” or a third-party application window

Be more precise, what the intended meaning of the phrase “ a new window” is expected in this context, While it comes to behaviour it could imply several options, which would make it impossible to accomplish the goal of providing interoperability across several office productivity applications

Suggest clarification of the term “new window”.  
DK-122 Part 4

Section 2.16.5.31

Page 1536 Ed The HYPERLINK offer several field-specific-switches, which is open for interpretation, which should be clarified in this context

the \t have the possible value of _blank which  indicate, that the destination site is open in a new window. Would than mean a new application window, or a “default browser window” or a third-party application window

Be more precise, what the intended meaning of the phrase “ a new window” is expected in this context, While it comes to behaviour it could imply several options, which would make it impossible to accomplish the goal of providing interoperability across several office productivity applications

Suggest clarification of the term “new window”.  
DK-123 Part 4

Section 2.16.5.34

Page 1538 Ed The \n  field-specific-switch an XPATH formated namespace mapping. Since XPATH exist in different version it should be stated precise, which kind of XSLT is expected Define the expected version of XPATH  
DK-124 Part 4

Section 2.16.5.34

Page 1538 Ed The \t  field-specific-switch specifies an XSLT to format the XML data. Since XSLT exist in different version it should be stated precise, which kind of XSLT is expected Define the expected version of  XSLT  
DK-125 Part 4

Section 2.16.5.34

Page 1538 Ed The \x  field-specific-switch an XPATH formated string to be returned. Since XPATH exist in different version it should be stated precise, which kind of XSLT is expected Define the expected version of XPATH  
DK-126 Part 4

Section 2.16.5.35

Page 1540 Ed The adoption of the ST_LangCode as the argument to the \z field-swich-argument will limit the possible language settings of an INDEX to include only those language available in the definition of ST_LangCode part 4 section 2.16.52 page 1748

this would limit the international af the specification, since it seems to only allow language setting af INDEX based on the limited languages-set as defined in the ST_LangCode

Should add a normative comment that ST Lang (2.18.51) is the preferred language code representation.

The reference to ST_LANGCODE in the z-switch in 2.16.5.35 should be changed to references to language code - i.e. 2.18.51.

 
DK-127 Part 4

Section 2.16.5.39

Page 1542

line 27

Ed The description of the LINK state, that it uses OLE to link to the original source file. Since OLE ( Meaning Object Linking and Embedding) is a Microsoft specific technology, which isn't available on all platform, the requirement to use OLE to the original source file indicate, that the specification can't be adopted to all platforms

Since OLE technology is protected by Microsoft patent and IPR rights is also suggest, that there is potential patent constrains involved in adoption of the ECMA-376 specification.

Since

Suggest delete the phrase “using OLE”  (line 27) .  
DK-128 Part 4

section 2.16.5.72

Page 1565

line 18

Ed The definition “the Gregorian calendar is always used” seems a little weak also compared to the alternate interpretation in Part 4, section 3.17.4.1 Ref. to relevant date representation Part 4  3.17.4.1  
DK-129 Part 4

Section 2.16.24

Page 1602 Ed The attribute tgtFrame offer a _blank value, which is intended to  “Open hyperlink target in a new window”

What kind of “window” is refer in this context

there could be several options and intepretation which would make it impossible to accomplish the goal of providing a specification which provide interoperability across office productivity applications

Suggest clarification of the term “new window”.  
DK-130 Part 4

section 2.18.2

Page 1629

line 27-28

Ed As it appear in the current version of the ECMA-376 Office Open XML specification this accept any value, but assign no directions. This could lead to significant interoperability and upgrade nightmares, since there is no way to ensure, that would-be implementers is using the same notation and interpretation. If every application developer describe this as “myHashAlgoritm” then there will be a potential break of the interoperability goal of the specification.

It also open up for the suggested future expansion of the definition could be in direct conflict with existing implementation, and in this way  break the goal of backwards compatibility

Suggest (if a list exists) list of possible known types and possibility for extension.  
DK-131 Part 4

Section 2.18.11

Page 1695 Ed The adoption of a combined bitmask representation of a series of boolean values is not considered best practice when working with XML specification. The interpretation of bitmask operations isn't feasible within the definition of XSLT, Suggest change the word bitmask to something that better represents the term. E.g. flag-list.  
DK-132 Part 4

Section 3

  Ed There is significant confusion around the adoption of formula arrays in OOXML. There is used several different names like “array formula”, “array-entered formula” and “array entered formula”

While the problems seems editorial it gives technical confusion to reading and understanding the specification.

Choose one term for “array formula” and use in consistently.  
DK-133 Part 4

Section 3.2

Page 1874

line 38-29

Ed The reference to “Sheet1” is confusing on the background of the above attempt to define the meaning of “sheet” using concepts like surface ( is this the screen),  The reference to “discussion in a later section should be more precise as the which section is implied Give the correct and specific number of the section where “Sheet1” will be explained.  
DK-134 Part 4

Section 3.3.1.61

3.3.1.62

Page 1988 Ed The attribute  paperSize contain a wide variety but limited list of paper size specification, which most likely would fulfil the purpose for most organisation,

But the attempt to keep up with is meaningless since there already exist standard specification which should adopted in an attempt to minimize the maintenance burden of the specification.

Suggest add reference to ISO 216 ANSI (with a third column added to the table).  
DK-135 Part 4

3.17.4.1

  Ed The Gregorian calendar is the most widely used calendar in the world. A modification of the Julian calendar, it was decreed by Pope Gregory XIII on 24 February 1582. The Gregorian calendar forms the basis of many international standards such as ISO 8601.

“Date Representation”, conflicts with the Gregorian calendar in the calculation of dates. Specifically, it requires spreadsheet implementations to incorrectly treat the year 1900 as a leap year. This contradicts the Gregorian calendar, ISO 8601 and the civil calendar adopted by most nations of the world.

We strongly suggest to add an addtional new date base system with a NULL date being 1899-12-30 and with the options to use negative serial values. Any future use of functions with date parameter should conform to www.w3.org/TR/2001/REC-XMLschema-2-20010502/   section 3.2.7 and 3.2.9.

Existing date base systems are to be kept for backward compatibility.

 
DK-136 Part 4

3.17.4.1

  Ed ISO 8601 is the ISO standard for date and time representations.

“Date Representation” stipulates that dates must be represented as numeric codes counting from 1900 or 1904. This is in conflict with ISO 8601. This section also forbids applications from supporting years before 1900, also in conflict with ISO 8601.

We strongly suggest to add an addtional new date base system with a NULL date being 1899-12-30 and with the options to use negative serial values. Any future use of functions with date parameter should conform to www.w3.org/TR/2001/REC-XMLschema-2-20010502/   section 3.2.7 and 3.2.9.

Existing date base systems are to be kept for backward compatibility.

 
DK-137 Part 4

3.17.7.224

  Ed An International Standard must take a broader view and provide wide cultural and linguistic interoperability.

The spreadsheet function NETWORKDAYS(). This function is defined by OOXML to return the number of working days between two dates, exclusive of any weekends in that interval. For some cultures, the weekend is Saturday and Sunday. For others, the days of rest are either Thursday/Friday or Friday/Saturday. OOXML does not define “weekend” and does not provide a way for the user to define it either. As implemented in Excel the function assumes the weekend is always Saturday/Sunday. This spreadsheet function is defined in a way which renders an incorrect answer for potentially billions of people across the globe. OOXML lacks cultural adaptability.

Suggest to include optional parameters for describing non-working days which are not holidays.  
DK-138 Part 4

2.15.1.28 
3.3.1.69

  Ed Ecma 376 ignores accepted standards for cryptographic hashes and defies expert standards for cryptography, by proposing its own hash algorithms which are almost certainly flawed.

Cryptography, including the constructure of secure hash functions, is very difficult. Weaknesses are regularly discovered even in publicly-vetted cryptographic algorithms long thought secure, whereas proprietary cryptographic methods not subjected to intensive public scrutiny are nearly always found to be seriously flawed (see e.g. Schneier).

Several government agencies and standards bodies with expertise in encryption have made lists of recommended hash functions, all of which have received extensive scrutiny by cryptographers. For example, in the area of secure hash functions:

* ISO has chosen the "Whirlpool" algorithm as standard ISO 10118-3.

* The W3C, in its XML-ENC standard, includes a list of algorithms: SHA1, SHA256, SHA512, RIPEMD-160.

* The European NESSIE project recommends: ISO 10118-3 ("Whirlpool"), SHA-256, SHA-384 and SHA-512.

* In the USA, NIST recommends SHA1, SHA224, SHA256, SHA384, and SHA512.

* In Japan, CRYPTREC recommends: MD5, RIPEMD-160, SHA1, SHA256, SHA384, and SHA512.

Ecma 376 does not follow the advice of any of these organizations. Instead, it defines new hashing algorithms that have not undergone scrutiny by the cryptographic community.

Ecma 376 defines two very similar algorithms. Nowhere is there clear notification that these algorithms are likely to be extremely flawed and thus should not be used in new applications.

The Emca 376 hash functions are almost guaranteed to be flawed and insecure. This poses two security risks:

#1     The immediate risk is that hashed document passwords may be determinable from the hashed value. Since users often reuse document passwords for other documents and other systems (whether they should or not), including an inadequately reviewed hash function risks enabling forgery and identity theft of many other systems by attackers.

#2     Defining a new hash function inside an ISO standard (giving it the ISO seal of approval) creates the expectation that this hash function has received proper scrutiny by the crytographic community (like ISO 10118-3 has) and is secure. This is likely to lead the industry into using the new insecure hash function(s) in a variety of security-critical applications, making many other security-critical applications directly vulnerable as well.

The description of the hash algorithm shall be made informative. We suggest that in the first section of this part of the document a recommendation is made to use existing security hash algorithms e.g. FIPS 180 compliant algorithms. It should be emphasized that the described hash algorithm is for backwards compatibility only.  
DK-139 Part 4

5.1.12.42 
5.9.2.1 
2.18.105

  Ed Many attributes throughout the Ecma 376 spec take values in "English Metric Units" (EMU). For example, attributes of type ST_PositiveCoordinate are measured in EMUs. This is not a known unit in existing literature. It is only defined inside a paragraph in section 5.9.2.1, so that "91440 EMUs/U.S. inch, 36000 EMUs/cm". Similarly, 2.18.105 specifies "twips"—twentieths of a point (1/1440th of an inch). Suggest to specify “EMU” in the section.  
DK-140 Part 4

2.18.4

  Ed Ecma 376 lists numerous styles such as apples, scaredCat, heebieJeebies, etc. However, the specification does not fully define these styles (e.g missing height, width, color-depth, orientation). The style basicThinLine describes behaviour for horizontal, vertical and corner scenarios but many styles (e.g babyRattle, balloonsHotair, etc) provide no such details.

The problem with this is that a single style can be interpreted differently by different vendors/implementers. Also, these styles provide no generality.

Should provide the design specification needed in a format, which ensures that it is possible to construct a correct implementation.  
DK-141 Part 4

2.18.52

  Ed Ecma 376 uses confusing and inconsistent definitions of values with hexadecimal numbers.

For example, ST_LangCode, is defined on the text as a "two digit hexadecimal code". But the values given cannot be represented by only two hexadecimal digits, but needs four.

One possible interpretation is that by "digit" the spec sometimes means "octet" (i.e., a byte). An octet/byte is equivalent to two hexadecimal digits. If this interpretation is correct, then the specification clearly needs repair, since this is very likely to cause serious confusion in developers trying to implement Ecma 376.

However, in other places (such as the definition for ST_LongHexNumber), it notes that 4 octets can store 8 hexadecimal digits (which is correct), so it is not simply a matter of defining "digit" oddly. This problem also suggests a lack of review, since clearly 4-digit values cannot fit in fields where only 2 digits are permitted.

More examples:

Attribute

Spec says 

ST_ShortHexNumber

"two octet hexadecimal number"  

ST_LongHexNumber

"four octet (eight digit) hexadecimal number" 

ST_LangCode

"two digit hexadecimal code" 

Should add a normative comment that ST Lang (2.18.51) is the preferred language code representation.

The reference to ST_LANGCODE in the z-switch in 2.16.5.35 should be changed to references to language code - i.e. 2.18.51.

Suggest to clarify LangCode and ST_LongHexNumber.

 
 
 
 
 
 
 
 
DK-142 Part 4

2.18.85 
2.15.1.95 
2.18.97 
5.1.12.41 

  Ed Ecma 376 uses four inconsistent notations for percentage units, at least one of which is particularly inflexible:

* Section 2.18.85 uses predefined symbols (like "pct15" for 15%) in 5 or 2.5 percent increments (which is inflexible and difficult to process with standard XML tools, compared to a generic number-valued field)

* Section 2.15.1.95 uses a decimal number giving the percentage

* (Section 2.18.97 uses a number in 50ths of a percent

* Section 5.1.12.41 uses a number in 1000ths of a percent

Suggest consistent use of notation of percent throughout the specification.  
DK-143 Part 4

2.15.3.16

  Ed "doNotLeaveBackslashAlone". "This element specifies whether applications should automatically convert the backslash character into the yen character when it is added through user keyboard input".

This is an application setting, not a document setting.

Suggest that this issue is an implementation issue and not a standardization issue. Remove the paragraph from the specification.  
DK-144 Part 4

2.18.66 
2.9.18 
2.11.17 
2.11.18 
2.15.1.16 
2.6.12

  Ed Inflexible numbering format: ST_NumberFormat, Numbering Format for number lists (2.9.18), footnotes (2.11.17), endnotes (2.11.18), captions (2.15.1.16) and Page numbers (2.6.12).

* Fixed to a few countries. Many regions are not included.

* Contradicts W3C XSLT which ISO 26300 uses.

* Contradicts Unicode ISO 10646.

Provide an unambiguously algorithm for the full interpretation of the suggested numeration series.

Insufficient specified question.

 
DK-145 Part 4

2.18.46 
5.1.12.48

  Ed Ecma 376 contradicts the standard SVG Color Keyword Names's hexadecimal RGB values for given color names.

Color Name  SVG  Ecma 376

Dark blue  00008B  000080

Dark cyan  008B8B  008080

Dark gray   A9A9A9  808080

Dark green  006400  008000

Dark red   8B0000  800000

Light gray   D3D3D3  C0C0C0

Independent of Ecma 376's failure to adopt the SVG standard, its subtle redefinition of existing standardized terms will only lead to further confusion.

In contrast, section 5.1.12.48 "ST_PresetColorVal" (Preset Color Value) matches SVG colors well. Unfortunately, it renames "darkGray" to "dkGray" to avoid self-contradiction at the cost of reducing agreement with the SVG standard.

Suggest to uniform and align colour coding schemas.  
DK-146 Part 4

2.4.51 
2.4.52 
2.15.1.86 
2.15.1.87 
2.8.2.16 
2.18.57 
2.3.1.8 
2.4.7 
2.4.8 
2.18.11 
6.1.2.7

  Ed The bitmasks specified by Ecma 376 are mostly of fixed length (a fixed number of bits). For example, the bitmasks used in sections 2.4.51, 2.4.52, 2.15.1.86, and 2.15.1.87 are all of type ST_ShortHexNumber, which is defined as consisting of exactly 4 hexadecimal digits (16 bits, see above regarding conflicting definitions). The bitmasks in section 2.8.2.16 are of type ST_LongHexNumber (2.18.57) which is defined as consisting of exactly 8 hexadecimal digits (32 bits, see above regarding conflicting definitions). The bitmasks in sections 2.3.1.8, 2.4.7, and 2.4.8 are of type ST_Cnf (2.18.11), which is defined as consisting of exactly 12 binary digits (12 bits). The bitmask in section 6.1.2.7 consists of exactly "three bits".

Because it is not possible to add new bits to a fixed-length bitmask, extensibility is extremely limited.

Also, bitmasks require that some other data be encoded into numbers to be used in the bitmasks. For example, see the language encodings discussed earlier: every language must be assigned an arbitrary numeric code before it can be used. Keeping this mapping up-to-date requires constant maintenance by some body. If not carefully handled, a single vendor could end up having de facto control over this mapping, and as a result that vendor could determine what could be done or not by the format (by refusing to assign mappings useful to a competitor).

Using bitmasks creates a new data model, separate from the XML data model. In particular, the bitmask cannot be described in or validated by XML Schema, Relax NG, Schematron or any standard XML schema language or current validator.

XSLT is the W3C standard for manipulating and converting XML documents, and is by far the most popular tool for working with XML. XSLT has no tools for bitwise operators, since bitmasks are not part of the XML data model.

The TC45 is the Ecma Technical Committee charged with developing the Ecma 376 specification. The charter of the TC45 includes the specific goal of:

    "...enabling the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems"

Since bitmasks cannot be implemented in any of the standard tools for XML data formats, their use is in conflict with the TC45's charter.

The specification should use XML stylesettings instead of bitmaps.  
DK-147 Part 4

6.2.3.17

  Ed "Embedded Object Alternate Image Requests Types" requires implementors to support the proprietary Windows Metafiles. The support for available Object linking technologies should be expanded to support Object linking technologies from Linux platform, This should include support for KParts and Bonobo technologies as know from KDE desktop environment and GNOME linux graphical user interfaces.

Eg. expanding the complexType CT_ExternalLink with:

  • kparts (KParts Link)
  • bonobo (Bonobo Link)
 
DK-148 Part 4

2.15.3.6 
2.15.3.26 
2.15.3.31 
2.15.3.32 
2.15.3.41 
2.15.3.51 
2.15.3.53 
2.15.3.54 
2.15.3.63 
2.15.3.64 
2.15.3.65 
2.15.3.66

  Ed Several sections require the implementor to clone the behaviour of a proprietary product, where the behaviour to clone is not specified.

For example:

* Section 2.15.3.6, autoSpaceLikeWord95. 
* Section 2.15.3.26, footnoteLayoutLikeWW8. 
* Section 2.15.3.31, lineWrapLikeWord6. 
* Section 2.15.3.32, mwSmallCaps. 
* Section 2.15.3.41 shapeLayoutLikeWW8. 
* Section 2.15.3.51, suppressTopSpacingWP. 
* Section 2.15.3.53, truncateFontHeightsLikeWP6. 
* Section 2.15.3.54, uiCompat97To2003. 
* Section 2.15.3.63, useWord2002TableStyleRules. 
* Section 2.15.3.64, useWord97LineBreakRules. 
* Section 2.15.3.65, wpJustification. 
* Section 2.15.3.66, wpSpaceWidth.

Specifications that say "clone this product," instead of explicitly stating what behavior is required, have no place in an international standard. It may also be illegal in some jurisdictions to determine what such a non-specification means, as discussed below regarding end-user license agreements (EULAs).

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification  
 
DK-149 Part 4

6.1.2.19 
6.2.2.14 
2.7.4

  Ed 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.  
DK-150 Part 1, 
11.3.1
  Ed Alternative Format Import Part (RTF)

The RTF support example in 11.3.1 has in a number of discussions been seen as a normative part of the specification although it is stated relatively clear that is an example and that it is a note; hence not normative.

Remove the references in line 3 towards specific application formats. This would allow any implementer to decide, which “import-format” they would like to provide additional support from.  
DK-151 Part 1, 
15.2.14
  Ed Printer settings

The DEVMODE example in 15.2.14 has in a number of discussions been seen as a normative part of the specification although it is stated relatively clear that is an example; hence not normative.

We recommend a platform neutral description of the print settings, it should be evaluated if such technologies could be replaces, which would offer a true Cross-platform printer specification  
DK-152 Part 4, 3.17.4.1   Ed Date Representation

ECMA-376’s date representation based on original implementation in Lotus 1-2-3 secures compatibility with an enormous amount of spreadsheets created over the last 20 years.

Although non-critical it would be nice with support for dates before 1900 / 1904.

We strongly suggest to add an addtional new date base system with a NULL date being 1899-12-30 and with the options to use negative serial values. Any future use of functions with date parameter should conform to www.w3.org/TR/2001/REC-XMLschema-2-20010502/   section 3.2.7 and 3.2.9.

Existing date base systems are to be kept for backward compatibility.

 
DK-153 Part 4

2.15.3.6

2.15.3.26

2.15.3.31

2.15.3.32

2.15.3.41

2.15.3.53

2.15.3.54

2.15.3.63

2.15.3.64

2.15.3.65

2.15.3.66

  Ed Misunderstandings about compatibility attributes

ECMA-376 contains a number of compatibility attributes, ex.:

  • 2.15.3.6 :autoSpaceLikeWord95
  • 2.15.3.26: footnoteLayoutLikeWW8
  • 2.15.3.31: lineWrapLikeWord6
  • 2.15.3.32: mwSmallCaps
  • 2.15.3.41: shapeLayoutLikeWW8
  • 2.15.3.53: truncateFontHightsLikeWP6
  • 2.15.3.54: uiCompat97To2003
  • 2.15.3.63: useWord2002TableStyleRules
  • 2.15.3.64: useWord97LineBreakRules
  • 2.15.3.65: wpJustification
  • 2.15.3.66: wpSpaceWidth
  • Although stated relatively clear in ECMA-376 that applications shouldn’t replicate the behaviour of this attributes, it have created a lot of fuss and misunderstandings.
The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification  
 
DK-154 Part4

sec.6.1

p.4350ff af

5220.

Ed It is not necessary to define a vector drawing standard to obtain 3D graphical functionality. 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.  
DK-155 Part 4

11.3.1

  Ed Ecma376 documents are allowed to embed document data in RTF. But since RTF is a proprietary Microsoft format, such documents will not be readable by non-Microsoft Ecma376 implementations. Remove the references in line 3 towards specific application formats. This would allow any implementer to decide, which “import-format” they would like to provide additional support from.  
DK-156 Part 4

6.4.3.1

  Ed Only proprietary Windows formats like Windows Metafile are mentioned in the list, which makes it impossible to implement Ecma376 in a UNIX or Linux environment. Relevant   additional enumeration values should be added to SF_CF e.g. TIFF, PNG, HTML, JPG or others well-established formats.  
DK-157 Part 4

2.15.1.28

  Ed The described processing steps are ambiguous. In particular SHR and SHL give different results on different machines and with signed and unsigned values The description of the hash algorithm shall be made informative. We suggest that in the first section of this part of the document a recommendation is made to use existing security hash algorithms e.g. FIPS 180 compliant algorithms. It should be emphasized that the described hash algorithm is for backwards compatibility only.  
DK-158 Part 4

2.15.2.32

  Ed Only Internet Explorer and Netscape Navigator are supported. Contemporary non-Microsoft browsers such as Firefox and Safari should be supported.  Suggest that the table is made informative.  
DK-159 Part 4

15.2.14

  Ed “An Office Open XML producer might store the DEVMODE structure...”: This indicates that an implementation on the Windows platform might store printer settings in a Windows-specific format that does not make sense on other platforms. We recommend a platform neutral description of the print settings, it should be evaluated if such technologies could be replaces, which would offer a true Cross-platform printer specification  
DK-160 Part 4

Section

3.17.7.287

3.17.7.50

3.17.7.313

3.17.7.12

3.17.7.4

3.17.7.14

3.17.7.1

  Ed The type of units on the values value for trig functions are not specified (radians or degrees)

SIN

COS

TAN

ASIN

ACOS

ATAN

ATAN2

State that measurements are all in radians  
DK-161 Part 4

Section 3.17.7.17

  Ed AVEDEV function is using an incorrect formula. Correct formula to read :

image

 
DK-162 Part 4

Section 3.17.7.47

  Ed CONFIDENCE function needs some more information Make it clear that this assumed a Normal distribution  
DK-163 Part 4

Section

3.17.7.33

  Ed CEILING( x , significance ) doesn’t round negative numbers like some mathematical formulas (ex. Wolfram http://mathworld.wolfram.com/CeilingFunction.html)

; hence in risk of creating confusion.

Insert a informative note to clarify any possible misunderstandings  
DK-164 Part 4   Ed Minor editorial comments to the following formulas, all found on http://www.xmlopen.org/ooxmlwiki/index.php/3._SpreadsheetML_Reference_Material#3.17.7.17_.5Bp2546.2C_AVEDEV_argument-list.5D
  • CELL
  • CHAR
  • CHIINV 15
  • CHITEST 15
  • CHIINV 15
  • CHANGE 15
  • CORREL
  • COVAR
  • CUBEKPIMEMBER
  • CUBEKPIMEMBER
  • CUBEMEMBER
  • DATE
  • DATEVALUE
  • DAVERAGE
  • DAY
  • DEVSQ
  • DISC
  • DOLLARDE
  • DOLLARFR
  • DURATION
  • EXACT
  • FIND
  • FINDB
  • FINV
  • FIXED
  • FORCAST
  • GAMMAINV
  • HOUR
  • HYPERLINK
  • INTERCEPT
  • IRR
  • KURT
  • LINEST
  • LOWER
  • MDURATION
  • MEDIAN
  • NORMINV
  • NORMSINV
  • OR
  • PEARSON
  • PI
  • RSQ
  • SEARCH/SEARCHB
  • SLOPE
  • STDEV
  • STDEVA
  • STDEVP
  • STDEVPA
  • STEYX
  • VAR
  • VARA
  • VARP
  • VARPA
  • WORKDAY
  • YEARFRAC
Make corrections and necessary clarifications  
DK-165 Part 4

3.1

  Ed The OOXML violates ISO 8601 (dates and times) Ref. to relevant date representation Part 4  3.17.4.1  
DK-166 Part 4

3.2

  Ed ISO 639 (Names and languages) is violated by OOXML by inventing new codes. Should add a normative comment that ST Lang (2.18.51) is the preferred language code representation.

The reference to ST_LANGCODE in the z-switch in 2.16.5.35 should be changed to references to language code - i.e. 2.18.51.

 
DK-167 Part 4

3.3

  Ed OOXML is violating ISO 8632 (Graphics Metafile) by referring to windows metafiles/ enhanced metafiles instead of ISO 8632. The support for available Object linking technologies should be expanded to support Object linking technologies from Linux platform, This should include support for KParts and Bonobo technologies as know from KDE desktop environment and GNOME linux graphical user interfaces.

Eg. expanding the complexType CT_ExternalLink with:

  • kparts (KParts Link)
  • bonobo (Bonobo Link)
 

Relevant   additional enumeration values should be added to SF_CF e.g. TIFF, PNG, HTML, JPG or others well-established formats.

 

MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **)

2 Type of comment: ge = general te = technical  ed = editorial

NOTE Columns 1, 2, 4, 5 are compulsory.

page of 63

ISO electronic balloting commenting template/version 2001-10


Top