DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> XML學習教程 >> XML詳解 >> 模型驅動的復合文檔開發
模型驅動的復合文檔開發
編輯:XML詳解     

復合文檔

  W3C 已經成立了 Compound Document Formats (CDF) 工作組。CDF 工作組源自 Web Applications and Compound Documents Workshop,探索關於復合文檔標准化和某些格式結合的行為規范的問題,解決可擴展和可互操作 Web 的要求。

  CDF 工作組專注於將成為 CDF 配置文件的特定名稱空間詞匯表的組合,比如用於移動設備的豐富媒體配置文件可能包括 XHTML 和 SVG Tiny。其他的例子包括 XHTML 和 XForms 的組合、使用 X+V 配置文件的 XHtml 和 VoiceXML 一個子集的組合。

  復合文檔定義

  名稱空間惟一標識了一組名稱,這樣,來源不同而名稱相同的對象混合在一起的時候就不會出現歧義。一個 XML 名稱空間就是一個元素類型和屬性名的集合,這些元素類型和屬性用所屬 XML 名稱空間的惟一名稱來惟一標識。在 XML 文檔中,任何元素類型或屬性名都可使用兩段式的名稱,包括名稱空間名和元素或屬性名。

  Compound Document by Inclusion (CDI) 將來自多個名稱空間的 XML 標記組合到一個物理文檔中。已經存在一些標准,並將繼續出現新的標准,來描述單一名稱空間中的 XML 標記,XHtml、XForms、VoiceXML 和 MathML 是這類標准中最突出的例子,每一個都有自己的名稱空間。每種規范都關注豐富內容開發的某一方面。比如,XForms 專注於數據采集和提交,VoiceXML 突出語音,MathML 則強調數學符號的顯示。

  對於內容的作者而言,所有這些標准都非常有用,非常重要。但是,只有將來自這些標准的任意數量的元素結合起來,才具有真正的靈活性和強大能力來創建豐富文檔。要創建的文檔可能要求在 Web 浏覽器中顯示,並且包括輸入表單、可縮放的圖像以及一些數學符號 —— 所有這些都在同一個頁面中。XHtml、XForms、SVG 和 MathML 可分別滿足這些要求,因此可以將它們結合到一個多名稱空間的文檔中。

考慮一個簡單的例子:包含 XHtml 和 MathML 的復合文檔。清單 1 中名稱空間聲明後面的注釋與下面的說明編號相對應:


清單 1. 簡單的復合文檔

<?XML version="1.0" encoding="iso-8859-1"?> 
<xhtml:html XMLns:xhtml="http://www.w3.org/1999/xHtml"><!-- 1 --> 
 <xHtml:body> 
  <xhtml:h1>A Compound document</xHtml:h1> 
  <xhtml:p>A simple formula using MathML in XHTML.</xHtml:p> 
  <mathml:math XMLns:mathml="http://www.w3.org/1998/Math/MathML"><!-- 2 --> 
   <mathml:mrow> 
    <mathml:msqrt> 
     <mathml:mn>49</mathml:mn> 
    </mathml:msqrt> 
    <mathml:mo>=</mathml:mo> 
    <mathml:mn>7</mathml:mn> 
   </mathml:mrow> 
  </mathml:math> 
 </xHtml:body> 
</xhtml:Html> 

  XHTML 名稱空間聲明: 清單 1 中的每個 XHTML 元素用 xHtml: 名稱空間前綴限定。

  MathML 名稱空間聲明: 清單 1 中的每個 MathML 元素用 mathml: 前綴限定。

  圖 1 是 清單 1 中結合 XHtml 和 MathML 的簡單復合文檔的顯示結果。


圖 1. 呈現的簡單復合文檔
模型驅動的復合文檔開發

  查看原圖(大圖)


 

