Về sự hoài nghi, chứng cứ cuối cùng: OpenXML đã không (và đang không) sẵn sàng

Thứ sáu - 17/04/2009 06:53
For the skeptical, the final proof: The OpenXML wasn't (and isn't) ready

April 8th, 2009

Theo: http://homembit.com/2009/04/for-the-skeptical-the-final-proof-the-openxml-was...

Bài được đưa lên Internet ngày: 08/04/2009

Lời người dịch: Bạn hãy xem những gì đang xảy ra với cái gọi là chuẩn OOXML nhé: “có vẻ buồn cười, nhưng cho tới hôm nay vẫn có những đám người đang tìm các lỗi...”, sau gần 1 năm ISO/IEC phê chuẩn OOXML là một tiêu chuẩn để có thể đưa ra văn bản chính thức các đặc tả kỹ thuật của nó. Có vẻ như OOXML được đặc cách theo kiểu: Có 6000 trang giấy, ta cứ phê chuẩn đi đã, sau đó tìm lỗi sau. Ai thích dùng cái thứ chuẩn này nhỉ???

Trong những ngày gần đây nhận được một số tài liệu từ JTC1/SC34 báo cáo về sự tiến triển trong nhóm làm việc mà đang cố gắng sửa OpenXML (OOXML), và thật ấn tượng và kỳ dị những gì một người có thể thấy trong những tài liệu này.

Ví dụ, tài liệu N1101/N1168, chứa vài điều khoản trong đó họ nhận thức rằng có những quyết định được thực hiện trong cuộc họp quyết định có biểu quyết (BRM) mà đã không được kết hợp vào trong văn bản cuối cùng được xuất bản của tiêu chuẩn này. Nói một cách khác, ngay cả việc mất hầu như 1 năm sau khi phê chuẩn tiêu chuẩn này để xuất bản văn bản này (vâng, đã phê chuẩn mà không đọc), đã không có thời gian/sự chú ý hoặc bất kỳ thứ gì cần thiết khác để đảm bảo rằng những thay đổi đã được xuất ban4r trong văn bản này (hầu hết những thay đổi đó, chấp thuận “có điều kiện”). Những gì làm cho tôi tức giận hơn nhiều về điều này là việc trong BRM tôi đã hỏi về việc ai sẽ có trách nhiệm cho việc kiểm tra lại tất cả những thay đổi này có thể sẽ là một phần của văn bản cuối cùng và câu trả lời là ITIF (dạng của ban thư ký hỗn hợp của ISO/IEC). Khi tôi đã hỏi liệu ITTF có thực sự làm công việc này không, thì tôi đã nhận được câu trả lời đáng kinh hãi: “Anh còn nghi ngờ ITTF ư, ông bạn trẻ?”...

Tệ hơn thế, thông tin bên trong tài liệu này là đủ cho tôi nghi ngờ rằng việc sửa lỗi đã được phê chuẩn/đã được khuyến cáo ở những nơi mà còn đã được triển khai nữa. Nếu trước khi tài liệu này mà tôi đã nghi ngờ rằng phiên bản cuối cùng của đặc tả kỹ thuật đã không là những gì mọi người nghĩ, thì bây giờ tôi khá chắc chắn về nó và tôi nghĩ rằng chúng ta đã không tìm ra được ngay cả những vấn đề rất xấu ở đó vì hầu hết mọi người, giống như tôi, đã từ chối xem của khỉ 6000 trang này một lần nữa.

Trong tài liệu N1171, một người trong nhóm làm việc của SC34 tuyên bố rằng họ đã thấy những vấn đề trong đặc tả kỹ thuật về phông của OOXML và sẽ đệ trình một báo cáo lỗi về nó cho nhóm chịu trách nhiệm về việc sửa chữa tiêu chuẩn này (có vẻ buồn cười, nhưng cho tới hôm nay vẫn có những đám người đang tìm các lỗi...).

Received in recent days several documents f-rom JTC1/SC34 reporting the progress at the working group that is trying to fix the OpenXML, and it’s impressive and surreal what one may find in those documents.

The document N1101/N1168 contains for example, several items in which they recognize that there are decisions made in the BRM (BRM resolutions) which were not incorporated into the final published text of the standard. In other words, even taking almost a year after the aproval of the standard to publish the text (yes, approved without reading), there wasn’t time/attention or anything else necessary to assure that the changes were published in the text (most of those changes, “conditioned” the approval). What makes me much more angry about this is that during the BRM I asked about who would be responsible for verifying that all these changes would be part of the final text and the answer was ITTF (kind of joint ISO/IEC secretariat). When I asked if the ITTF would really make this work, I received as a reply the intimidating: “You are doubting the ITTF, kid ?”…

Worse than this, the informations inside this document are sufficient for me to doubt that the approved/recommended corrections whe-re even implemented. If before this document I suspected that the final version of the specification wasn’t what everybody thought, now I’m pretty sure about it and I think that we didn’t find even more severe problems there because most people, like me, refuses to look at those damn 6000 pages again.

On the document N1171, one of the working groups of SC34 announces that they’ve found problems in the OpenXML fonts specification and will submit an error report about it to the group responsible for repairing the standard (looks funny, but until today there are folks finding defects … ).

