Thêm các báo cáo từ cuộc họp quyết định có biểu quyết BRM

Theo: http://www.noooxml.org/forum/t-44713/more-reports-f-rom-the-brm

Bài được đưa lên Internet ngày: 05/03/2008

Một thành viên nhóm P nói rằng quá trình này đã thất bại, một chuyên gia trung lập về tiêu chuẩn và ngạc nhiên về việc đại biểu của BRM lăng mạ uỷ ban quốc gia của anh ta và các đoàn đại biểu khác, các lỗi ngày tháng không được sửa, những thảo luận về thực sự những gì đã xảy ra, và đại biểu của Hy Lạp Antonis Christofides với một đóng góp sáng suốt cho tính minh bạch.

A P-member that declares the process failed, a neutral standard expert and surprise BRM delegate insults his national committee and other delegations, unresolved date bugs, discussions about what really happened, and Greek delegate Antonis Christofides with an insightful contribution to transparency.

Antonis Christofides đã chuyển một báo cáo với những điều làm sáng tỏ. Theo ý kiến của tôi thì đây là một trong những báo cáo tốt nhất từ BRM. Sau 5 ngày đàm phán bạn có thể mong chờ những bài viết có suy nghĩ chín chắn.

Tôi là 1 trong 2 đại biểu của đoàn Hy Lạp tới cuộc họp quyết định có biểu quyết BRM cho OOXML. Nhiều thứ đã được viết về cuộc họp này. Tôi sẽ không lặp lại chúng ở đây, mà sẽ chỉ làm sáng tỏ một số điều mà tôi nghĩ đã không được hiểu đúng.

Ông Christofides báo cáo ông cũng đã phác thảo một giải pháp của Hy Lạp cho vấn đề về ngày tháng (ông nghĩ nó rõ ràng hơn nhiều so với phiên bản đã được chấp thuận) nhưng:

Khi tôi thảo luận đề xuất của mình với Brian Jones [Microsoft/ECMA] sáng thứ năm, anh ta (Jones) đã chỉ ra rằng sẽ khó cho ECMA chấp nhận nó [??], vì họ không có đủ thời gian để kiểm tra điều đó có thực sự làm việc trong mọi trường hợp hay không. Bây giờ điều này là một lo lắng rất có căn cứ. Đề xuất của tôi là hơn 30 trang. Nếu nó là những suy nghĩ cẩn thận và không có lỗi, thì ECMA sẽ không có cách nào biết điều đó. Vì thế, BRM thực sự đã hạn chế thực hiện các thay đổi mà nó chỉ gãi lên bề ngoài của các vấn đề.

Hình như vấn đề ngày tháng không được giải quyết một cách tối ưu và ECMA đã có thể khai thác ưu điểm của các đề xuất/truy cập ưu tiên. Một giải pháp thay thế của cơ quan tiêu chuẩn quốc gia Hy Lạp cho một vấn đề có thể sẽ không được chấp thuận bởi BRM vì lý do mà Antonis giải thích cho chúng ta. Đây là một sự chọc giận đáng chú ý mà một nhóm tư nhân như ECMA quốc tế có một vai trò chính thức và mạnh mẽ trong BRM của ISO (mà không có báo chí, không có các quan sát viên, không có truyền hình trực tiếp, mọi người tham gia trong im lặng) và cố gắng kéo dây. Tôi tin tưởng những đổi mới của ISO trong tương lai sẽ lấy sức mạnh từ ECMA trở lại cho các cơ quan tiêu chuẩn quốc gia – những người tham gia hợp pháp mà họ có thể đưa ra những quyết định tại BRM.

Antonis Christofides posted a report with clarifications. In my opinion it is one of the best reports f-rom the BRM. After a five days negotiation round you would not expect thoughtful writings.

I have been one of the two Greek delegates to the OOXML Ballot Resolution Meeting (BRM). Lots of things have already been written about the meeting. I will not repeat them here, but will only make a few clarifications on things that I think are not well understood.

Mr. Christofides reports he also drafted a Greek solution for the date problem (he thinks its much cleaner than the adopted version) but:

When I discussed my proposal with Brian Jones [Microsoft/ECMA] on Thursday morning, he pointed out that it would be difficult for Ecma to accept it[??], because they did not have the time to verify that it actually works in all cases. Now this was a very valid concern. My proposal was more than 30 pages. Even if it were well thought and error free, Ecma had no way of knowing that. Therefore, the BRM was essentially confined to making changes that only scratched the surface of the problems.

