Theo: http://www.robweir.com/blog/2008/03/five-bad-reasons-to-approve-ooxml.html
Bài được đưa lên Internet ngày: 24/03/2008
Nếu bạn không chấp thuận OOXML, Microsoft sẽ từ bỏ, và bạn sẽ không bao giờ nghe thấy từ họ một lần nữa. Hãy quên đi sự thực rằng OOXML đã là một tiêu chuẩn ECMA (ECMA-376), và không thể bị bỏ đi. Hãy quên đi sự thực rằng Microsoft có những định dạng khác xếp hàng chờ ISO chấp thuận trong tương lai gần, như XPS hoặc HD Photo. Microsoft muốn bạn nghĩ rằng nếu bạn không cho họ chính xác những gì họ muốn, bây giờ, thì họ sẽ rời bỏ ISO và bạn sẽ thấy tồi tệ hơn vì việc đó. Chúng ta cần khuyến khích Microsoft vì sự lạm dụng của họ về quá trình tiêu chuẩn hoá, với hy vọng rằng sự tham gia của họ sẽ giải quyết được theo thời gian với những hy vọng của chúng ta, và không phải sự sợ hãi của chúng ta, mà họ sẽ cải thiện ở phía tiêu chuẩn hoá, trong khi buộc giây điều khiển phía lạm dụng đó. Tất nhiên, sự khuyến khích này có thể bị hiểu nhầm sang nghĩa ngược lại, và chúng ta có thể có nhiều sự lạm dụng hơn nữa, và ngay cả cá tiêu chuẩn chất lượng thấp hơn nữa. Tôi đồ rằng rủi ro đó chúng ta sẽ phải hứng chịu. Với sự lạm dụng tương tự về logic thì đứa trẻ con giữ được hơi thở của chúng cho tới khi mặt chúng tái xanh, khi nghĩ chúng có thể làm người lớn kinh sợ mà đưa cho chúng những gì chúng muốn. Nó sẽ không làm việc như vậy ở đây.
Nếu bạn chấp thuận OOXML, bạn có thể có ưu tiên bỏ ra 5 năm làm việc cật lực tiếp sau để sửa hàng ngàn khiếm khuyết trong văn bản này. Bạn có thể có được một cái ghế cạnh cái bàn, sửa các lỗi mà chúng phải được sửa tại ECMA trước khi OOXML được đệ trình tới JTC1. Hãy quên đi thực tế rằng sự duy trì tại JTC1 là một hoạt động chán ngắt và tốn nhiều thời gian, nơi mà những khiếm khuyết riêng rẽ được đánh số, những thay đổi được đề xuất, được thảo luận, được biểu quyết .v.v. Hãy quên đi thực tế rằng cuộc họp quyết định có biểu quyết BRM gần đây đã chỉ ra rằng bạn không thể thực sự có được hơn 60 khiếm khuyết trong một cuộc họp dài 1 tuần. Hãy quên đi sự thực rằng việc sửa các lỗi khiếm khuyết tại ECMA, chứ không phải JTC1, có thể còn lâu mới nhanh hơn và dễ dàng hơn nhờ vào quá trình nhẹ cân mà ECMA ép buộc lên các tiểu ban kỹ thuật TC. Hãy quên đi quá trình nhanh (Fast Track) được dự kiến cho các tiêu chuẩn được chấp thuận và chín muồi chứ không phải cho những tiêu chuẩn mà chúng đòi hỏi một “cuộc họp quyết định có biểu quyết BRM chung thân suốt đời”. Hãy quên đi tất cả những thứ đó. Bạn muốn một chiếc ghế sau chiếc bàn để sửa lỗi chứ? Bạn sẽ có được nó đấy.
Hàng tỷ và hàng tỷ các tài liệu cũ. Vâng, thực sự đó là các tài liệu cũ này không ở định dạng OOXML; chúng ở định dạng nhị phân cũ kỹ. Và không có việc ánh xạ nào được cung cấp từ các định dạng cũ này sang OOXML. Nhưng sẽ có hàng tỷ và hàng tỷ các tài liệu cũ như thế. Đó phải là rất quan trọng. Vì thế hãy biểu quyết CÓ cho OOXML vì sẽ có hàng tỷ và hàng tỷ các tài liệu ở một vài định dạng khác mà nó sẽ có liên quan một cách mờ ám tới nó.
Càng nhiều tiêu chuẩn càng tốt. Nhiều tiêu chuẩn hơn có nghĩa là nhiều lựa chọn hơn, có nghĩa là nhiều tư vấn hơn, có nghĩa là nhiều tiền hơn phải trả cho các chuyên gia XML. Bạn sẽ sớm thấy Uỷ ban Sữa Mỹ khuyến cáo tiêu thụ ít sữa hơn một chuyên gia chuyên nghiệp về tiêu chuẩn kêu gọi ít các tiêu chuẩn hơn. Vì thế hãy quên đi chất lượng, độ chín muồi và nhu cầu. Nhiều tiêu chuẩn hơn là một thứ tốt. Giống như Blue-ray và HD DVD.
ODF sẽ tốt hơn nếu OOXML được chấp thuận. Trong OASIS chúng tôi quá ngu không thể thấy các tính năng cũ hoặc các công thức bảng tính của Excel trong ECMA 376. Chúng tôi có thể sẽ không bao giờ nghĩ về điều đó. Chúng tôi tin tưởng chỉ có cách làm cho ODF tốt hơn là làm cho có nhiều thứ giống OOXML hơn. Đó là vì sao chúng tôi muốn khuyến khích các quốc gia có JTC1 bé tẹo như Kazakhstan biểu quyết CÓ cho OOXML. Ngay khi OOXML được chấp thuận, thì thật ma thuật, nó sẽ trở nên hữu dụng cho chúng ta. Nhưng chính xác văn bản y hệt, sẽ không được chấp thuận bởi Kazakhstan và JTC1, sẽ không hữu dụng cho tất cả chúng ta. Đó là tất cả hoặc không có gì. Không có gì đứng trung gian được cả. Thay vì lấy văn bản chất lượng cao, hữu dụng, và cải tiến các giá trị của nó, chúng ta lại được yêu cầu chấp thuận một đặc tả kỹ thuật với hàng ngàn khiếm khuyết, và bằng việc chấp thuận của chúng ta, chúng ta sẽ chuyển nó vào thứ gì đó hữu ích cho ODF.
If you don't approve OOXML, Microsoft will walk away, and you'll never hear f-rom them again. Forget the fact that OOXML is already an Ecma standard (Ecma-376), and cannot be taken away. Forget the fact that Microsoft has other formats lined up for ISO approval in the near future, like XPS or HD Photo. Microsoft wants you to think that if you don't give them exactly what they want, now, they will walk away f-rom ISO and you will be the worse f-rom it. We need to encourage Microsoft for their abuse of the standardization process, in hopes that their participation will evolve in line with our hopes, and not our fears, that they will improve on the standardization side, while curbing the abuse side. Of course, the encouragement could be misinterpreted to mean the opposite, and we could get more abuse, and even lower quality standards. I guess that's the risk we'll just need to take. By similar abuses of logic small children hold their breath until their faces turn blue, thinking they can scare adults into giving them what they want. It doesn't work there either.
If you approve OOXML, you can have the privilege of spending the next 5 years in the glorious work of fixing thousands of defects in the text. You can get a seat at the table, fixing bugs that should have been fixed in Ecma before OOXML was even submitted to JTC1. Forget the fact that maintenance in JTC1 is a ponderous, time consuming activity, whe-re individual defects are enumerated, changes proposed, discussed, voted on, etc. Forget the fact that the recent BRM showed that you can't really get through more than 60 defects in a week-long meeting. Forget the fact that fixing defects in Ecma, not JTC1, would be far faster and easier due to the lighter-weight process Ecma imposes on their TC's. Forget that Fast Track is intended for mature, adopted standards not for ones that will require a "Perpetual BRM". Forget all that. You want a seat at the bug fixing table? You got it.
Billions and Billions of legacy documents. Well, actually these legacy documents are not in OOXML format; they are in the legacy binary format. And no mapping has been provided f-rom the legacy formats to OOXML. But there are billions and billions of these legacy documents. That must be important. So vote Yes for OOXML because there are billions and billions of documents in some other format that is nebulously related to it.
More standards are better. More standards means more choice, means more decisions, means more consultants, means more money paid to XML experts. You'll sooner find the American Dairy Council recommending less milk consumption than a standards professional calling for fewer standards. So ignore quality, maturity and need. More standards are a good thing. Like Blue-ray and HD DVD.
ODF will be better if OOXML is approved. In OASIS we're too stupid to look up legacy features or Excel spreadsheet formulas in Ecma-376. We would have never thought of that. We believe the only way to make ODF better is to make it more like OOXML. That is why we would like to encourage nice little JTC1 countries like Kazakhstan to vote YES for OOXML. As soon as OOXML is approved, then magically, it becomes useful to us. But the exactly same text, not approved by Kazakhstan and JTC1, is not useful to us at all. It is all or nothing. There is nothing in the middle. Rather than taking a useful, high quality text, and approving it on its merits, we are asked to approve a specification with thousands of defects, and by our approval we transform it into something useful to ODF.
Dịch tài liệu: Lê Trung Nghĩa
Ý kiến bạn đọc
Những tin mới hơn
Những tin cũ hơn
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...