Tài liệu N1183 biện hộ sự phân nhánh của những phần hiện đã có sẵn của tiêu chuẩn này để nói rằng để sửa cho đúng một vài lỗi được chỉ ra, những tính năng “nhỏ không đáng kể” mới cần phải được bổ sung vào đặc tả kỹ thuật (và điều đó thực sự là hay ho, vì bây giờ ISO đã phê chuẩn tiêu chuẩn này rồi, họ có thể viết bất kỳ thứ gì họ muốn, phải không?).

Tôi đã giữ lại thứ tốt nhất vào cuối cùng: tài liệu N1187. Một người nói rằng OOXML “như nó” chứa những lỗi không chủ tâm mà chúng có thể ngăn ngừa được những tài liệu hiện hành được trình bày một cách đầy đủ trong định dạng mới này.

Thật ngạc nhiên vì sự ủng hộ được thừa hưởng từ trước đã được cho như là lý do chính cho sự phát triển và phê chuẩn OOXML tại ISO, và cũng là lý do vì sao một vài quốc gia đã ủng hộ sự phát triển và phê chuẩn của tiêu chuẩn này. Trong tài liệu này, họ cũng giải thích những chỉ tiêu mà sẽ được sử dụng để chỉ định những thay đổi mà chúng sẽ được phát triển, sao cho họ có thể làm nó tất cả thực sự nhanh chóng (nói một cách khác họ đi qua những lỗ thủng của những chỉ thị của JTC1 để những thay đổi này được kết hợp vào trong tiêu chuẩn đã được phê chuẩn mà không phải làm gì ồn ào nhiều về nó).

Không may tôi không có thể đặt tất cả những tài liệu này ở đây, để cho phép truy cập thông qua blog, vì các tài liệu của SC34 phải bị hạn chế (vâng, sự minh bạch là bằng 0), mà tôi tin tưởng rằng dù sớm hay muộn chúng sẽ được xuất bản ở đâu đó (và tất nhiên, các cơ quan tiêu chuẩn quốc gia thành viên đã phải nhận được chúng).

Vì tôi là một người trẻ tuổi nên tôi đã học được không được ký vào những tờ giấy để trắng, nhưng tôi nghĩ rằng điều này không phải là một bài học có giá trị tại các quốc gia khác.

Tôi muốn thấy được trả lời một vài câu hỏi cơ bản sau:

Brazil, Nam Phi, Ấn Độ và Venezuela đã đúng hay không khi đã kháng án (và có đúng là những kháng án của họ bị ISO phớt lờ hay không?)

Các ngài trong ban lãnh đạo ISO, mà đã phớt lờ các kháng án này, làm y như vậy sẽ tiếp tục công việc phát triển và các tài liệu được bình luận ở đây chăng?

Ai là người chịu trách nhiệm về tất cả những thứ này, và ông ta sẽ trả thế nào?

The document N1183 justifies the subdivision of the already existing parts of the standard to saying that to correct some errors pointed out, new “minor” features need to be added to the specification (and that is really cool, because now that the ISO has already approved the standard, they can write whatever they want , isn’t it?).

I saved the best for the end: document N1187. This one says that OpenXML “as is” contains unintentional errors that may prevent existing documents to be fully represented in this new format. It is amazing because the legacy support was alleged as the main reason for OpenXML development and approval at ISO, and also the reason why several countries supported the development and approval of the standard. In this document, they also explain the criteria that will be used to specify the changes that will be developed, so that they can do it all really quickly (in other words, they go trough the breaches of the JTC1 directives to get these changes incorporated into standard already approved without making much noise about it).

Unfortunately I can not put all these documents here, to allow access trough the blog, because they should be restricted SC34 documents (yep, zero transparency), but I believe that sooner or later they will be published somewhe-re (and of course, NB members should already received those).

Since I was a young boy I’ve learned to not sign blank papers, but I think that this isn’t a valuable lesson in other countries.

I would like to see answered some basic questions:

Brazil, South Africa, India and Venezuela were right or not when appealed (and had their appeals ignored by the ISO)?

Do the same gentleman at the ISO board, that ignored the appeals, are following the development work and documents commented here?

Who is responsible for all this, and how he will pay?

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Tổng số điểm của bài viết là: 0 trong 0 đánh giá

Click để đánh giá bài viết

  Ý kiến bạn đọc

Những tin mới hơn

Những tin cũ hơn

Về Blog này

Blog này được chuyển đổi từ http://blog.yahoo.com/letrungnghia trên Yahoo Blog sang sử dụng NukeViet sau khi Yahoo Blog đóng cửa tại Việt Nam ngày 17/01/2013.Kể từ ngày 07/02/2013, thông tin trên Blog được cập nhật tiếp tục trở lại với sự hỗ trợ kỹ thuật và đặt chỗ hosting của nhóm phát triển...

Bài đọc nhiều nhất trong năm
Thăm dò ý kiến

Bạn quan tâm gì nhất ở mã nguồn mở?

Thống kê truy cập
  • Đang truy cập0
  • Hôm nay35,663
  • Tháng hiện tại562,196
  • Tổng lượt truy cập32,040,522
Bạn đã không sử dụng Site, Bấm vào đây để duy trì trạng thái đăng nhập. Thời gian chờ: 60 giây