復合文檔可以由包含多個名稱空間的單一文檔組成,如 清單 1 那樣。這是一個 Compound Document by Inclusion(基於包含的復合文檔,CDI)。但是,復合文檔也可以由多個文檔組成,其中屬於特定名稱空間的一個文檔引用不同名稱空間的另一個單獨的文檔。比如,根文檔或者頂層文檔可能包含定義和格式化頁面的 XHTML 內容。通過使用 XHTML <object> 標記,這個 XHTML 父文檔可以引用屬於其他名稱空間的另一個文檔。可根據需要重復這一過程,以引入更多的文檔。根文檔加上這些單獨的、被引用的文檔就是一個 Compound Document by Reference(基於引用的復合文檔,CDR)。圖 2 是一個簡單的 CDR 文檔,其中 XHtml 根文檔包含對單獨的 SVG 子文檔的引用,SVG 文檔包含三個彩色圓的標記。


圖 2. 基於引用的復合文檔 
模型驅動的復合文檔開發

  查看原圖(大圖)

  當然,復合文檔也可以是 CDI 和 CDR 的混合體。

  模型驅動的開發

  縮寫形式

  CDI——Compound Document by Inclusion(基於包含的復合文檔)
CDR——Compound Document by Reference(基於引用的復合文檔)
DTD——Data Type Definition(數據類型定義)
EMF——Eclipse Modeling Framework(Eclipse 建模框架)
MathML——Mathematical Markup Language(數學標記語言)
MDA——Model Driven Architecture(模型驅動的體系架構)
MDD——Model Driven Development(模型驅動的開發)
MOF——Meta-Object Facility(元對象設施)
OMG——Object Management Group(對象管理組)
PIM——Platform Independent Model(平台獨立的模型)
PSM——Platform Specific Model(平台專用的模型)
SMIL—— Synchronized Multimedia Integration Language(同步多媒體集成語言)
SVG——Scalable Vector Graphics(可伸縮向量圖形)
UML——UnifIEd Modeling Language(統一建模語言)
VoiceXML——Voice eXtensible Markup Language(語音可擴展標記語言)
W3C——World Wide Web Consortium(萬維網聯盟)
X+V——XHTML + Voice profile(XHtml + Voice 配置文件)
XHtml——eXtensible HyperText Markup Language(可擴展超文本標記語言)
XMI——XML Model Interchange(XML 模型交換)
XML——eXtensible Markup Language(可擴展標記語言)
XUL——XML User interface Language(XML 用戶接口語言)


 

模型驅動的開發(MDD) 是更快地開發更好的軟件的一種方法和一組技術。對象管理組(OMG)給 MDD 概念貼上了模型驅動的體系架構(MDA)的標簽,並開發了一組標准來支持 MDD。過程從軟件開發需求階段早期的業務邏輯定義開始。在對業務邏輯進行抽象的基礎上,可使用統一建模語言(UML)對業務邏輯建模。得到的一個或多個模型形成了生成代碼獲得實現的基礎。

  使用 MDD 的一些理由包括:

  加快開發過程

  業務邏輯從平台中獨立出來

  如果業務邏輯變化,模型也要變化

  專門的技術應用於業務模型而不是軟件中

  降低軟件開發的成本

  模型可以用多種形式表示,如 UML、XML Model Interchange、Essential Meta Object Facility 和 W3C XML Schema。

  Eclipse 中模型驅動的開發

  Eclipse 是一種開放源代碼的工具集成平台,最常在 Java 開發環境中使用。作為一種工具集成平台,Eclipse 擁有多種編輯器和實用工具,並且還在不斷增加,其中之一就是 Eclipse Modeling Framework (EMF)。

  EMF 是 Eclipse Open Source Project 的一個工具子項目。EMF 是一種建模和數據集成框架,也是一個用於為 Eclipse 創建插件的代碼生成框架。EMF 使用 ECore 元語言描述模型,並為這些模型提供運行時支持。EMF 使用的 ECore 元語言以 OMG Meta Object Facility 2.0 (MOF) 的一個子集 Essential MOF (EMOF) 為基礎來描述模型。EMF 模型被持久化為 XML Model Interchange (XMI) 文檔。EMF 提供了查看和基於命令編輯模型的能力,以及按照 EMF 模型操縱和序列化實例文檔的基本編輯器。EMF 模型可從帶注釋的 Java 代碼、XML 文檔或 UML 模型產生。

