Ai có thể triển khai được MSOOXML?

Thứ năm - 30/08/2007 07:30
MSOOXML: Hỗ trợ của bên thứ 3 – Apple iWork '08

MSOOXML: Third Party Support - Apple iWork '08

Theo: http://www.openmalaysiablog.com/2007/08/msooxml-third-p.html

Bài được đưa lên Internet ngày 25/08/2007

Khi Apple tung ra iWork '08, các bloggers của Microsoft ngay lập tức nhảy lên bình luận về việc nó chứng minh rằng MSOOXML là dễ dàng được triển khai bởi bên thứ 3. Trước hết, chúng ta cần hiểu rõ rằng Apple ngồi trong Uỷ ban Kỹ thuật của ECMA mà nó “đã phát triển” cái gọi là tiêu chuẩn này. Vì thế chúng ta phải hoàn toàn không được ngạc nhiên nếu chúng có hỗ trợ định dạng tệp này trong các sản phẩm sẽ ra đời bao gồm cả iPhone.

Tuy nhiên những gì chưa được nói, và tôi đang chờ đợi vài ngày một câu trả lời từ Stephen McGibbon của Microsoft, là vì sao Apple KHÔNG hỗ trợ MSOOXML một cách thực sự.

When Apple released iWork '08, the Microsoft bloggers immediately jumped in to comment on how this is proof that MSOOXML is easily implementable by third parties. First of all, we need to realise that Apple sits in the Technical Committee at Ecma which "developed" this so called standard. So we should not be surprised at all if they have support of this file format in their upcoming products including the iPhone.

What is not said however, and I have been waiting for days for a response f-rom Microsoft's Stephen McGibbon, is why Apple does NOT really support MSOOXML.

What? iWork '08 DOESN'T support MSOOXML?!

Cái gì? iWork '08 KHÔNG hỗ trợ MSOOXML?!

Đúng vậy. Nếu bạn xem một cách kỹ lưỡng các ví dụ mà Microsoft cung cấp, chúng chỉ trình diễn các tính năng chỉ đọc của iWork. iWork không GHI được sang MSOOXML. Như một thành viên bạn bè của uỷ ban kỹ thuật mà nó đã thực sự phát triển đặc tả kỹ thuật này, bạn có lẽ đã mong đợi vài dạng khả năng đọc/ghi có thể tương thích tới 70%, để hoàn chỉnh cái vòng của “tính tương hợp”, phải không bạn?

Trừ phi tất nhiên là nó quá khó để làm?

Có lẽ Apple có thể bỏ ra nhiều thời gian hơn để tạo ra phần mềm tốt thay vì việc triển khai một định dạng tệp nhìn ngược về quá khứ mà “đối tác” của nó đang bốc hơi cuồn cuộn qua qui trình tiêu chuẩn hoá? Có thể nó đã được tư vấn từ nhóm Macintosh của riêng Microsoft, và những khó khăn họ đối mặt trong việc đưa định dạng tệp MSOOXML lên một nền tảng mới? Bộ phận kinh doanh máy Mac của Microsoft kêu ca rằng nó có thể chiếm một đội 5 người 44 tuần để triển khai ¼ phần việc của một sản phẩm.

Yes. If you have a careful look at the examples the Microsofties provide, they just demonstrate read only features of iWork. iWork does not WRITE to MSOOXML. As a fellow member of the technical committee which actually developed the spec, you would have expected some form of read / write ability to perhaps 70% compliance, to complete the circle of "interoperability," wouldn't you?

Unless of course it is too hard to do?

Maybe Apple would rather spend time creating great software instead of implementing a backwards looking file format which its "partner" is steamrolling through the standardisation process? Maybe it has taken advice f-rom Microsoft's own Macintosh team, and the difficulties they are facing in porting the MSOOXML file format on a new platform? Microsoft's Mac Business Unit claims that it would take a team of 5 people 44 weeks to implement a quarter of one product.

Andrew Shebanow (từ Adobe) đã làm phép ngoại suy và tính được rằng nó có thể “chỉ cần“ 120 người/nhiều năm để triển khai MSOOXL. Số lượng đầu tư lớn này chỉ để đọc và ghi tệp cho một nhà cung cấp là những gì các các Mỹ có thể thấy được sự nản lòng:

Làm sao các đối thủ cạnh tranh có thể chịu được mức đầu tư như vậy? Novell nói họ sẽ hỗ trợ nhập và xuất cho OOXML với sự hỗ trợ về tài chính và kỹ thuật từ Microsoft. Corel nói họ cũng sẽ làm như vậy. Hãy đoán chúng tôi sẽ cần chờ đợi và xem làm thế nào họ sẽ thành công được trong việc duy trì lòng trung thành và tính tương thích, mặc dù đưa ra thứ Rick phải nói, Tôi không chắc chắn lắm”.

Không nghi ngờ vì sao Office for Mac đã bị chậm 2 lần khi, với ngày tung ra “được lên kế hoạch” trong năm 2008. Nó đã là tốt nhất trong năm 2008, vì tên sản phẩm đã được đặt thành “Microsoft Office 2008 for Mac”.

Andrew Shebanow (f-rom Adobe) extrapolated that and calculated that it would take a "mere" 120 man years to implement MSOOXML. This large amount of investment just to read and write files for one vendor is something American countries would find daunting:

"How can competitors afford to make that level of investment? Novell says they will support import and export for Open XML with financial and technical help f-rom Microsoft. Corel says they’ll do it too. Guess we’ll need to wait and see how successful they’ll be at maintaining fidelity and compatibility, though given what Rick has to say, I’m not super confident."

It is no wonder why Office for Mac has been delayed twice since, with the "projected" date of release in 2008. It had better be 2008, because the product name has been set to "Microsoft Office 2008 for Mac".

Quay lại với Apple. Họ là các thành viên của uỷ ban (của ECMA). Họ được cho là đã đóng góp cho sự phát triển của đặc tả kỹ thuật này. Khi tôi hỏi Stephen McGibbon là Apple đã đóng góp cái gì, [được cập nhật ngày 25/08/2007] thì Brian Jones đã nói:

Apple đã đóng góp rất lớn. Họ đã đưa vào những triển khai cho chức năng của phiên bản trong tương lai; drawingML và VML; và nhiều thời gian tập trung vào tính tuân thủ”.

Tôi nghĩ đó là sự châm biếm to lớn vì MSOOXML đang gặp khó khăn khổng lồ từ các vấn đề phiên bản với sự trộn rộn của những thứ đã có và bị phản đối theo kiểu giả sử là nhưng đáng ngạc nhiên thường thấy đối với VML và sự “giàu chất” DrawingML. Như những người lính của mỹ từ học, một người có thể có suy nghĩ các đại diện của Apple có lẽ đã bảo vệ ở ý tưởng của 2 đặc tả kỹ thuật như nhau về chức năng sẽ được đưa vào trong cùng một cơ thể công việc. Thật không tối thiểu tí nào.

Now back to Apple. They are committee members. They allegedly contributed to the development of the specification. When I asked Stephen McGibbon what Apple contributed, [Up-dated 070825] Brian Jones said:

"Apple made huge contributions. They included improvements to the future versioning functionality; drawingML and VML; and big time focus on conformance."

I thought this was hugely ironic because MSOOXML suffers f-rom huge versioning issues with the mixup of the legacy and supposedly deprecated but surprisingly prevalent VML and the "richer" DrawingML. As soldiers of aesthetics, one would have thought the Apple representatives would have balked at the idea of the two functionally equivalent specifications to be included in the same body of work. How un-minimal.

Pinning the monkey

Vòng vo con khỉ

