Lại bàn về ODF và OOXML

Triển khai so với triển khai (và vì sao đó là vấn đề của sự khác biệt)

Implementations vs. Implementations (and why the difference matters)

Theo: http://www.consortiuminfo.org/standardsblog/article.php?story=20070922150738283

Bài được đưa lên Internet ngày: 22/09/2007

Các nhà chiến thuật chiến tranh thường than phiền về sự tàn phá mà “mây mù chiến tranh” (nghĩa là không có khả năng giao tiếp một cách có hiệu quả giữa những mớ hỗn độn của chiến trường) sẽ trút giận lên các kế hoạch đã được đưa ra một cách thận trọng của họ. Đôi khi tôi có cảm giác là có vài cách về thách thức đối với việc duy trì một hội thoại xây dựng trong các tình huống của các tiêu chuẩn cạnh tranh cao. Khi mà những khoản cược thương mại bắt đầu tăng lên, rất thường thấy ham muốn lớn hơn trong trao đổi những cuộc đấu khẩu hơn là giao tiếp thực tế. Và nó cũng sẽ trở nên lôi cuốn hơn khi trở thành nội dung với những tổng quát hoá lên so với cố sức đi xuống đáy của sự việc để chỉ ra thực sự thì cái gì đang xảy ra.

Khoảng 10 ngày trước tôi đã cố thử xua tan một chút mây mù bằng việc đặt ra một số câu hỏi trên blog của Jason Matusow ở cuối của một bài viết mà anh ta đặt tên là “Những triển khai độc lập của Open XML”. Jason thực hiện công việc một cách tỉ mỉ để cố gắng trả lời tất cả các câu hỏi mà mọi người để lại trên blog của anh ta, kể cả những câu hỏi mà bạn thực sự không thể gọi là lịch sự được. Trong trường hợp này, Jason đã liệt kê ra 6 triển khai của OOXML, cung cấp các đường liên kết tới các sites của các nhà cung cấp để trả lời.

Military tacticians often bewail the havoc that the "fog of war" (i.e., the inability to communicate effectively amid the chaos of the battlefield) wreaks on their carefully laid plans. I sometimes feel the same way about the challenge of maintaining a productive dialogue in highly competitive standards situations. When the commercial stakes begin to rise, there too often seems to be a greater desire to exchange verbal salvos than to actually communicate. And it also becomes more tempting to be content with generalizations than to try to get to the bottom of things to figure out what's really going on.

About 10 days ago I tried to do a bit of fog cutting by posing a few questions at Jason Matusow's blog at the end of a post he had titled Independent Implementations of Open XML. Jason does a conscientious job of trying to answer all of the questions that people leave at his blog, including those that are not exactly what you'd call polite. In this case, Jason had listed six implementations of OOXML, supplying the usual links to the sites of the vendors in question.

Những gì tôi muốn tới đáy trong trường hợp này là thực sự những triển khai này có cố gắng để hoàn thành hay không. Những người bảo vệ ODF thích tập trung vào không chỉ khả năng của ODF được sử dụng như cơ sở cho những triển khai các bộ phần mềm văn phòng, mà trên thực tế là những bộ như vậy thực sự được làm ra trong thực tế. Họ cũng muốn chỉ ra rằng không có bộ phần mềm nào như vậy triển khai OOXML, ngoài bản thân bộ Office, mặc dù có các sản phẩm (như triển khai OpenOffice của Novell) mà chúng có thể lưu sang định dạng của OOXML. Và để công bằng, Microsoft đã thường xuyên khẳng định rằng OOXML và ODF được tạo ra cho 2 mục đích hoàn toàn khác nhau. Vì thế tôi tò mò muốn biết mục đích nào các triển khai này đã muốn có.

Mục đích thực sự của nó là gì? Vâng, tôi nghĩ rằng nó có. Nhưng trước khi khai phá tuyên bố đó tiếp tục, hãy xem các câu hỏi mà tôi đã hỏi trên blog của Jason và cách mà chuỗi câu trả lời được đưa ra từ điểm đó trở đi.

