Template for comments and secretariat observations | Date: 2007-09-01 | Document: DIS 29500 |
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:
|
|||||
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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:
|
||||||
DK-148 | Part 4
2.15.3.6 |
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. 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 |
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.:
|
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 : | ||||||
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
|
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:
Relevant additional enumeration values should be added to SF_CF e.g. TIFF, PNG, HTML, JPG or others well-established formats. |
1 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
|
![]() |
|