Apparently the date problem could not be optimally resolved and ECMA was able to exploit its advantage of privileged access/proposal. A Greek national body al-ternative resolutions for a problem could not be adopted by the BRM for the reason Antonis explains us. It is a remarkable irritation that a private party as ECMA International got an official and powerful role in the ISO BRM (but no press, no observers, no live broadcasting, participants silenced) and attempted to pull the strings. I am confident future ISO reforms will take the power f-rom ECMA back to the NB - the legitimated stakeholder that are supposed to take the decisions at the BRM.

BRM participant Rob Weir (IBM) discusses the changes applied and supports an old suggestion of this campaign:

Một đại biểu là Rob Weir (IBM) tham gia BRM thảo luận những thay đổi được áp dụng và hỗ trợ một đề xuất cũ về chiến dịch này như sau:

Liệu OOXML có nói cho bạn biết làm thế nào để dịch một tài liệu nhị phân sang OOXML hay không? Không. Liệu nó có nói cho bạn làm thế nào để ánh xạ các tính năng của các tài liệu cũ sang OOXML không? Không. Liệu nó có đưa ra hướng dẫn bất kỳ nào về việc làm thế nào “miêu tả một cách trung thực” các tài liệu cũ không? Không. Vì thế cả 2 điều kỳ cục và không thoả mãn mà mục tiêu ban đầu của tiêu chuẩn OOXML được hỗ trợ một cách rất mong manh bởi văn bản của nó. ... Microsoft phải xuất bản một cách đơn giản việc ánh xạ này. Không có một ánh xạ như vậy, việc chuyển đổi sẽ không ổn định, tính tương hợp sẽ bị tổn hại và mục tiêu ban đầu của tiêu chuẩn này sẽ không được đáp ứng.

Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to "represent faithfully" legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text. …Microsoft should simply publish this mapping. Without such a mapping, conversions will be inconsistent, interoperability will suffer and a primary goal of the standard will not be met.

Một người theo dõi kinh điển của tranh luận này: Groklaw tiến hành một phỏng vấn với Andy Updegrove, người quản lý Blog Consortium Info. Mặc dù ông không phải là người tham gia của BRM nhưng ông trích dẫn (từ nhiều nguồn tin). Updegrove là một trong những người đầu tiên đã đưa ra một vài sự thấu hiểu kết quả của BRM mà chúng đã được tranh luận bởi người điều khiển và những người khác.

Consortium Info: Trình bày tại Geneva: Hầu hết những sắp xếp của OOXML thất bại trong việc đạt được sự chấp thuận của đa số tại BRM. (Xem đường dẫn bên dưới).

Chúng tôi thấy một tranh luận rất mãnh liệt trong phần các bìnhh luận của ông và ông cập nhật báo cáo của mình một cách tương xứng.

Người đóng góp “guồng nước” nhắm vào Brian Jones, người là một phần của đội ECMA tại BRM.

Ủng hộ Brian Jones, BRM đã đạt được sự tiến bộ to lớn. Một khi ban biên tập đứng bên ngoài thì BRM đã làm việc được với 20 trong số gần 900 vấn đề tuần này. Dường như có suy nghĩ thứ duy nhất đi đúng đường đối với một đặc tả kỹ thuật chất lượng là một chút thời gian nữa để làm việc với những vấn đề còn lại. Sự tính toán đằng sau phong bì thư nói với tôi rằng cần thêm 45 tuần nữa để thực hiện được nó theo quá trình nhanh.

Another classic follower of the debate: Groklaw conducts an interview with Andy Updegrove who runs the Consortium Info Blog. Although he was no participant of the BRM he is quoted by many. Mr. Updegrove was one of the first who gave some BRM result insights that were disputed by the convenor and others.

Consortium Info: Showdown in Geneva: Most OOXML Dispositions Fail to Achieve Majority Approval at BRM

We find a very heavy debate in his comments section and he up-dates his report accordingly.

Contributor "overshot" shots at Brian Jones who was part of the ECMA team at the BRM.

Seconding Brian Jones, the BRM made great progress. Once the editorial stuff was out of the way the BRM worked through 20 of approximately 900 issues this week. It seems as though the only thing standing in the way of a quality specification is a bit more time to work out the remaining issues. A back-of-the-envelope calculation tells me that another 45 weeks should do it for the fast-track process.

Steve Ballmer hình như đã nói trong bài trình bày của mình tại Cebit 2008 về OOXML – khi một tham chiếu không là một phần của tuyên bố được xuất bản, nó có thể hơn là một câu trả lời cho một câu hỏi của phóng viên:

Ballmer cũng biểu dương định dạng tệp OOXML của hãng, hiện đang được xem xét để trở thành một tiêu chuẩn quốc tế bởi Tổ chức Tiêu chuẩn Quốc tế ISO, như một ví dụ khác về việc hãng đã mở như thế nào.

Rick Jelliffe, một chuyên gia “độc lập” được gửi tới bởi Cơ quan tiêu chuẩn Úc đã xoá bỏ bài viết trên blog của mình. Sự giảng giải gây tranh cãi của ông ta về việc vì sao BRM chỉ có thể để mắt tới một phần nhỏ của đặc tả kỹ thuật: những đại biểu khác của BRM là chậm chạp và không có trình độ.

Thông thường thì hầu hết các đại biểu dạng này là không đạt được tốc độ về mọi thứ (vì bạn muốn những chuyên gia hiểu sâu về những thứ này, hơn là những người chung chung), không điển hình là số lớn các đại biểu phi kỹ thuật và chỉ số ít đại biểu dường như ngạc nhiên drawngf phái đoàn của họ phải chỉ ra quan điểm đối với từng vấn đề vào cuối tuần (nó có thể là “bỏ phiếu trắng – chúng tôi không có quan điểm gì”). Đây không phải là dường như họ không được nói cho!

và ông tiếp tục giải thích vì sao các chính phủ (!?) tham gia là có lợi cho tiêu chuẩn này. Đề xuất của ông ta là chấp thuận tiêu chuẩn này hoặc Microsoft có thể bỏ đi và không để lại vai trò nào cho các chính phủ đối với vai trò duy trì.

Steve Ballmer apparently talked in his Cebit 2008 presentation about OOXML - as the reference is not part of the published speech, it was most likely an answer to a journalist question:

Ballmer also cited the company's Office Open XML (OOXML) file format, now under consideration to become an international standard by the International Organization for Standardization, as another example of how the company has opened up.

Rick Jelliffe, the "independent" expert sent by Standards Australia removed his blog post. His controversial teaching why the BRM was only able to cast an eye on a small part of the specification: the other BRM delegates were slow and incompetent.

It is typical that most delegates at these kind of thing are not up to speed on everything (because you want deep experts at these things, more than generalists), what is atypical is the large number of non-technical delegates and that a few delegates seemed surprised that their delegations would have to figure out a position on each issue by the end of the week (which could be “abstain - we have no position”.) It is not as if they hadn’t been told!

and he continues to explain why getting governments(!?) involved is beneficial to the standard. His subtile suggestion is to approve the standard or Microsoft could walk away and leave no role to governments for a maintenance role.

Có rất nhiều những người, và họ sẽ phải duy trì, mà đó thực sự là một vấn đề lớn: liệu Microsoft sẽ tiếp tục các bước chập chững này tới tính mở hay họ sẽ làm ướt sũng một khi đứng ngoài sân khấu, mà nó là chưa từng thấy đối với những người đóng góp cho các tiêu chuẩn khác? Cả sau biểu quyết cuối cùng (giả sử một phiếu chấp thuận, có lẽ như vậy) các chính phủ sẽ cần giữ áp lực lên ECMA để tiếp tục làm việc với SC34 và để những vấn đề nổi tiếng này được giải quyết một cách nhanh nhất có thể; đây không phải là trường hợp mà các vấn đề không được giải quyết cần biến mất trong lỗ đen, mà sức mạnh của SC34 chỉ tới từ việc có các chính phủ và người sử dụng mạnh ủng hộ để đưa ra sự duy trì này những thứ nó cần: điều này không chỉ có nghĩa việc con quái vật MS sẽ tiếp tục thông qua sự duy trì, mà còn cung cấp những tài nguyên đầy đủ: chỗ dựa, các đại biểu, và hỗ trợ dài hạn cho sự tham gia tại các cuộc họp về tiêu chuẩn. Chính phủ cần được hỏi “Hỗ trợ gì chúng ta đang đưa ra cho việc phát triển và khuyến khích các chuyên gia kỹ thuật của chúng ta?” hay là họ đang nói thông qua những chiếc mũ của họ về tiêu chuẩn. Sẽ không có những thứ như vậy như một chuyên gia thực sự.

