互操作性對開放標準的新要求
互操作性對開放標準的新要求
4月20日我受邀出席“企業軟體與應用互操作國際會議(I-ESA)”,並應主辦方要求就UOF和互操作等問題作主題演講。以下是根據我的演講稿《互操作對開放標準的新要求》整理而成,代表我對這一問題的一些新思考,以饗讀者,歡迎探討。
目前在文件格式領域已有多個開放標準存在,包括ODF、OOXML,還有中國的國家標準UOF。可以說,我們在開放標準領域已經積累了很多經驗,但在實踐中我們越來越認識到,僅有格式標準是不夠的,還必須考慮格式的最終顯示問題。我把它稱之為“顯現”標準。而這個問題之所以直到今天才在我們的具體實踐中被發現,原因在於只有UOF才是同時由多個廠家制訂,多個廠家協作實現的文件格式標準。
過去文件格式標準的制定一般都是單一Office廠商制定,同時又是由單一Office廠商實現,因此只考慮了格式規範的描述,並沒有考慮文件的具體顯現標準,因為相應的顯現標準就是自己產品展示的結果。過去的DOC格式是封閉的格式標準,其標準的實現自然就是MS Office所展示的樣子。甚至於因為其封閉性,任何其他廠家要相容DOC,只能從其所顯示的結果去逆推格式文字。
ODF和OXML雖然已成為了國際標準,其制訂和釋出也都經歷了較長的完全開放的研討和修改,但這兩個標準嚴格意義上也還是單一Office廠家(社群)力量主導和實現的標準。如ODF是基於OpenOffice.org推出的,所以ODF所描述的顯現效果其實就是把OpenOffice.org作為唯一標準。所幸的就是因為OpenOffice.org實現樣本是開源的,因此版面演算法也是公開,大家基本能據以瞭解和實現ODF。而微軟所主推的OOXML格式標準,其唯一的實現樣本是MS Office 2007,換言之,是否符合OOXML標準事實上是由Office 2007說了算。如今的國際標準OXML是在OOXML的基礎上經過了大量修改後才推出的,目前國際上並沒有符合其標準的產品。當然,按照微軟公佈的計劃,將來Office 14可能會是第一個全面實現OXML的辦公軟體產品。只是那時候,微軟Office就會成為了OXML的標準樣本。
這個事實的關鍵點在於,ODF和OXML這兩個開放格式本身需要依賴一個產品才能最終確定是否是“符合”其標準,或者能“精確相容”其標準。這和我們過去依賴微軟Office來相容DOC有點類似,進步之處在於ODF和OXML本身是開放的。而這個開放性確保了文件內容的可閱讀性,資料的長期可儲存性以及可呼叫;但不能確保不同Office產品對同一文件的精確相容性。而作為標準的“實現樣本”,OpenOffice.org和MS Office顯然在實現自己主推的格式上明顯具備了先天優勢,因為他們本身已成為了標準的一部分----顯現標準。
這也是基於UOF產品實現過程中最大的困難所在。從UOF本身的發展來說,格式本身基本上和ODF、OXML的在體系結構和標準質量上處在同一水平;但在其實現過程中,卻明顯要比ODF和OXML更為複雜繁瑣。因為,根據標準描述所實現的每一步均需要得到四個產品RedOffice、永中Office、WPS和中標Office的基本認可或者多數認可;並且同時制訂相應的測試案例和標準。目前各家廠商根據UOF標準的描述可以進行實現,這已獲得認可,但從使用者的角度來看,目前的實現可能還存在問題,會覺得實現得步伐和程度較慢。這其實涉及的就是顯現標準問題。
如果只是呼叫目前這些開放文件格式標準的內容,ODF、OXML和UOF均已展現其開放性,但要真正解決Office互操作性問題尤其是顯示的“精確相容”問題,必須儘早提到就整個顯現問題出臺統一標準的高度。顯現標準的制定可參考開放標準制定規則,集中和吸引相關廠商進行共同制定,顯現標準應具體涵蓋排版規則、式樣集和文件元素式樣等內容,並根據文件的不同型別定義不同的顯示效果。目前UOF在這些方面已經建立起較好的基礎,只是沒有按照制定一個統一的顯現標準的高度和思路來統領相關工作。因此需儘快確立顯現標準的制定方法和思路,在具體工作上應進一步細化和明確版面演算法和顯示規範,並進一步完善測試案例集等。退一步說,開放標準如ODF、OXML也都需要標準符合性測試規範;這一點,現在還只有UOF有很大進展。
開放的文件格式標準的推廣將有效促進產業的多元化。多種實現本身就是開放標準的目標,只有統一的顯現標準的出臺才能有效解決不同實現之間的互操作問題。另外隨著WebOffice的發展,桌面Office和WebOffice相互間的互操作性問題也同樣需要納入開放文件格式標準中進行統籌考慮,還有現存的DOC格式歷史文件的轉換問題,同樣需要顯現標準的支援。否則,在中國市場,尤其在電子公文領域裡的“精確相容”要求,並不能在現行開放標準的體系下解決。在此方面,UOF顯然已先行一步。
我們在實踐中認識到,開放標準與其最終的實現,包括其實現的方法有很大關係。在文件格式領域,沒有顯現規範,標準的主要制定者將在事實上決定標準的“表現”,其開放性不能得到真正保證,其競爭產品還需要依賴標準的“實現樣本”。相應的,真正的開放標準一定要考慮具體的實現辦法是否是“開放”的,或者是其結果有明確的“標準”的,否則其開放性就要受到限制。也許在其它領域裡開放標準,是否要對其關鍵因素和關鍵技術的實現進行規範和約束,並把這些規範納入開放標準範圍,也要慎重考慮。
相關閱讀:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14682504/viewspace-592046/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- IOT語義互操作性之標準與開源
- 雲端計算標準化以及互操作性方面的標準
- 基於混合雲管理標準化模型,消除差異化與互操作性難題模型
- 微軟對華開放互操作原始碼微軟原始碼
- 痞子衡嵌入式:並行介面NAND互操作性標準(JEDEC-JESD230)並行NaN
- 陸首群:開源與微軟API的互操作性微軟API
- 發展中的SOAP互操作性
- 英國迫使微軟採用開放文件標準(ODF)微軟
- 英特爾:基於開放標準的雲解決方案
- 開放資料OData協議成為OASIS標準協議
- 標準的開發框架,對企業開發有多重要?框架
- 新興的去中心化、開放式實時通訊標準:Matrix中心化
- IOT語義互操作性之API介面API
- IBM Mashup Center:OpenSocial 互操作性IBM
- 互操作性的區塊鏈系統設計理念區塊鏈
- 對SAP專案文件的考核標準
- OpenMessaging:構建一個分散式訊息分發的開放標準分散式
- Kotlin 1.6.20釋出:更好的Java互操作性 - infoworldKotlinJava
- 互動設計方案衡量標準的五層總結
- 騰訊王巨巨集:雲與開源共生共榮|共建開放協作的技術標準
- 爐邊對話:區塊鏈技術的互操作性問題和區塊鏈的未來區塊鏈
- 對SAP專案文件的考核標準(轉)
- 開放API未必就等於互通互聯API
- Samba解決了Linux與Windows互操作性的辦法SambaLinuxWindows
- 開源與標準(轉)
- C++ Qt開發:標準Dialog對話方塊元件C++QT元件
- Linux的標準輸入、標準輸出和標準錯誤Linux
- Twitter將使用區塊鏈等分散式技術建立新的社交媒體開放標準區塊鏈分散式
- 索尼VR遊戲新要求 低於60幀不準登陸PS VRVR遊戲
- c#之互操作性_(非)託管程式碼小記C#
- Qt標準對話方塊實現QT
- 開源與標準:為什麼對待專利如何不同?
- APP開啟(二)—標準流程APP
- 構建“萬物互聯”生態鏈,微信對話開放平臺正式釋出
- 歐盟冷對微軟“API”開放微軟API
- Web快速開發:一套標準開發框架對企業有多重要Web框架
- 零信任產業標準工作組發起相容性認證計劃,打造行業互聯互通標準產業行業
- USB4標準釋出 Intel完全開放雷電技術:底層融合USB 4Intel