Template for comments and observations | Date: 30/08/07 | Document: DRAFT
INTERNATIONAL STANDARD
ISO/IEC
29500 Information technology — Office Open XML file formats |
1 | 2 | (3) | 4 | 5 | (6) | (7) |
MB1 |
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) | Proposed change | Observations on each comment submitted |
AU | ge | Australia abstains from this
ballot, however wishes to provide the following comments as a
contribution. We have abstained from voting as a result of a lack of clear consensus in Australia on this issue, and the lack of a nationally representative technical committee in this area. |
|||||
AU | ge | ISO and IEC need to ensure all appropriate intellectual property declarations are followed and that any material referenced in the document is appropriately available to users of the document. | |||||
AU | Whole document | ge | In Australia and New Zealand
government archival authorities have responsibility for preserving access
to records of Australian Governments over the very long term, irrespective
of the format of those records. Such archives are preserved for a
wide range of government, social, legal and cultural purposes.
Particular concerns arise with the preservation of digital formats.
These include issues about the intellectual property constraints on and
the technical sustainability of digital data formats. Failure to adopt
effective measures for the preservation of digital materials poses
significant risks to the national cultural, social and government
administration values of Australian society.
In Australia and New Zealand the archival approach to digital preservation that is followed by the National and State government archival authorities is founded on a strategy of migrating records from their original formats to formats based on open standards that have better prospects for enabling the records to remain useable over very long periods. Effective implementation of this digital preservation strategy requires the adoption of standards that foster the ready and practical development of rendering tools to ensure that digital records can be made accessible and useable. The OOXML specification as currently drafted remains dependent on proprietary implementations to a significant degree, has IP licensing arrangements that are not standard and that apparently impose significant constraints on use, and poses a considerable degree of implementation complexity. Formats based on such a standard are not likely to be viable for the purposes of preserving access to and use of digital records over the very long term. |
The archives and records community is aware that there has been considerable international interest in the development of the draft OOXML standard. However it is not evident that the interests of the archives and records community has been adequately taken into account in the resulting draft. We support the standardization effort in this area and acknowledges the significant contribution of Microsoft in making its specification available to the process. We believe that further progress in enabling digital preservation can be achieved through expanding such industry collaboration. | |||
AU | All parts | Ge Ed | Where there are multiple standards
in the same space, they should clearly indicate their different
application area. Some reviewers report the name causes confusion.
Some reviewers report that it is important not to differentiate the goals, development method and scope of DIS 29500 Office Open XML with that of IS 26300 ODF in particular. The current name “Office Open XML” is confusing, with ISO Open Document Format (ODF), ISO Office Document Architecture (ODA) and the many various products, notable “Open Office”. Public usage has evolved into “OOXML” and “Open XML” as shorthands. Furthermore, the name may appear to indicate a (non-standard) dialect of XML rather than a use of XML, which would be regrettable. However, because “Office Open XML” is the title of Ecma 376 and in products, it is not suitable to change the name of the technology. A change in the name of the proposed Standard will suffice. |
Change the name of the standard to “Information technology – Product-derived document format Office Open XML” | |||
AU | All Parts | ge ed | Some reviewers found the size and
organization of the draft difficult. It would be burdensome for
maintenance for the current organization to continue.
To encourage maintenance, a split standard would make it easier for working groups and task forces of experts in each field. DIS 29500 is too large, especially part 4, and it contains too much tutorial material. While this material is useful for users, it is burdensome for adequate review, printing and maintenance. VML is deprecated in the DIS and should be removed to its own part or annex. The large size of Part 4 will be difficult for paper versions of the standard, but also makes the electronic version difficult (the PDF links from the TOC do not have sufficient grain to locate clauses.) |
The FDIS should be split into 9
parts, each being capable of being considered complete standards. This
largely mirrors the current chapter arrangement of Part 1 and Part 4, and
would not seem be difficult editorially. The TOC of each should contain
entries for each clause and sub-clause at any level.
Note that Part 3 is removed entirely, as it is informative. The normative parts of Part 1 are put with their appropriate specifications. The general introductory pages are repeated; this follows the pattern of IS 19757 in which all parts have the same introduction or scope material. Part 4 Annex C should be split up. Each part should indicate dependencies on other parts. The Schemas should be available in their own part, as well as being available in file form. Publication-dependent formatting, such as line numbering is not appropriate. However, a clear index to the page number of each global declaration (complex type, element, etc) is important. |
|||
AU | All Parts | Ge ed | The treatment and completeness of
references in the draft is unacceptable, This can be corrected.
Furthermore, it appears that several times there are numbers or codes used without explanation of their provenance. |
Check all parts for references. | |||
AU | Part 1. 2 | Para 2 | Ge ed | Conformance and requirements as
drafted are unacceptable. This can be corrected.
The important word “shall” is defined in Part 1 in a way that accords with ISO Directives Part 1. However, the word “shall” is not used in this specification according to this definition, especially in Part 4. In multiple cases, “shall” is used for optional or even deprecated functionality. For example, in Part 4, s2.15.3 Compatability Settings and its subclauses. Furthermore, Part 1 s2.4 and s2.5 specify that conformance is purely syntactic, which contradicts the definition of “shall” in part 1.2 which speaks of ‘behave’. Some reviewers found the conformance issues unclear, for example with regard to Part 1 s2.15.3 and subclauses. To encourage maintenance, we strongly urge option 1) is adopted. However, we are aware that this requires review of over six thousand uses of “shall”, consequently we suggest that adopting options 2) and 3) should be adopted even if option 1) is not adopted. |
|
||
AU | Part 1, s 8.2 | te | DIS 29500 currently allows
applications to arbitrarily move and rename parts, providing the correct
relationships are kept. However, this works against documents which are
OPC-compliant and also contain data formats that do not use the OPC
relationships system but hardcode locations.
For example, an OPC file that contains various JPEG images together with an HTML file that uses those images and the equivalent Open XML file. If the Open XML application renames the images, the HTML file will be out-of-date. |
|
|||
AU | Part 2, s8.1.2 | te | There is a security issue that the
OPC relationships mechanism allows a kind of obfuscation that can hide
virus or malware or unexpected objects from casual view and detection..
In particular, this is where objects with a .bin extension can be renamed to any other extension, such as .jpg or .txt, and potentially passed through a production process undetected. However, DIS29600 does not specify a macro mechanism or Active X controls. Consequently it is difficult to add extra protection. |
Add text to such as the
following:
“It is a requirement of this standard that dynamic extension mechanisms such as scripting languages and macro mechanisms must use, for the executable parts and their “file extension”, the application/ content type tree, and must not use any of the application/ content types defined in this standard or file extensions belonging to other content types.” |
|||
AU | Part 2, s8.3.5 | Para 2 | ed | The meaning of para 2 is unclear.
What is “ignored content” in this context.
It is strongly desired that any requirements in the specification which causes renaming and removal of parts be made user- and application- optional. |
Clarify para 2. No concrete suggestion is possible in the absence of a clear understanding of the behaviour. | ||
AU | S3.17.2 | te | The syntax of formulas is inadequately described. | Specify the syntax using ISO BNF or similar notation that allows a parser or validator to be constructed. | |||
AU | Part 4 | Ed | The repetition of complex type
declarations in Part 4 increases the size of the specification
unnecessarily.
Furthermore, though well-intentioned, its usefulness for reducing the work in reading the specification is dubious because many of the complex type declarations themselves reference other complex type declarations which are not present. |
Remove all complex type declarations and replace them with a single sentence that references the appropriate section, either in the proposed Part 9 (i.e. the printed schemas) or in another section in a similar fashion to the the way simple types are currently handled. | |||
AU | Part 4, s2.8 Fonts | Ge ed | Through this clause and its
sub-clauses, the relationship with ISO/IEC 9541-4: Information
technology - Font information interchange - Part 4: Open Font Format (dual
numbered as IS 14496-22) is not adequately clear. Presumably this is
because IS 14496-22 was not published until after Ecma 376 was
complete.
In particular this concerns IS 9541-1 s4.1.7 OS/2 – Global Font Information Table. Some reviewers missed that the hexadecimal values in 2.8.2.16 were standard values, and had unnecessary concerns about the use of hexadecimal numbers, in this case. |
|
|||
AU | Part 4, s2.8.2.2 charset | te | The relationship between Part 4
s2.8.2.2 and other standards should be clarified.
Furthermore, IS 29300 matches fonts based on their IANA name, as may be more suited for non-Open Font fonts, such as fonts on Linux. Some reviewers made general comments on the desirability of removing any platform dependencies. Even though Open Font is a standard and Open Type is available on all major platforms, there are some systems, such as Linux systems, where many fonts may use pre-Unicode conventions such as the name of the charset. |
The mapping from values in IS
9541-4 or other standards should be clarified.
If there is no specific mapping, then the definition of s2.8.2.2 should be broadened to also allow characters identified by any string: such as an IANA font name. |
|||
AU | Part 4 s2.18.52 ST_LangCode | te | This data type does not accord with the ISO standard for languages, or with common practise for interchange formats. |
|
|||
AU | Part 4 s3.2.28 workbookPr | ed | The potential use of different date bases, which has a more generalized mechanism in by ODF, combined with the well-known leap-year problem with the 1900 base, means that dates before 1904 are not reliably interchangeable. | Add a warning “Use of dates before
1 Jan 1904 is deprecated.”
Also to Part 4 s3.1.7 |
|||
AU | Part 4 s3.17.6.7 | te | This data type does not accord with the ISO standard for languages, or with common practise for interchange formats. | The definition of s3.17.6.7 should be broadened to also allow standard ISO 8601 dates, in particular, the XSD Date simple type, as well as the digits. Because these are lexically distinct, this should pose no trouble to parsers or datatyping. | |||
AU | Part 4, S5 (throughout) | te | The use of a fixed coordinate
system that allows exact integer division of inches and centimetres is
long established practise in typesetting systems. For example, gruff and
PostScript. The English Metric Units of DrawingML is an example of
this.
However, it is inappropriate that common dimensions cannot be used, and adds an unnecessary burden on the user (i.e. the developer). |
Throughout s5, wherever English
Metric Units are currently allowed, the type should be broadened to also
allow standard measurements such as inches and centimetres. Because these
are lexically distinct, having unit suffixes, this should pose no trouble
to parsers.
The datatype will have to be adjusted accordingly, presumably to a regular expression pattern. As well all types that use EMU must be adjusted. |
|||
AU | Part 4 s7.6 | te | There is no reason to arbitrarily
restrict the sizes of bibliographic fields.
Furthermore, the term “character” is difficult: are Unicode characters meant, or database “characters” which often relate to bytes? |
The ST_String255 datatype should
be removed, and replaced with XSD:String
All places which use ST_String255 should instead have an informative note: “For interoperability, use of strings greater than 255 Unicode characters in length is deprecated.” (or 255/3 = 84 characters if the constraint is bytes and we need to cope with Chinese/Japanese/Korean UTF-8) |
|||
AU | Part 4, 2.15.3 | Bullet list 2 starting “Compatability settings” | te | The usage of “ignorable” in Part 4, s2.15.3 is problematic, since it suggests some unexplained hierarchy: presumably it means that these elements are ignored by Office 2007 or that some typical Word Processor would not be expected to implement them | Change to “intended for use by specialist applications not typical applications.” | ||
AU | Part 4 s2.18.4 | Ed te | It is inappropriate to have a
fixed list of values, both because it is unnecessarily product-specific
and because it creates a maintenance problem.
Furthermore, there appears to be a conflict between the schemas, which specific a closed (enumerated) list, and the text which mentions “possible enumerated values”. So it seems that the intent may have been to have an open list. In other similar cases in the same Part, string types are used rather than an enumeration, so this seems to be a mistake. Furthermore, it is appropriate for information of this kind to be separated into an annex. |
Alter the schema so that ST_Border
uses the XSD token type.
Move DIS Part 4 s2.18.4 into a separate normative Annex: “Basic Border Types”. Rephrase the annex to say “The following border names are reserved by this standard.” |
|||
AU | Part 4 s3.8.40 Table Styles | ed | The phrasing of this section is
unclear, and there appears to be conformance requirements that go against
the “purely syntactic” requirement of Part 1.
Furthermore, it is appropriate for information of this kind to be separated into an annex. |
The meaning of the first paragraph
is entirely unclear and needs to be rephrased.
Move all the built-in style definitions DIS Part 4 3.8.40 into a separate normative Annex “Basic Table Styles”. Rephrase the annex to say “The following style names are reserved by this standard.” |
|||
AU | Part 4 s3.18.96 ST_Xstring (Escaped String) | te | This datatype allows characters
that are not allowed in XML markup to be represented. These primarily
include are control characters.
While this might be a reasonable technique for encoding binary data, as an alternative to XML Schema’s Bin16 and Bin64 encodings, an examination of the elements which are defined using this datatype shows many if not all are simple strings, such as author name. As a consequence, this datatype is highly undesirable and bad practise. In the particular case where a data field is basically textual however it may be generated by a system that does not follow XML conventions, then this data type may be used. |
In almost all cases in s3.18.96
and associated schema components, change the type to reference xsd:String
instead of ST_Xstring. The normal XML restrictions will then apply. This
must be done for all uses in names, titles, ids, numbers, formats,
captions, etc.
(Where a data field is basically textual however it may be generated by a system that does not follow XML conventions, then this data type may be used.) |
All | ge | The following individual
technical comments illustrate reasons why a student assessment may not
be treated fairly and equitably as a result of a failure to address
technical errors in ISO/IEC DIS 29500.
While there are many possible examples that could be used, consider a student submitting a Spreadsheet for an assessable task that relies on various ISO/IEC DIS 29500 formula functions noted below. Unless they are corrected by ISO, these errors (or unspecified elements) could lead to inequity in student assessment. |
||||
Part 4, Section 3.17.7 multiple clauses | te | Trigonometric function which fails to specify which units are used for angles (degrees or radians) | Specify correct units as required | |||
Part 4, Section 3.17.7.17 | te | Incorrect formula for Average Deviation function | Change to correct formula | |||
Part 4,Section 3.17.7.47 | te | Confidence function incorrectly assumes normal distribution, rather than specifying the type of distribution. | Correct function to incorporate specification of type of distribution | |||
Part 4, Section 3.17.7.48 | te | Convert function assumes particular measurements (eg, cup = 8oz/240ml); whereas other countries have alternative measurement (Aust cup = 250ml, UK = 285ml). | Correct function to ensure conversions are based on local standards, not a single US standard. | |||
Part 4, Section 3.17.7.352 | te | Text instruction gives incorrect formula description (“where x is the sample mean” instead of “where x-bar is the sample mean”), which would lead to incorrect calculations if used. This problem applies to 8 other statistical functions. | Correct the instructions. | |||
Part 4, Section 3.17.7.33 | te | CEILING function based on incorrect formula, gives incorrect answers (eg, CEILING (-4.5) = -4, not -5 as incorrectly calculated by ISO/IEC DIS 29500). Also, CEILING provides incorrect help text | Correct errors in formula and help text |
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 11
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|