Template for comments and secretariat observations | Date: 2007-08-28 | Document: ISO/IEC DIS 29500 |
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) by the MB | Proposed change by the MB | Secretariat observations on each comment submitted |
CH | Results of the Comments
Resolution Meeting (2 August 2007)
Version 0.1 of 3 August 2007 The following table displays the results of the comments resolution meeting for the DIS 29500 ballot held on 2 August 2007. The document has been derived from the notes taken during the meeting, and contained in original form in document CRM_Outcome.pdf, posted on Livelink in UK14 folder 02 (DIS29500 CRM sub-folder). Colored type is used as follows:
Text for submission to ISO has been worded suitably. Conclusions have been worded and enhanced to be understandable by those not at-tending the meeting. Hereby, the aim was not to change the meaning. Those who did attend the meeting are kindly asked to compare this document with the orig-inal text in CRM_Outcome.pdf and to advise me of any perceived change of meaning or any inconsistency with that document. Corrections and proposals for improvement of the wording are as well welcome. Conclusions are of the following types:
|
|||||
CH | Part 1, intro-duction (page xii) and entire document | ed | It is not acceptable for an
international standard to be designed primarily around the goal of
compatibility with a particular company's products.
Justified by JTC1 Directives section 1.2 Interoperability, Annex I Interoperability Policy. Established: DIS 2950 is related to MS file formats. Established: It is common JTC1 practice to issue stan-dards of imperfect interoperability, such as JPEG1, JPEG2000. Established: Major Swiss users accept OOXML for its improved interoperability. Rejected: Based on the preceding claims established, it was rejected that it should not be acceptable of OOXML to be primarily targeting MS file formats. The comment is not admissible by JTC1 Directives sec-tion 13.4, as clearly being a contradiction to be ad-dressed during the review period, no longer applicable during the 5-month ballot. This is particularly inappropriate where, as in the pre-sent case, compatibility with an existing international standard is neglected in favor of the one-sided goal of maximal compatibility with document file formats intro-duced by one company, and where the proposed stan-dard does not provide equal opportunities for compatibil-ity to that company's present and future competitors. Rejcted, as not justified by JTC1 Directives and practice. Unless this shortcoming of DIS 29500 is fixed, accepting this specification as a national or international standard would be a violation of Swiss and international law. DIS29500, which is related to Microsoft file formats, does not explain the mapping to ODF. |
Change the goal from being
„fully compatible“ with „existing investments in Microsoft Office
documents“ to seeking at attain the same high level of compatibility not
only with Microsoft's formats, but also with the international norm
ISO/IEC 26300 (OpenDocument). Review the entire draft standard and modify
it corresponding to this revised goal.
Add to introduction: "Attention is drawn to DIN document (MS to provide reference) regarding mapping between OXML and ISO 26300 – 2006." |
||
CH | Entire document | ge | Microsoft's “Open Specification
Promise” is explicitly re-stricted to only “the required
portions of the Covered Specification” (emphasis added). While
this promise may be valuable with regard to specifications that de-clare
all of the important functionality as required and only unimportant
additions as optional, in DIS 29500 sections 2.4, 2.5 and 2.6 clearly (and
in fact appropri-ately) describe most of the functionality provided by DIS
29500 as optional rather than required for a conforming implementation.
Established: MS is offering at least RAND conditions. Rejected: The claim that MS failed to provide the patent information was rejected. |
Microsoft should publish a stronger “open specifi-cation promise” which is not limited to only the “required” portions of covered specifications. | ||
CH | Entire document | ge | There is at least legal
uncertainty about whether Micro-soft's “Open Specification Promise” is
compatible with the GNU LGPL license under which OpenOffice,
Rejected as JTC1 Directives do not require GNU LGPL compatibility. Not admissible: Licensing compliance is not in UK14's authority, but only in ITTF's. Contradictions regarding li-cencing must be addressed in the review period and are no longer admissible during the 5-month ballot. which is currently the primary competitor to Microsoft's office software, is licensed. Richard Stallman, the au-thor of the GPL and LGPL licenses, has publicly stated that relying on Microsoft's promise (this presumes ac-cepting Microsoft's patents as valid) would violate the GPL (see http://www.eweek.com/article2/0,1759,1829728,00.asp ). Stallman's remarks apply equally to the LGPL, the relevant provisions of which are identical to those in the GPL. Microsoft's website addresses the question of the GPL compatibility of the “Open Specifi-cation Promise” by refusing to take position on this question, stating only that the GPL “is not universally in-terpreted the same way by everyone” and “based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).” While it is certainly true that free soft-ware and open source licenses exist which are compati-ble with Microsoft's promise, the primary question is whether DIS 29500 can be implemented in derivative works of the LGPL-licensed OpenOffice software. It is not fair if only Microsoft can implement the standard di-rectly in their office software while competitors have to use a different format internally and must rely on docu-ment format conversion utilities. |
Microsoft should, in addition to the “open specifi-cation promise”, make any relevant patents it controls available under a license which is clearly compatible with GPL and LGPL. | ||
CH | Part 2 | ed | There are many normative references to “the
ZIP file format specification”, but no actual such specification is
included and no explicit reference to any such external document is
provided.
Accepted |
Provide a detailed specification
for the “ZIP for-mat” or provide a normative reference to a speci-fication
which must itself be an open standard
Resolve this in the same way as ISO 26300 does. |
||
CH | Part 3, 3.16.9 Part 4, 3.17.4.1 |
te | Disallowing dates before 1900 in spreadsheets
is wrong. There are people alive today who were born before 1900.
Historical studies often consider dates before 1900.
Accepted |
Allow the “serial value” to be negative in the 1904 baseline syste | ||
CH | Part 4,
3.17.4.1 |
te | DIS 29500 specifies that in the
year 1900, “for dates be-tween January 1 and February 28, WEEKDAY shall
return a value for the day immediately prior to the cor-rect day” and also
assigns a “serial value” to the non-existing day February 29, 1900. This
is wrong. Software bugs should be fixed, not exported by means of ISO
standards to the programs of competitors.
See next comment |
Make the calendar system configurable, with a default of the Gregorian calendar, allowing alter-natives to be specified by means of providing co-de for the computation of year, month, weekday and day-of-the-month. This mechanism can then be used for replicating the broken behavior of Microsoft Excel where that is desired. | ||
CH | Part 3,
3.16.9.1– 3.16.9.3
Part 4, 3.17.4.1 3.17.6.7 |
te | Having two different date
systems with different base dates side-by-side in the same standard
document for-mat makes no sense. Rather, it is appropriate to fix a single
base date. Applications which use a different base date can convert from
the date representation used in the standard document format to the
applica-tion's preferred date representation, and vice versa.
Acknowledged. Established: The two base dates pose problems. Established: Conversions must 1-t bidirectional conver-sion. The coexistence of the two baseline systems causes some problems. |
Delete all references to the
“1904 base date sys-tem”.
Add the following text MS to specify the text posi-tion: "Implementors are encouraged to use the 1904 baseline system avoiding the 1900 baseline system's leap year bug. " |
||
CH | Part 4,
3.17.4.2 3.17.6.7 |
te | In the internet age, it is
inappropriate to represent times simply as a numeric value without
timezone information.
Acknowledged In OOXML, time values in cells are represented in UTC not by default. |
Specify that when stored in
OOXML files, dates and times are always expressed in terms of UTC. Add a
mechanism for storing in the file informa-tion on what timezone should be
used to repre-sent the time in human-readable form.
In OOXML, UTC is default for metadata, serial time for cell data. UTC strings can also be placed in cells, or created using string manipulation func-tions on other cells. Request to illustrate this with some informative examples. Illustrate by some informative examples the placement of UTC strings in cells, or their crea-tion from other cell data |
||
CH | Part 4,
3.17.4.3 |
te | The “combined date and time representation” is
broken in Switzerland and all other locales which switch to
day-light-saving time and back, on those days which are 23 hours or 25
hours long instead of the usual 24 hours.
Acknowledged |
This problem is most easily
avoided by always using UTC for the “combined date and time
rep-resentation”.
Clarify the behaviour on transitions to daylight saving time and back. |
||
CH | Part 4,
2.18.52 |
te | Having two different language
representation systems, one based on ISO standards and one with arbitrary
hex-codes for a subset of the languages makes no sense. Applications which
use arbitrarily-chosen numeric val-ues to represent some languages can
convert from the standard language representation system to the codes they
use internally, and vice versa.
Withdrawn, but underlying problem acknowledged. DIS 29500 defines two language codings. |
Delete all references to
ST_Langcode.
Add the following text MS to specify the text posi-tion: "Implementors are encouraged to use the ISO-compatible coding." |
||
CH | ge | Die Norm wäre nicht aus der
vereinten Erfahrung und Expertise aller interessierten Kreise entstanden
(z.B. Produzenten, Verkäufer, Käufer, Nut-zer und Regulatoren), sondern
nur durch Microsoft allein.
Rejected |
||||
CH | ge | Es existiert bereits die Norm
ISO26300, auch Open Do-cument Format (ODF) genannt. Eine doppelte Normung
erhöht die Kostenbelastung sowohl für uns als Anbieter als auch für unsere
Kunden.
see above |
||||
CH | te | Die Spezifikation verletzt
andere ISO Normen, wie zum Beispiel ISO 8601 (Darstellung von Datum und
Uhrzeit), ISO 639 (Namenund Landerkürzel) see above oder ISO/IEC 101183 (Kryptographischer Hash).
Eine Doppelnormung see above in diesem Be-reich hat ebenfalls viele zusätzliche Kosten für uns und unsere Kunden zur Folge. Established: Various popular hash algorithms are fore-seen in OOXML, as well as some proprietary ones (see Part 4, 2.15.1.28) |
Rejected: Request to discard the proprietary has algorithms | |||
CH | te | Mehr als 10% der Beispiele in
der Spezifikation erfüllen nicht die Anforderungen gültigen XMLs.
Acknowledged. There are some editorial and technical deficiencies present. |
No change, as the submitter failed to provide ex-amples. Editorial and technical corrections are known to be submitted by other countries, and to be welcomed by SC34. | |||
CH | te | In dem Spezifikationsdokument
fehlen Informationen, zum Beispiel über die Bedeutung von Definitionen wie
autoSpaceLikeWord95 und use-Word97LineBreakRules. Dies erschwert ebenfalls
die Interoperabilität mit unseren Produkten.
Established: These definitions are missing. Established: These elements are not required by imple-mentations. Rejected: Claim that missing definitions cause interop-erability problems |
No change | |||
CH | te | Es besteht ein Designfehler in
der Definition des Tabel-lenkalkulationsformats, welcher das Einfügen
eines Datums unmöglich macht, das vor dem Jahr 1900 liegt. Dieser Fehler
betrifft sowohl die OOXMLSpezifikation als auch SoftwareProdukte wie
Microsoft Excel 2000, XP, 2003 und 2007.
see above |
||||
CH | ge | Es existiert keine belegte
Implementation der OOXMLSpezifikation. Microsoft Office 2007 unterstützt
lediglich ein Derivat von OOXML, aber kein Dokumentenformat, welches mit
der Spezifikation übereinstimmt. Dies bedeutet für uns eine Unsicherheit
bezüglich der Interoperabilität mit Microsoft Office 2007 und anderen
Produkten, wel-che die Spezifikation erfüllen.
Acknowledged that the current version of MS Office 2007 may not be 100% compliant with DIS 29500. |
MS aims to be compliant with DIS 29500, and will treat examples of the contrary as bugs. UK14 members are encouraged to report such exam-ples to the following link. | |||
CH | ge | Der vorliegende Standard ist
teilweise von Patenten be-troffen. Eine Implementation ist daher stets mit
Kosten für die Lizensierung der Patente ver-bunden und macht eine freie
Implementation. des Standards unmöglich. Dies ist nicht im Interesse
unserer Kunden.
Wir bedanken uns für diese Gelegenheit, unsere Mei-nung zur ISOStandardisierung von Microsoft. see above |
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 8
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|