EMF 是 Eclipse 中進行模型驅動開發的基礎。

  復合文檔加工

  可以用現有的 XML 編輯器創建和編輯 CDR,因為對其他文檔的引用使用如 <xhtml:object> 標記這樣的一般引用機制。但是 CDI 編輯器要求不僅僅知道如何驗證引用的單個文檔實例以便提供受控的編輯體驗。支持復合文檔的編輯器必須了解可把一個名稱空間的什麼標記作為孩子插入另一個名稱空間標記的詳細信息。這種跨名稱空間的聯系可以是雙向的和遞歸的。復合文檔配置文件為一組混合名稱空間定義了何種標記可以插入到其他何種標記下。目前已經存在幾種明確的復合文檔配置文件,如 XHTML/X+V(VoiceXML 的一個子集)和 XHtml/MathML/SVG。

  為了提供了一個具體的例子,不妨考慮 XHTML+XForms 復合文檔配置文件,它必須定義什麼 XForms 標記可以作為特定 XHTML 標記的孩子,反之亦然。對此配置文件的一個要求是 xhtml:div 元素可以包含 xforms:repeat 子元素,後者又可以擁有另一個 xHtml:div 元素作為孩子,這個元素又可以有一個 xforms:input 元素作為孩子,如清單 2 所示。


清單 2. XHtml 和 XForms 嵌套標記
<xHtml:div> 
 <xforms:repeat model="model_PostalAddress" 
  id="repeat_AddressLine_model_PostallAddress" 
  nodeset="/hrxml:PostalAddress/hrxml"DeliveryAddress/hrXML:AddressLine"> 
  <xHtml:div> 
   <xforms:input ref="." model="model_PostalAddress"> 
    <xforms:label>Address Line</xforms:label> 
   </xforms:input> 
  </xHtml:div> 
 </xforms:repeat> 
</xHtml:div> 

由於驗證和受控編輯器,標記的嵌套必須用 xsd:any 和 xsd:anyAttributes 之外的機制明確地定義,而為浏覽器編寫呈現代碼的用戶代理的實現者則需要更明確的詳細信息來無歧義地驗證和指導文檔的構造,建立處理引擎和呈現引擎。

  復合文檔加工用戶

  考慮復合文檔的創建和編輯加工時,必須要記住需要適應兩種用戶:復合文檔模式架構師和實例文檔創建者。

  復合文檔模式架構師需要有效地表達定義,即如何使用定義好的配置文件組合特定的名稱空間詞匯表。這是建立復合文檔配置文件實現的人。

  實例文檔創建者需要利用配置文件,但是對構造和編輯配置文件不感興趣。實例文檔創建者只想創建結構良好的、符合配置文件的有效文檔實例,更願意使用受控編輯器和基於結構的改正體驗。在這種體驗中,為編輯器提供受限制的選擇來根據配置文件檢查上下文敏感的選項。

  作為一種開放的建模技術,EMF 非常適合定義復合文檔配置文件。然後可以使用 EMF ECore 模型為文檔創建和序列化構建基於 Eclipse 的編輯器。

  復合文檔加工的模型驅動方法從配置文件中包含的每種功能名稱空間(XHTML、XForms、SVG 等等)的 Platform Independent Models (PIMs) 開始。PIM 是不考慮具體實現,只考慮建模對象目的 的高層抽象。PIM 可采用不同的形式,如 W3C XML Schema、RELAX NG、Schematron、MOF 或 UML 模型。一旦建立了所有配置文件模式的 PIM 模型,就可以轉化成 Platform Specific Models (PSMs),全部采用同一種標准類型。比如,PSM 可能全部是 XML Schema、UML 模型或 EMF ECore 模型。然後通過創建模型間的交叉模型引用來實現配置文件,交叉模型引用表示在那兒可以引用或者插入另一個名稱空間中的標記。比如,XHTML+XForms 配置文件需要定義,<xforms:model> 標記可以插入到 <xhtml:head> 標記中。圖 3 中,PSM XHtml+XForms 配置文件使用 UML 符號表示 XHtml PIM 模型中的 head 類和 XForms PIM 模型中的 model 類之間的聚合關系。