Sau đó tôi đã hỏi “iWork có lưu sang MSOOXML?” Stephen sau đó bắt đầu đánh trống lảng cuộc bàn luận với những vấn đề của ODF, KOffice, và OpenFormula, ngay cả thái độ của tôi, và tiếp tục tránh câu hỏi đơn giản đó. Nguyên nhân vì sao ông ta không thể trả lời câu hỏi này là vì ông ta đã đặt đầu đề cho bài viết trên blog của mình là: “iWork '08 hỗ trợ OpenXML”.

Nó làm cho bạn nghi ngờ vì sao “hỗ trợ” thực sự lại có nghĩa đối với những người theo Microsoft. Có thế nó “hỗ trợ” quan điểm của Microsoft.

Thay vào đó, các cơ quan tiêu chuẩn quốc gia và những người xem xét lại đặc tả kỹ thuật của OOXML phải hỏi các câu hỏi tiếp sau đây:

  • Vì sao “con dấu đóng chấp thuận” từ Apple lại không dịch được sang định dạng tệp nguyên thuỷ hỗ trợ trong ứng dụng sản xuất của hãng?

  • Liệu có phải Apple đã nghĩ rằng MSOOXML là không đủ tốt cho họ?

  • Là những chủ nhân của MSOOXML, vì sao Microsoft không tò mò việc vì sao những khoản chi của họ để có được các đối tác kinh doanh như Apple (và Novell) lại không chọn OOXML hơn là các định dạng tệp nguyên thuỷ của riêng họ?

  • Vì sao Microsoft lại không giải quyết bất kỳ vấn đề gì liên quan tới sự bất đắc dĩ của Apple để chấp thuận định dạng tệp dự kiến có tính toàn cầu này bên trong ECMA TC45, hoặc ngay cả trước khi mà iWork được tung ra?

Bổ sung thêm:

  • Liệu nó có thể là Apple đang giữ lại những đóng góp của mình cho TC45 và giữ bí mật về các tính năng mới của iWork để có “một thứ chơi trội“ đối với các thành viên uỷ ban kỹ thuật bạn bè khác?

  • Hay là vì Apple không lo ngại cho sự đóng góp?

  • Hay là vì phạm vi của TC45 đã được xác định quá hẹp không đủ cho một dòng sản phẩm của nhà cung cấp (Microsoft)?

I then asked "Can iWork save MSOOXML?" Stephen then started to divert the discussion with issues of ODF, KOffice, and OpenFormula, even my attitude, and continued to avoid that simple question. The reason why he cannot answer the question is because he entitled his blog post: "iWork '08 supports OpenXML"

It makes you wonder what "support" really means to Microsofties. Maybe it "supports" his view.

Instead, National Bodies and reviewers of the MSOOXML spec should ask these further questions:

  • Why doesn't that "stamp of approval" f-rom Apple translate to native file format support in its productivity application?

  • Didn't Apple think MSOOXML was good enough for them?

  • As owners of MSOOXML, why wasn't Microsoft curious why their paid to be business partners like Apple (and Novell) didn't choose MSOOXML over their own native file formats?

  • Why didn't Microsoft resolve any issues relating to Apple's reluctance to adopt this supposedly universal file format within Ecma TC45, or even prior to the iWork launch?