Jason đã mở bài viết của mình bằng việc đưa ra địa chỉ các câu hỏi mà chúng đã được đưa ra về chất lượng đặc tả kỹ thuật của OOXML và sau đó chuyển sang điểm về chất lượng (hoặc ít nhất tính sử dụng) là trong con mắt của khán giả – trong trường hợp này, thị trường – một điểm mà tôi đồng ý với nó. Anh ta đã kết luận bài viết của mình như sau: Vậy thì còn các triển khai độc lập đó thì sao? Tôi sẽ không trở nên điên rồ và cố liệt kê chúng tất cả ở đây. Tôi có thể khuyến cáo kiểm tra danh sách các dự án của cộng đồng OpenXML và nếu bạn quan tâm tự bản thân làm một vài việc gì đó để xây dựng một triển khai – hãy kiểm tra OpenXMLDeveloper.org. Hơn nữa, các bạn tôi ở Đức đã cung cấp cho tôi đường liên kết này tới hơn 160 dự án triển khai Open XML (nhưng tôi nghĩ nó tốt nhất nếu bạn biết làm thế nào đọc được tiếng Đức đối với nó).

What I wanted to get to the bottom of in this case was what exactly these implementations were trying to accomplish. ODF advocates like to focus on not only the potential for ODF to be used as the basis for office productivity suite implementations, but on the reality that such suites have actually been produced. They also like to point out that there are no such suites implementing OOXML, other than Office itself, although there are products (such as Novell's OpenOffice implementation) that can save to the OOXML format. And to be fair, Microsoft has consistently said that OOXML and ODF were cre-ated for two entirely different purposes. So I was curious to learn to what purposes these implementations were intended.

Does the nature of those purposes really matter? Yes, I think that it does. But before exploring that statement further, let's take a look at the questions that I asked at Jason's blog, and how the thread developed f-rom that point forward.

Jason had opened his post by addressing the questions that have raised about the quality of the OOXML spec, and then moved on to make the point that quality (or at least utility) is in the eye of the beholder – in this case, the marketplace – a point on which I agree. He concluded his post as follows:

So how about those independent implementations? I'm not going to go crazy and try to list them all here. I would recommend checking out the OpenXMLCommunity list of projects and if you are interested in doing some work yourself to build an implementation - check out OpenXMLDeveloper.org. Also, my colleagues in Germany have provided me with this link to more than 160 projects implementing Open XML (but I think it best if you know how to read German for that one).

Here are a few:

Đây là một số:

• Monarch từ Datawatch

• XMLSpy từ Altova

• iPhone từ Apple

• Mindmanager từ Minjet

• Gnumeric từ Gnome

• Dataviz Document To Go từ Palm

• Open XML IIS Analyzer từ Intergen

• Monarch f-rom Datawatch

• XMLSpy f-rom Altova

• iPhone f-rom Apple

• Mindmanager f-rom Minjet

• Gnumeric f-rom Gnome

• Dataviz Documents To Go f-rom Palm

• Open XML IIS Analyzer f-rom Intergen

Tại vài điểm câu hỏi cần được đưa ra về mong muốn đối với các cơ quan tiêu chuẩn có các điều khoản công việc mà chúng đại diện cho những gì đang hiện hành và có giá trị trên thị trường. Còn phải làm việc nhiều để làm được Open XML bên trong ngữ cảnh được chính thức hoá của JTC1, và đó là tốt. Nhưng không nghi ngờ về sự thực rằng việc thuyết phục công nghệ này là việc hưởng thụ một sự bùng nổ mối quan tâm trong thị trường hoàn toàn tách biệt với việc bán Microsoft Office. Đây là thước đo rất thực tế về chất lượng của đặc tả kỹ thuật này.

Mặc dù theo các đường liên kết đó, không nói lên cho bạn nhiều chính xác về cách mà các sản phẩm đã viết về sử dụng thực sự OOXML. Liệu họ đã hoàn tất các triển khai của bộ phần mềm văn phòng, như OpenOffice hoặc KDE, hoặc họ các sử dụng OOXML chỉ để cho phép việc trao đổi thông tin của họ với Office? Vì thế tôi đã hỏi như sau:

Jason, tôi nghĩ rằng sự hiểu nhầm xuất hiện ở 2 mức: trước tiên, khi hầu hết mọi người đều nói “không có triển khai nào”, tôi nghĩ là chúng có nghĩa là không có bộ phần mềm văn phòng cạnh tranh nào khác dựa trên OOXML, mặc dù một vài bộ (như triển khai ODF của Novell) sẽ có khả năng lưu sang OOXML.

At some point the question needs to be raised about the desire for standards bodies to have work items that represent what is current and valuable in the marketplace. There is still hard work to be done on Open XML within the formalized context of JTC-1, and that is good. But, there is no doubt about the fact that this compelling technology is enjoying an explosion of interest in the marketplace completely separate f-rom the sale of Microsoft Office. That is a very practical measure of the quality of this specification.

Following those links, though, doesn't tell you much about exactly how the products noted actually use OOXML. Are they complete office suite implementations, like OpenOffice or KDE, or do they utilize OOXML only to enable their exchange of information with Office? So I asked the following:

Jason, I think that whe-re the confusion comes in is at two levels: first, when most people say "there are no other implementations," what I think that they mean is that there is no other competing office suite based upon OOXML, although some suites (such as Novell's ODF implementation) will be able to save to OOXML.

Điều thứ 2 là liệu các triển khai này có là những triển khai đứng độc lập mà chúng đang sử dụng OOXML như một công cụ được ưa thích hơn, hoặc liệu họ có đang triển khai nó chỉ vì họ cần tương tác với các sản phẩm của Microsoft.

Khi các danh sách đưa ra các sản phẩm mà chúng triển khai OOXML mà không giải thích cách nào và vì sao, tôi nghĩ rằng nó để mọi người còn phải phỏng đoán, đặc biệt nơi mà các sản phẩm nhwu iPhone được nói tới, vì nó rõ ràng là không trực giác về cách mà điều này có thể được thực hiện, hoặc vì sao.

Tôi nghĩ cái gì là hữu ích nếu bạn hoặc ai đó nữa có thể giải thích được bằng cách nào và vì sao. Ví dụ, giả sử của tôi là (có thể là hoàn toàn sai) hầu hết các triển khai có thể cho phép các sản phẩm khác tương tác với Office, làm cho triển khai của họ trở nên thực tế hơn trong việc sử dụng một tiêu chuẩn giao diện hơn là như một nền móng đối với sản phẩm của họ được chọn cho giá trị thực chất bên trong của OOXML.

Nếu danh sách ở trên là tốt khi mọi sản phẩm sử dụng cho mục đích này, nó có thể rất quyến rũ để giải thích, đối với từng sản phẩm:

1. Liệu triển khai này cho mục đích đó có làm việc được với Office (ví dụ, trong sản phẩm của Datawatch, liệu triển khai này có phải chỉ để cho phép khai thác các dữ liệu được lưu giữ trong cơ sở dữ liệu của Office 2007?)

2. Nếu không, thì OOXML đang được sử dụng như thế nào? và vì mục đích gì?

The second is whether these implementations are stand alone implementations that are using OOXML as a preferred tool, or whether they are implementing it solely because they need to intereact with Microsoft products.

When lists are posted of products that implement OOXML without explaining the how and why, I think that it leaves people still puzzled, particularly whe-re products such as the iPhone are mentioned, because it isn't intuitively obvious how this would be done, or why.

I think what would be helpful would be if you, or someone else, could explain the how and why. For example, my assumption (which may be all wrong) is that most of the implementations would be to allow other products to interact with Office, making their implementation more in the nature of utilizing an interface standard rather than as a foundation for their product chosen for OOXML's intrinsic merit.

If the above list is as good as any to use for this purpose, it would be very interesting to explain, for each product:

1. Is this implementation for the purpose of working with Office (for example, in the Datawatch product, is the implementation only in order to allow mining of data saved in Office 2007 databases?)

2. If not, how is OOXML being used, and to what purpose?

Trong một lưu ý khác, có thể sẽ thú vị biết liệu sản phẩm đó có hay không được dựa trên ODF, và nếu không, liệu nguyên nhân có khác hơn là vì sản phẩm đó cần làm việc với Office 2007.

Những ngày sau đó, một số người từ các nhà phân phối mà Jason đã kết nối tới đã đăng nhập vào để trả lời các câu hỏi này, và một loạt những điều thú vị khác và các bình luận quan trọng đã được đưa lên. Tôi sẽ không cố gắng tổng kết chúng ở đây (như hôm nay, có 35 bình luận), nhưng chúng làm cho thú vị và đọc được nhiều thông tin, và tôi có thể đoán bạn hãy kiểm tra chúng liệu bạn có quan tâm tới những gì mà những người khác đang sử dụng OOXML hay không. Tôi đã đưa lên bình luận khác trên blog của Jason và rời bỏ các bình luận này. Sự quan sát của tôi được đọc một phần như sau:

On a different note, It would be interesting to know whether the product could or could not have been based on ODF, and if not, whether the reason is other than because the product needs to work with Office 2007.

In the days that followed, a number of folks f-rom the vendors Jason had linked to logged on to answer these questions, and a variety of other interesting and worthwhile comments were posted as well. I won't try and summarize them here (as of today, there are 35 comments), but they make interesting and informative reading, and I'd suggest you check them out if you're interested in what others are using OOXML for. I posted another comment at Jason's blog with my take-aways f-rom these comments. My observations read in part as follows:

As a non-technical person, what I'm taking away f-rom this thread is the following:

Như một người không hiểu biết về kỹ thuật, những gì tôi từ bỏ khỏi các bài viết là như sau:

1. Câu hỏi ban đầu của tôi là quá giản dị. Dường như bạn không thể chia các triển khai OOXML thành những thứ chỉ cho mục đích làm việc với Office, hoặc các dữ liệu được lưu trữ trong Office, và những thứ mà chúng triển khai OOXML vì các mục đích độc lập của riêng họ, mặc dù điều đó làm việc được đối với vài sản phẩm.

Dường như là câu hỏi làm việc được cho Gnumeric và Altova (câu trả lời cho mỗi sản phẩm này là tương đối “người xưa cũ”. Trong trường hợp các Hồ sơ người sống, OOXML sẽ được sử dụng để tạo ra các tài liệu để sử dụng “bên ngoài” ứng dụng này, như nó đã từng (đó là có thể một cách ẩn dụ hơn là chính xác về mặt kỹ thuật). Và đối với Datawatch (một khách hàng cũ của tôi, khi xảy ra, ngược lại về đầu những năm 1980, khi họ đã thực hiện công nghệ TEMPEST), thì câu trả lời cũng là phức tạp hơn.

2. Andrew và Ben cũng đưa ra câu hỏi ở mức chi tiết kỹ thuật ngoài khả năng của tôi: đủ khó đối với tôi để xem khu rừng ở đây, hãy để một mình tách biệt tôn ti thứ bậc kỹ thuật khỏi các cây cối (xin lỗi, không thể tự giúp tôi ở đó).

3. OOXML cóc vài khía cạnh mà một vài người thấy thú vị, và ưa chọn công nghệ trước đó của Microsoft.

4. Vì giữa ODF và OOXML, câu hỏi là, từ một viễn cảnh kinh doanh, có cái gì đó có thể bàn, đưa ra sự thâm nhập thị trường tối thiểu của OOXML.

5. Dường như là mọi sản phẩm như thế này “được xây dựng trên” OOXML, trong ý nghĩa ban đầu câu hỏi của tôi. Không quá ngạc nhiên, đưa ra rằng nó chỉ được ECMA đưa ra vào cuối năm ngoái và còn chưa kết thúc tại ISO/IEC JTC1. Điều đó làm cho câu hỏi cái gì đó chưa chín, mặc dù đưa ra cơ sở được cài đặt của những người sử dụng Office và mức độ biết trước được về nâng cấp, triển khai một cách sớm theo cách được mô tả trong các bài ở đây được xem là một động thái kinh doanh thông minh.

1. My initial question is too simplistic. It seems that you can't divide OOXML implementations into just those that are for the purpose of working with Office, or data stored in Office, and those that implement OOXML for their own stand-alone purposes, although that does work for several of the products.

It seems that the question does work for Gnumeric and Altova (the answer for each is pretty much, "the former"). In the case of Records for Living, though, OOXML will be used to cre-ate documents for use "outside" the application, as it were (that's probably more metaphorically than technically accurate). And for Datawatch (an old client of mine, as it happens, back in the early 1980s, when they were doing TEMPEST technology), the answer is also more complex.

2. Andrew and Ben also take the question to a level of technical detail that is beyond my competence; it's hard enough for me to see the forest here, let alone separate the technical hierarchies f-rom the trees (sorry, couldn't help myself there).

3. OOXML has some aspects that some find attractive, and preferable to earlier Microsoft technology.

4. As between ODF and OOXML, the question is, f-rom a business perspective, somewhat moot, given the minimal market penetration of OOXML to date.

5. It doesn't appear that any of these products are "built on" OOXML, in the original sense of my question. That's not too surprising, given that it only came out of Ecma last year, and still isn't final in ISO/IEC JTC1. That makes the question somewhat premature, although given the installed base of Office users and the anticipated level of upgrades, early implementation in the manner described in this thread has obviously been seen to be a smart business move.

Các bình luận vẫn tiếp tục. Jason bổ sung thêm một bài mới với sự quan sát của riêng mình về câu hỏi triển khai, mà bạn có thể tìm thấy ở đây, và bài này nay cũng đang thu thập các bình luận.

Đạo lý của câu chuyện, tôi nghĩ, là việc lời nói không mất tiền mua, và thị trường cuối cùng sẽ quyết định nơi nào nó tìm thấy giá trị, và bằng cách nào. Tôi muốn thấy nhiều thông tin về chất lượng hơn về những ai chính xác đang triển khai từng định dạng, và cách nào, vì mục đích gì. Nếu thấy rằng hầu hết các triển khai OOXML chỉ là để tương hợp với Office hoặc để trích dữ liệu từ Office, thì đó sẽ có nghĩa một thứ. Mặt khác, nếu OOXML cũng được sử dụng cho những thứ khác hoàn toàn, nó sẽ rất thú vị để xem những thứ đó là như thế nào.

Tất nhiên là nó sẽ nói lên nhiều hơn việc xem ai đang mua hoặc sử dụng các triển khai đó. Và cuối cùng, nó sẽ thật thú vị để quan sát cách mà, về lâu dài, hoạt động của thị trường này sẽ trả lời về sự tiến hoá tiếp theo của ODF và OOXML, và cách mà những thứ đó với hầu hết sự đánh cược trong các nhà cung cấp phản ứng đối với các yêu cẩu của những người tham gia khác cho sự tiến hoá như thế này.

Further comments followed. Jason added a new blog entry with his own observations on the implementation question, which you can find here, and this entry is now also collecting comments.

The moral of the story, I think, is that words are cheap, and the market ultimately decides whe-re it finds value, and how. I'd like to see more quality information on exactly who is implementing each format, and how, and for what purpose. If it turns out that most OOXML implementations are solely to interoperate with Office or to extract data f-rom Office, that will mean one thing. On the other hand, if OOXML is also used for entirely different things, it will be quite interesting to see what those things are as well.

It will of course be even more telling to see who is buying or using those implementations. And finally, it will be quite interesting to observe how, in the long run, this market activity feeds back into the further evolution of ODF and OOXML, and how those with the most at stake on the vendor side react to the requests of other stakeholders for such evolution.

Sau cùng, tôi sẽ không ngạc nhiên thấy xảy ra với ODF và OOXML những gì đã xảy ra với các tiêu chuẩn không dây ban đầu. Ngay từ đầu, chúng ta thấy Wifi,Bluetooth, HomeRF và một vài đặc tả kỹ thuật khác mà nay đã bị lãng quên, tất cả cạnh tranh để tạo nên các mạng LAN không dây. Sau vài năm, Wifi chiến thắng cuộc chiến ban đầu, trở nên thâm nhập vào từng nhà và một vài thiết lập LAN thương mại, trong khi Bluetooth trở thành công cụ của lựa chọn cho thiết bị cầm tay tầm ngắn cho giao tiếp thiết bị. Năm năm kể từ nay, chúng ta có thể thấy rằng OOXML vẫn chỉ được sử dụng trong một bộ phần mềm văn phòng và trong các sản phẩm khác cần tương tác với Office, trong khi ODF được triển khai trogn nhiều bộ văn phòng toàn phần. Nhưng chúng ta cũng có thể thấy rằng mỗi định dạng cũng chiếm được một vài chỗ đáng ngạc nhiên khác.

Với việc quay về với câu hỏi ban đầu về làm thế nào mỗi định dạng được triển khai, và liệu trong thực tế câu trả lời cho câu hỏi này thế nào. Bạn có thể nhớ lại rằng tôi đã nói rằng tôi đã nghĩ nó như vậy.

Lý do tôi nghĩ nó như vậy là trùng với lý do tôi đã đưa ra rất nhiều mối quan tâm về các định dạng tài liệu. Đó là vì tính có thể truy cập được trong tương lai của các tài liệu hiện nay phụ thuộc vào sự chấp thuận một tiêu chuẩn (hoặc ít lý tưởng hơn, các tiêu chuẩn) mà chúng hầu hết dường như được hỗ trợ trên cơ sở dài lâu suốt đời nếu có thể. Những gì chúng ta thấy trong thị trường trong 1 hoặc 2 năm tới, hơn là những gì xảy ra tại ISO/IEC JTC1 trong 6 tháng tiếp theo, hoặc trong những câu từ mà chúng ta nói đi nói lại hôm nay, cuối cùng sẽ xác định liệu tiêu chuẩn nào – nếu không phải cả 2 – sẽ thực sự đạt được nhiệm vụ sống còn này.

Ultimately, I wouldn't be surprised to see happen with ODF and OOXML what happened with the first wireless standards. Early on, we saw WiFi, Bluetooth, HomeRF and some other now-forgotten specifications all competing to enable wireless LANs. After a few years, WiFi won the original battle, becoming pervasive in home and some commercial LAN settings, while Bluetooth became the tool of choice for short-range mobile device to device communication. Five years f-rom now, we may see that OOXML is still only used in one office productivity suite and in other products that need to interact with Office, while ODF is implemented in many full office suites. But we may also see that each format is also popping up in some other surprising places as well.

Which brings us back to the original question of how each format is implemented, and whether in fact the answer to that question matters. You may recall that I said that I thought that it did.

The reason that I think it does is the same reason that I have taken so much interest in document formats. That is because the future accessibility of the documents of the present is dependent upon the broad adoption of the standard (or, less ideally, standards) that is most likely to be supported on as close to a perpetual basis as possible. What we see in the marketplace in the next year or two, rather than what happens in ISO/IEC JTC1 in the next six months, or in the words that we are slinging back and forth today, will ultimately determine which standard - if either – will actually achieve this vital mission.

Tôi muốn ủng hộ những giỏi kỹ thuật hơn là tôi đóng góp vào các bình luận của bạn ở đây hoặc trên blog của Jason để giúp làm tươi lại cơ sở tri thức về những triển khai nào của mỗi tiêu chuẩn thực sự đang cố đạt được. Tôi sẽ rất thú vị đọc những gì bạn phải nói, cũng như xem cách mà danh sách các triển khai được tăng lên. Đó là vì cách tốt nhất để đảm bảo rằng các tài liệu ngày hôm nay có thể mở được vào ngày mai là để cho số lượng lớn nhất các ứng dụng có thể thực sự tạo ra các tài liệu đó (của tất cả các dạng) trogn một định dạng. Khi số lượng các tài liệu như vậy bùng nổ, thì cũng sẽ có sự quan tâm bất di bất dịch và động cơ thúc đẩy gia tăng của tất cả các bên tham gia để duy trì và sử dụng định dạng đó trong tương lai.

I'd encourage those of you that are more technically adept than I am to contribute your comments here or at Jason's blog to help flesh out the knowledge base on what implementations of each standard are actually trying to achieve. I, for one, will be very interested to read what you have to say, as well as to see how the list of implementations grows. That's because the best way to ensure that the documents of today can be opened tomorrow is for the largest number of applications possible to actually cre-ate documents (of all types) in one format. As the number of such documents explodes, so also will the vested interest and motivation increase of all stakeholders to maintain and use that format forward into the future.

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

Công ty Cổ phần phần mềm – Thương mại điện tử Nhất Vinh

ltnghia@yahoo.com