圖 3. 用 UML 表示的 PSM 交叉模型關系
模型驅動的復合文檔開發

  查看原圖(大圖)

  可以將 PSM 轉化成 EMF ECore 模型,後者可使用 EMF 提供的工具從 UML 模型或者 XML Schemas 創建而來。圖 3 所示的例子中,聚合關系變成了 PSM ECore 模型中的 EReference。建立這些模型和利用交叉模型引用實現配置文件是復合文檔模式架構師的職責。實現復合文檔配置文件的那些 PSM 模型然後被用於驅動受控的編輯器,實例文檔創建者用這種編輯器創建和編輯符合該配置文件的實例。圖 4 是從 PIM 到 PSM 再到序列化實例文檔的 XHtml+XForms+XML Events 配置文件。


圖 4. 模型驅動的復合文檔編輯器配置文件的創建
模型驅動的復合文檔開發

  查看原圖(大圖)

  模型驅動方法是創建特定名稱空間的功能 PIM 的有效方式,這些 PIM 可用於創建名稱空間組合的 PSM 來表示配置文件。可以在不同組合中重用 PIM 模型,組成需要的配置文件。使用 Eclipse EMF ECore 模型對於在 Compound XML Document Editor 中創建實例文檔,是一種非常理想的方式,可以直接編輯和序列化。

  Compound XML Document Editor

  Compound XML Document Editor(可從 IBM alphaWorks 下載)是一種動態編輯器框架,它使用 ECore 模型推動基於模型的復合文檔構造。

不需要編寫任何 Java 代碼,就可以向 Compound XML Document Editor 框架添加序列化為 XML 的任何類型的文檔。Compound XML Document Editor 使用模型資料庫,ECore 模型保存在其中。只要把 ECore 模型拖到 Compound XML Document Editor 模型資料庫中,並啟動 Compound XML Document Editor,就可以從這些 ECore 模型創建或動態地編輯實例文檔了。可以根據需要創建模型資料庫以容納任意多種模型和復合文檔配置文件。

  可以交換出單個模型,也可以在運行時交換出整個模型資料庫。此外,可以隨時修改 ECore 模型,並立即在編輯器和序列化實例文檔中反映出來。

  Compound XML Document Editor 提供了 XHTML、XForms、XML Events、SVG、SMIL、VoiceXML、XUL、MathML 和 XLink 的 ECore 模型。圖 5 顯示了以 XHtml 作為根文檔的默認模型資料庫中可用的配置文件組合,其中一個配置文件允許包含來自其他名稱空間的元素和屬性。


圖 5. 默認的模型資料庫
模型驅動的復合文檔開發

  查看原圖(大圖)

  通過限制允許的標記插入右擊選項,Compound XML Document Editor 使用底層的 EMF 模型提供受控的編輯體驗。圖 6 給出了一個例子:集成 PSM 模型的 EMF 編輯器嚴格遵守配置文件的要求,通過詢問 PSM 模型只允許遵循復合文檔配置文件的輸入。元素屬性表示為屬性表中的屬性。


圖 6. 受控的編輯
模型驅動的復合文檔開發

  查看原圖(大圖)

  創建文檔後,可以利用支持文檔中使用的復合文檔配置文件的可配置右鍵菜單選項,將它直接呈現在浏覽器中(如圖 7 所示)。


圖 7. 呈現選項
模型驅動的復合文檔開發

  查看原圖(大圖)

  圖 8 顯示了 Automobile Loss Reporting 基於在 X-Smiles 浏覽器中呈現的 ACORD 模式的一份保險單。


圖 8. X-Smiles 呈現的 XForm
模型驅動的復合文檔開發

  查看原圖(大圖)

  結束語

  Compound XML Document Editor 是一種基於標准的、模型驅動的復合文檔開發框架,支持動態的復合文檔創建和序列化。Compound XML Document Editor 利用 Model Driven Development 概念和 Eclipse EMF 幫助開發靈活的復合文檔以及定義它們的配置文件。

 

 


XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved