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 in black type (quotes " ": Text for inclusion into the DIS 29500).
  • Original text as submitted by the member but not for submission to ISO in gray type. This may occur either because the comment was rejected, or another text was deemed preferable.
  • Conclusions not for submission to ISO in red type
  • Text to be replaced in the next document version in green type

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:

  • Justified by JTC1 directives: It is justifiable by the JTC1 directives to issue the comment to ISO.
  • Not admissible: JTC1 directives forbid the issuance of this comment to ISO.
  • Established: A claim has been established by the claimant, and the proof has been accepted in the meeting.
  • Rejected: A claim has been rejected in the meeting.
  • Accepted: A comment has been accepted.
  • Acknowledged: A comment has been accepted that a comment has some truth, though the comment was not formally accepted as a whole and as worded.
  • Withdrawn: The submitter withdraw the comment.
   
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

   

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


Top