Additionally:

  • Could it be that Apple has been holding back on its contribution to TC45 and has kept secret iWork's new features so as to have a "one-up" on its fellow technical committee members?

  • Or was it because Apple did not bother to contribute?

  • Or was it because TC45's scope was so narrowly defined to just one vendor's (Microsoft's) line of products?

Chúng là những câu hỏi vô cùng quan trọng. Tôi đã đưa các câu hỏi này lên blog của Stephen vào ngày 16/08 và cho tới hôm nay (25/08), không có hồi âm. Ông ta có lẽ đã lờ tôi đi khi bị sập bẫy. Đã có vài lần xảy ra như vậy rồi.

Nếu Apple rất sắc sảo về định dạng tệp của riêng mình, và Microsoft yêu thích tranh cãi về “sự lựa chọn trong các tiêu chuẩn”, liệu Microsoft có đưa tay ra giúp Apple trong việc tiêu chuẩn hoá định dạng tệp riêng của Apple thông qua ECMA và ISO khi mà Microsoft đã đặt nền móng bằng việc đầu tư rất nhiều vào việc mua các uỷ ban kỹ thuật, các cơ quan tiêu chuẩn và các bộ trưởng khắp toàn cầu?

These are extremely important questions. I posted these questions on Stephen's blog on the 16th of August, and till today (25th of August), not a squeal. He tends to ignore you when he's trapped. It's happened quite a few times already.

If Apple is so keen on its own file format, and Microsoft loves the "choice-in-standards" argument, would Microsoft give a helping hand to Apple in standardising Apple's own file format through Ecma and ISO since Microsoft has laid the groundwork by investing so much in buying up technical committees, standards bodies and ministers around the world?

iWork XML vs ODF vs OOXML

iWork XML với ODF với OOXML

Và còn thú vị hơn nữa cơ. Rambler của Cybertech đã bỏ chút thời gian để xem xét các định dạng tệp trong iWork '08. Những gì ông lưu ý có thể là thú vị: “Những ý nghĩ mào đầu của định dạng XML của iWork với ODF với OOXML”

Giống như định dạng tệp ODF, index.xml là tự chứa. Nó thực sự giống ODF hơn là gần với OOXML trong vấn đề này và nhiều khía cạnh khác”. Đặc biệt, chúng ta không thấy tên hoặc tên thuộc tính của yếu tố XML được viết tắt ngoại trừ những thứ đặc biệt rõ ràng và được lấy từ HTML. Điều này, tất nhiên, là chìa khoá cho việc vì sao tôi có thể giải mã được tệp một cách nhanh chóng. Chúng ta không xem “các thẻ chạy – run tags” (ví dụ các thẻ rPr) mà Microsoft khăng khăng là nó cần để lập tài liệu một cách đầy đủ cho các thuộc tính của văn bản. Các thẻ tính chất này là các thuộc tính của yếu tố nó tham chiếu tới, cách mà nó được thực hiện trong ODF và cách mà tôi nghĩ nó cần phải có”.

Rambler cũng khẳng định những gì mà những người theo Microsoft phủ nhận khẳng định: “về việc đọc website và tài liệu của iWork, nó thể hiện rằng iWorks chỉ có thể đọc tệp OOXML nhưng không thể ghi nó. Thật đáng tiếc”. Thực sự thật đáng tiếc.

Các thành viên bạn bè trong uỷ ban không có niềm tin vào định dạng tệp họ đã dự kiến làm việc tới gần 1 năm. Tôi không hiểu vì sao?

And it gets more interesting. The Cybertech Rambler has taken some time out to review the file formats in iWork '08. What he notes is mighty interesting: "iWorks XML format vs ODF vs OOXML preliminary thoughts"

"Like ODF single file format, index.xml is self-contained. It actually resembles ODF more closely than OOXML in this and many other respects. In particular, we do not see abbreviated XML element name or attribute name except those that are extremely obvious and borrowed f-rom HTML. This, of course, is the key to why I can decipher the file quickly. We do not see “run tags” (rPr tags for example) that MS insist it needs to fully document the properties of the text. Those property tags are attributes of the element it refers to, the way it is done in ODF and the way I think it should be."

He also confirms what the Microsofties refuse to confirm: "on closer reading of iWorks website and documentation, it appears that iWorks can only read OOXML file but cannot write it. That’s a pity."

What a pity indeed.

Fellow committee members have no faith in the file format they supposedly worked on for less than a year. I wonder why?

yk.

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

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

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ập222
  • Máy chủ tìm kiếm8
  • Khách viếng thăm214
  • Hôm nay3,866
  • Tháng hiện tại452,645
  • Tổng lượt truy cập36,511,238
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