There are a lot of those, and they will have to go to maintenance, which really is the big issue: will MS continue these baby steps to openness or will they go soggy once out of the spotlight, which is not unprecedented by other standards stakeholder? Even after the final vote (assuming an acceptance vote, as seems likely) governments will need to keep the pressure on Ecma to continue working with SC34 and to get these outstanding issues addressed ASAP; it is not the case that unaddressed issues need to disappear down a black hole, but SC34’s only power comes f-rom having strong government and user backing to give this maintenance the steroids it needs: this not only means monstering MS to continue through maintenance, but also to provide adequate resources: staffing, delegates, and long-term support for participation at standards meetings. The government needs to be asking “What support are we giving to developing and encouraging our technical experts?” otherwise they are talking through their hats about standards. There is no such thing as an instant expert.

Hãy để tôi đoán rằng Rick Jelliffe tìm thấy lời kêu gọi của mình đối với sự trợ giúp của nhà nước là không phù hợp và đã xoá bỏ bài viết trên blog của mình vì lý do này. Hoặc vì ông ta đã tấn công các thành viên của uỷ ban quốc gia của ông ta (ông ta dường như là đại diện như một đại biểu quốc gia) và các đồng nghiệp quốc tế bạn ông.

Điều đó không nói rằng văn bản cuối cùng sẽ được chấp thuận đối với cơ quan tiêu chuẩn quốc gia Úc của chúng tôi: có những người mà đối với họ không có số lượng nào cải tiến trong văn bản sẽ làm cho OOXML trở thành một đối tượng có thể chấp nhận được cho một tiêu chuẩn ISO, sẽ có rất nhiều thay đổi mà kết quả cần một thứ nhìn được. Và có những người lo lắng rằng lời hứa về đặc tả kỹ thuật mở OSP (Open Specification Promise) của Microsoft là không ổn (sở hữu trí tuệ IP (intellectual property) không phải là một vấn đề để tranh luận tại BRM). Và một lần nữ đây không nói rằng ngay cả khi một vấn đề được giải quyết, thì chúng ta có quan điểm ưu tiên hơn hoặc những thay đổi đó sẽ hoàn toàn được chấp thuận trong từng trường hợp: những quốc gia gây phiền phức khác đi trên con đường đó.

Các quốc gia “gây phiền phức”? Tôi không biết liệu Malaysia có là một trong số họ không nhưng chúng tôi có một thông cáo báo chí từ cơ quan tiêu chuẩn quốc gia Malaysia về kết quả của BRM.

“Malaysia đã quyết định biểu quyết 'Không tán thành' đối với các vấn đề không được giải quyết này”, Fadilah nói, “Sự hạn chế của quá trình của BRM rõ ràng đã chỉ ra rằng một nhiệm vụ như việc chấp thuận tiêu chuẩn phác thảo này không phù hợp trong quá trình nhanh được sử dụng bởi ECMA quốc tế. Malaysia và các đoàn đại biểu các quốc gia khác đã làm việc rất cật lực và mở rộng thêm cả các buổi tối sau các phiên họp của BRM. Tất cả các chuyên gia kỹ thuật từ những nền tảng cơ bản khác nhau, bao gồm cả từ Microsoft, người đề xuất ban đầu bởi nhiều cơ quan tiêu chuẩn quốc gia đã thảo luận trong thời gian diễn ra BRM. Đáng tiếc là có quá nhiều thứ cần sửa trong thời gian đó”.

Sức ép về thời gian là sự lo lắng cho Malaysia:

“Malaysia đã đệ trình 23 bình luận và hơn 70% trong số đó đã không được giải quyết một cách thoả mãn bởi những sắp xếp được đệ trình của ECMA. Chúng tôi dự kiến giải quyết các vấn đề kỹ thuật này tại BRM, nhưng chúng tôi chỉ có thể đưa ra 2 vấn đề quan tâm vì sức ép về thời gian”, Fadilah nói.

Let me suggest that Rick Jelliffe found his call for state aid inappropriate and removed his blog post for this reason. Or was it because he attacked members of his national committee (he was supposed to represent as a national delegate) and his fellow international colleagues:

That is not to say that the final text will be acceptable to our National Body, Standards Australia: there are people for whom no amount of improvement in the text will make OOXML an acceptable subject for an ISO standard, there have been so many changes the result needs a good looking over. And there are people who are concerned the MS OSP is unsound (IP was not an issue for the BRM to discuss.) And again it is not to say that even when an issue was addressed, we got our preferred position or that the changes will be completely acceptable in every case: other pesky nations got in the way.

"Pesky" nations? I don't know if Malaysia was one of them but we have a press release f-rom the Malaysian national body on the BRM outsome.

"Malaysia decided to vote 'Disapprove' to these undiscussed issues," Fadilah elaborated, "The limitation of the BRM process clearly showed that such a task of approving this draft standard does not fit in the Fast Track process employed by Ecma International. Malaysia and other country delegations worked very hard which extended into evenings after the BRM sessions. All the technical experts f-rom diverse backgrounds, including f-rom Microsoft, the original proposer of the Draft, put their heads together to fix the specification. Malaysia approved the counter proposals by many National Bodies which were discussed during the BRM. Unfortunately there were just far too many to fix within the given time."

Time contraints were a concern for Malaysia:

"Malaysia had submitted 23 comments and more than 70% of them were not addressed satisfactorily by Ecma's proposed dispositions. We intended to resolve these technical issues at the BRM, but we could only raise 2 concerns due to the time constraints imposed," Fadilah said.

Các báo cáo khác từ BRM

2 vấn đề ngay lập tức rõ ràng từ nhiều bình luật sau BRM: a) tiêu chuẩn được đệ trình DIS 29500 hiện gần sẵn sàng để trở thành một tiêu chuẩn tài liệu quốc tế và b) các quá trình của ISO và BRM, trong khi đưa vào các tiêu chuẩn mở, còn phải làm việc với một số vấn đề quản lý nghiêm túc.

Microsoft cuối cùng thực sự phải đi tới điều kiện với thực tế rằng họ sẽ cần đặt vào rất nhiều nỗ lực hơn nữa trong đặc tả kỹ thuật OOXML của họ trước khi nó trở thành một tiêu chuẩn hữu ích và có thể triển khai được (hãy nhớ rằng bản thân họ còn chưa triển khai nó trong các sản phẩmm Office của chính họ) và thực tế là có quá nhiều thì giờ của mọi người phải bỏ ra đối với tiêu chuẩn này đang bắt đầu mài mòn một cách rõ ràng với nhiều người.

Re: More reports f-rom the BRM

Two things are immediately clear f-rom much of the post-BRM commentary; a) the proposed DIS29500 standard is nowhe-re near ready to become an international document standard and b) the ISO and BRM processes, while integral to open standards, have to deal with some serious governance issues.

Microsoft is going to have to eventually come to terms with the fact that they will need to put a lot more effort into their OOXML specification before it becomes a useful and implementable standard (remember they haven't even implemented it themselves in their own Office products) and the fact that so many man hours are being wasted on this standard is obviously starting to grind with many.

Cuối cùng, Rick Jelliffe cũng cần nghĩ lại quan điểm của mình về sự thất bại tiếp tục của OOXML và sự thực rằng trong dạng hiện hành của nó thì nó sẽ không bao giờ có thể sửa lỗi được trừ phi nó được kiểm tra lại một cách kỹ lưỡng bởi bản thân Microsoft. Đáng tiếc, Jelliffe thấy bản thân từ đầu tới cuối tất cả là XML, nên việc tin tưởng rằng bất kỳ ai mà không chia sẻ quan điểm của ông ta là không gắn với đặc tả kỹ thuật được đệ trình và vì thế bất kỳ vấn đề gì họ có là không có hiệu lực và phải bị bỏ qua. Bổ sung cho bình luận ngạo mạn và thường xúc phạm của ông ta và nó dễ dàng bắt nguồn từ quan điểm về OOXML của ông ta là rõ ràng nghiêng hẳn về lợi ích của Microsoft bất kể đặc tả kỹ thuật đó què quặt như thế nào bên trong.

Lastly, Rick Jelliffe also needs to rethink his position with regards to the continued failure of OOXML and the fact that in its current form it will never be fixable unless it is overhauled by Microsoft internally. Unfortunately, Jelliffe sees himself as the be-all and end-all of XML, believing that anyone that doesn't share his views is clueless about the proposed specification and therefore any issue they have is invalid and should be ignored. Add to this his arrogant and often derogatory commentary and it is easy derive his view of OOXML is clearly skewed in favour of Microsoft no matter how broken the underlying specification.

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

ltnghia@yahoo.com