US Incits ballot with optional comments. While the vote result does not surprise observers of the committee some of the comments filed might be very useful to get considered by your national committee:
The results from the BRM, as we can see in the official BRM resolutions posted by the JTC1/SC34 Secretariat, as well as Mr. Farance's HoD report, show quite clearly that although some of the US comments were addressed, several were not, including those which the EB identified as the most critical issues. In particular the request for a reference to mappings to the legacy binary Microsoft Office file formats was not satisfied, and in fact was not even discussed at the BRM, for lack of time. So an important claim, highlighted in the scope clause of DIS 29500, can not be performed consistently by any other vendor. This is unacceptable, because one of the main purposes of DIS 29500 cannot be reliably practiced, for lack of this information. Further, important concerns regarding weak legacy cryptographic algorithms were not resolved at the BRM, again for lack of time.
Even if these particular issues had been resolved at the BRM, we would still not have a high level of confidence that the proposal was technically satisfactory. The question is not how many defects were fixed at the BRM. The question is how many defects remain in the standard.
We have recently performed a sampling of the DIS 29500, post BRM, using a random number
generator to pick random pages in the text. In a random sample of only 12 pages we found 19
technical defects, including serious ones such as:
1) Storage of plain-text passwords in database connection strings
2) Undefined mappings between CSS and DrawingML
3) Errors in the XML Schema definitions
4) Dependencies on proprietary features of Microsoft Internet Explorer
None of these issues were addressed at the BRM, or even raised as NB comments during the 5-
month ballot. This give us serious reservations about the overall quality of the text, and the
sufficiency of the Fast Track review.
Oracle continues to believe that the 6000+ page specification for DIS 29500 (OOXML) is inappropriate for fast-track processing. Significant unresolved technical concerns - documented in “Unresolved Technical Concerns In DIS 29500 (OOXML)” in file http://www.incits.org/ref-docs/Oracle-Comments_INCITS2558.pdf - as well as process irregularities compell us to vote NO on the INCITS/V1 recommendation to approve DIS 29500 as modified by the BRM of February 25-29, 2008. We also have considerable anxiety about the long-term impact of this heavy-handed initiative on the formal standards process in general and the fast-track process in particular. Although we believe experience has proven that use of the Fast Track process was clearly inappropriate for DIS 29500, we would support introduction of the latest revision of the DIS 29500 specification into the normal process where the numerous outstanding technical concerns could be properly addressed.
The 29500 document is not yet ready to become an ISO standard. [..] A position of "approval" is completely unacceptable to us. Regardless of the good work that was completed at the DIS 29500 BRM, there still remain significant problems:
(1) Given the large number of changes, the wide scope of changes, and the lack of finalized text, it is impossible to determine whether or not the document is something worthy of approval as an ISO/IEC international standard. Although the JTC1 fast-track DIS process does not mandate an FDIS ballot (and we recommend that JTC1 change its Directives to include FDIS ballot for fast-track and PAS processes that involve "substantive" changes during the DIS balloting), certainly the DIS 29500 process *could* have been scheduled in such a way that accomplished this strong technical need to see the document "as a whole". With the document split in multiple parts (yet unseen), the conformance wording reorganized and rewritten (yet unseen), and the schema excerpts completely rewritten (thousands of new pages, yet unseen), it is impossible to evaluate the quality of the finalized text, regardless of the good skill and good intentions of the Project Editor, his staff, and ECMA.
(2) The scheduling and management of the BRM (before, during, and after) did not serve the purpose of producing a high quality ISO/IEC standard. When the DIS ballot on 6000+ pages of text closed on 2007-09-02 and produced approximately 3500 comments, it should have been obvious at that point that a week of BRM time was not enough. The timing on reviewing proposed dispositions was poor, too: the 1000 or ECMA responses were available about a month before the BRM, which gave all National Bodies very little time to review the proposals in detail. The BRM itself was scheduled for only one week and the managers of the BRM (the Convener and ISO/IEC staff) were unsympathetic and rigid to devoting any additional time. It is unclear why the BRM was limited to a week since other BRMs have taken longer than a week (e.g., spanning several months) and we could find no limitation in the JTC1 Directives that confines the BRM to a week. During the BRM, virtually all comments that were discussed (about 20%) also required significant changes to build international consensus. The remaining 80% of comments that were not discussed (but yet they were approved by a "default vote" ballot) are likely to have a similar fate: approximately 800 changes to be applied to the text for which many of them will have some defect that *could* have been fixed in the BRM process had the BRM process placed Quality has a high priority. Thus, given the lack of finalized text and the low confidence level on the 800 applied (but not discussed) changes to the text, we expect there to be a significant number of defects in the published text of the ISO/IEC standard.
(3) It does not serve US industry, US interests, or any other national interests to approve and publish an international standard with such significant questions about its quality and a complete lack of finalized text. We are very concerned that such Defect Reports and Requests For Interpretation will completely swamp the ISO/IEC JTC1 SC34 participants and the national participants over the next 2 years with a substantial amount of administrative work and (unfortunately) diminishing the perception of the 29500 standard itself and, possibly, decreasing the adoption of the standard itself. As easily demonstrated by several other problematic standards (e.g., the ISO/IEC C++ standard), industry adoption is *not* guaranteed and quality issues have a great (negative) effect upon the adoption of an ISO/IEC standard. Although we disapprove of the DIS 29500 at its present state, Farance Inc. is supportive of the 29500 technologies becoming an ISO/IEC standard. We want the work done right and done quickly to address industry and international needs. Farance Inc. has proposed in INCITS/V1 two New Work Item Proposals for SC34: one NP if DIS 29500 succeeds and a different NP if DIS 29500 fails. These NP proposals were acknowledged in the INCITS EB ballot wording. We hope these NPs will be a starting point to trying to fix/finish issues within the 29500 text, and we hope these immediate needs can be addressed over the next 9-14 months.
Adobe has no opposition to the standardization of OOXML, but we are concerned that using the JTC1 fast track process for a 6000 page document has not lead to adequate consideration of the comments on that document nor does it seem to be producing a quality standard.
