???缺乏教育管理信息系統的標準,造成了極大的數據冗余和資源浪費,難以實現資源共享與系統互操作.而僅僅對數據進行標準化,并不能根本解決不同系統之間互操作的問題.本文在參考美國學校互操作框架(SIF)的基礎上,提出了我國高等教育管理信息系統之間互操作的解決方案——教育管理信息系統互操作框架(EMIF).該方案旨在建立數據交換與互操作的標準,使框架內的所有系統都能輕松地進行信息交換與使用.
關鍵詞:教育管理信息系統 互操作 XML 規范
1 引言
???隨著CERNET在全國高校和各級教育管理部門的普及,高等教育管理的信息化建設也被推上了一個新的臺階,基于Internet技術的校園網使得教育管理打破了原有的封閉,獨立的管理模式,開始向互聯,開放的體系轉變.盡管原有獨立的教育管理信息系統曾為教育管理的科學化作出過突出貢獻,但由于不同時期,不同部門開發的教學,財務,人事,設備,科研等單項管理系統互相封閉,各自獨立運行,造成了極大的數據冗余和資源浪費,難以通過網絡實現信息共享.造成這種局面的一個重要原因就是缺乏教育管理信息系統的標準.由于信息技術的飛速發展和廣泛普及,缺乏標準而導致的一系列問題日益突出,成為了阻礙信息化發展的瓶頸.因此,教育管理信息系統的標準化研究也已經被提到了重要的日程上來.
2 面臨的問題
???教育管理信息系統的標準化首要解決的問題就是如何保證學習資源的共享與系統互操作.學習資源共享是指一個學習對象可被多個學習系統利用;系統互操作是指多個系統及組件之間能夠交換與使用彼此的信息.對于學習資源共享來說,數據標準化是前提.在這方面,早在1991年原國家教委就開始了此項研究,頒布了普通高等學校的一系列管理基本信息集,對教育管理的數據交換起到了基本保障作用.但不同部門不同廠家開發的管理系統之間的互操作問題,一直沒有得到很好的解決.
2.1 缺少管理信息系統互操作規范導致的后果
目前,由于缺乏管理信息系統之間互操作的規范,已經導致了如下一系列問題:
教育管理信息橫向交換與縱向傳輸的困難
由于缺乏數據交換的規范,學校內部不同部門開發的教育管理信息系統(簡稱EMIS)之間不能進行數據交換,而學校之間學校與上級管理部門之間也不能直接傳遞數據,導致了教育管理信息橫向交換與縱向傳輸的困難.
妨礙管理部門的科學決策
由于信息傳輸困難,不能對教育管理信息進行比較分析,各級各類教育管理部門就難以作出相應的正確決策,甚至還會對社會經濟發展的決策作出帶來不良影響.
重復建設,造成人力,資金的浪費
由于系統之間的信息資源不能共享,同樣的數據需要錄入多次,同樣的系統功能也需要重復開發,這就極大的浪費了人力與資金,而我國的教育投入本來就相對不高,這種浪費對教育的發展實為不利.
2.2 國內解決系統間互操作問題的兩種方案比較
雖然國內缺少系統互操作方面的規范,但為了解決教育管理信息系統之間互操作問題,目前國內還是出現了兩種解決方案,可是這兩種方案卻在很大程度上存在著不同弊端.
2.2.1 大一統的解決方案
這種方案在軟件的采購上采用一刀切的辦法,要求所有的學校的教育管理機構都采用由一個廠商開發的統一的軟件.這種方法在一定程度上保證了數據共享與數據上報的問題,但也存在以下弊端:
耗資巨大,對原有已開發比較成熟的系統是一種浪費;
我國地區發展不平衡,高校管理水平不一致,同類的軟件未必適合同類的學校;
使用同一廠商的軟件,不利于市場競爭機制的發揮,不利于軟件水平的提高;
阻礙學校個性化管理的體現.
2.2.2 開發接口程序的方案
這種方案是目前使用較多的一種解決辦法,雖然兩個系統之間沒有統一的數據規范,但通過為數據交互編寫專用腳本,以使被提取數據能轉變為其他程序的數據庫能理解的格式,這樣也可以實現數據的共享與交換,但是這種方案同樣存在諸多弊端:
軟件升級需重新編寫腳本,費時費錢
大多數廠商也確實提供了應用程序界面(API)存取數據,然而,API往往是專用接口并且要求專業知識,每次當軟件升級時,必須重新編寫腳本,這樣做既費時又費錢.
不適應多個軟件間的互操作
這種解決方案通常針對兩個軟件間的互操作,通常是由兩個廠商合作提供一致的數據接口,編寫點對點轉換數據的腳本.然而,如果增加第三個應用程序,也要使用它們的數據,就得分別編寫與這兩個程序間交互的腳本,如果再增加幾個,就會更加復雜.
2.3 建立教育管理信息系統互操作框架的設想的提出
缺少互操作規范,導致了上述問題,而目前的解決方案又不能很好的解決問題,那么,當務之急,就是建立一種教育管理信息系統之間互操作的規范.
那么,對系統之間的互操作建立規范具有可行性嗎 如果可行,應該如何操作呢 針對這些問題,我們進行了廣泛的調研,終于從美國的學校互操作框架SIF(Schools Interoperability Framework)中找到了答案.
SIF是由美國一些企業,組織發起的,針對美中學小學不同的學校管理軟件間互操作問題建立的一種解決方案.SIF的任務是為各種各樣的教育軟件提供互操作,也就是能夠使不同的軟件方便的進行數據共享,交換與更新.通過使用XML定義共同遵循的數據對象(如學生,教師)和數據傳輸協議,就可以方便的進行軟件間的互操作.如果學校使用的軟件都支持SIF和XML,那么學校就可以針對不同的任務選擇合適的應用程序.通過在一種應用程序中插接另一種應用程序模塊,還能創建更加靈活,強大的解決方案.利用XML這樣的中間格式,每個應用程序都能維護自己的格式,只要它簡便,精確地把數據轉變成XML格式,或由XML格式轉變成數據.
通過對SIF的互操作機制的深入研究,我們發現,這種解決思路完全適用于解決我國教育管理信息系統的互操作問題,除了在數據對象的定義方面,由于國情不同不能照搬之外,SIF的框架結構和報文規范都可以為我們提供極大的參考.
參照學校互操作框架(SIF)解決問題的思路,我們提出了建立我國教育管理信息系統互操作框架的設想.
3 教育管理信息系統互操作框架的描述
教育管理信息系統互操作框架(Education Management Information Interoperability Framework),簡稱EMIF,是我們針對教育管理信息系統互操作問題提出的一個標準化的解決方案.該方案是通過制定EMIF規范,根據規范建立教育管理信息系統的互操作框架,并通過規范化的操作,實現教育管理信息系統之間的數據交換.
那么,互操作框架為什么能夠解決不同系統間數據交換的問題 它看起來是什么樣的 它的內部機制如何 這一框架應該如何建立呢 這些就是下文將要回答的問題.
3.1 XML在EMIF中的作用
通常,數據存儲格式不同的系統之間的數據交換需要編寫腳本來實現,那是因為沒有一種與平臺無關的,格式獨立的數據存儲方式存在.XML語言恰恰正是這樣一種語言,不但與平臺無關,而且還可以定制行業領域的標簽,非常適合作為一種獨立的數據交換格式.利用XML的這些優點,可以建立教育管理信息系統的XML數據交換格式,數據存儲格式不同的系統之間要進行數據交換,只要先轉換成符合EMIF的XML格式,就可以進行數據交換了.不同的應用系統要做的就是如何將自己的數據轉換成符合EMIF的XML數據,或將XML數據轉化為自己的數據.
3.2 EMIF的體系結構
EMIF是一種分布式聯網系統,它的基本結構是通過一臺區域集成服務器(ZIS)將一個區域內的各個管理子系統聯系起來.各個子系統都創建各自的代理程序作為系統與ZIS的接口,代理程序之間并不直接通信,而是通過ZIS間接通信,ZIS是所有代理程序的集成點.ZIS和代理程序都使用EMIF規定的XML詞匯,作為數據傳輸與互操作的語言.
舉一個典型事例,在一個學校內,SIF使得不同廠商開發的應用程序彼此相連,這些應用程序包括學生管理系統,教務管理系統,人事管理系統,圖書館管理系統等,每個程序都有一個廠商提供的接口程序叫做"代理".由于同一個學校共同使用這些應用程序,因此使這些程序成為一個邏輯上實體有著非常重要的意義.這個實體看作是由一個ZIS控制下的一個"區域(Zone)"(見圖1).EMIF可以有多個區域,各個區域的ZIS互聯可以使不同區域間實現互操作.
盡管EMIF可以有不同的區域,但大量應用程序之間需要共享數據這一點卻是相同的.EMIF在執行上不考慮它的組成成員的復雜性,不管有多少個應用程序,都是由一臺區域集成服務器(Zone Integration Server ,簡稱ZIS)將各個應用程序相連.每個應用程序需要創建各自的代理程序,用來與ZIS通信.ZIS和代理都支持EMIF規定的XML詞匯和語法,通過一種叫做"報文"的XML文檔的傳遞進行數據交換.
3.3 EMIF互操作機制
EMIF內各個子系統之間的互操作主要實現兩類數據交換的功能:
一個子系統獲取另一個子系統的數據.
一個子系統的數據變化時,其他共享其數據的子系統的相應數據也得到更新.
EMIF根據這兩類功能創建了兩類數據傳遞模式.一個是"請求與應答模式",想要獲取數據的系統向ZIS發出請求報文,ZIS傳遞給可以提供數據的系統,該系統向ZIS發回相應的應答報文,ZIS再將其返回給數據的請求者.另一個是"發布與預約模式",一個系統向ZIS發出"預約"報文,預約某數據的更新信息,當被預約的數據所在系統數據更新時,該系統要向ZIS發布"事件"報文,ZIS迅速將事件報文發送給預約者,從而實現數據的迅速更新.
事實上,并不是任何子系統都可以隨意獲得另一個子系統的數據及其更新信息,每個系統在加入EMIF時都需要經過注冊,通過發出"注冊"報文,注冊自己在該區域惟一的標識符(ID).如果決定將自己的數據給別人共享,還必須發出"提供"報文,聲明自己可提供的數據.
可見,EMIF需要定義多種類型的報文,除了上面涉及到的報文,還要定義確認報文是否接受的"通知"報文,定義取消注冊的報文,取消提供數據的報文.還有一種叫做"系統控制"的報文,該報文與別的報文不同,它本身并不攜帶數據信息,只包含子報文,這些子報文用來表示報文的發出者是否處于工作狀態,是否可以處理報文等,以便接收者控制是否向它繼續發送報文.EMIF定義的基本報文共11種.
由于不同類型報文的處理是不同的,因此EMIF必須定義報文處理協議,以使不同報文表達的含義能夠被正確的理解與反饋.同時,為了保證報文傳遞的安全性,身份驗證,加密保護,訪問權限控制等手段的運用也是EMIF的重要內容.作為報文的承載內容的數據對象和事件對象的規定,以及報文的XML格式的規定,更是EMIF規范中不可或缺的組成部分.
綜上所述,完整的EMIF規范應該包含以上涉及的所有內容,主要可以分為體系結構規范,報文規范和數據規范.
3.4 EMIF的實施辦法
要通過EMIF實現教育管理信息系統的互操作,需要開展以下工作:
(1)制定一整套教育管理互操作規范,包括EMIF體系結構,報文規范和數據規范.
(2)將一個區域內的多個管理系統共同組成一個EMIF區域,開發一個作為中介的區域集成服務系統(ZIS).
(3)開發各個應用程序的代理程序,代理的功能是能夠將各自的數據對象轉換為EMIF定義的XML報文格式,并能夠讀懂XML報文,根據報文內容更新數據.
完成這些工作之后,才能按照EMIF規范進行系統之間的互操作.由此可見,制定規范還只是解決互操作問題的第一步.目前我們的工作就是首先制定這樣一個規范.
那么EMIF規范究竟應該怎樣制定呢 下面我們將分別就EMIF體系結構規范,報文規范和數據規范的內容來闡述我們對EMIF規范內容的設想.
4 EMIF體系結構規范
根據前面對EMIF體系結構的分析可以看出,EMIF的體系結構的實質應該是一個開放性的概念模型.由一臺ZIS將一個區域內的系統聯網,通過ZIS與各子系統的代理之間的報文傳遞實現數據交換.各個EMIF區域之間的ZIS聯網,通過ZIS之間報文的傳遞,實現區域間數據的交換.經過這樣的擴展,EMIF的范圍可以小到學校,大到省市,甚至國家,只要遵循EMIF的規定,都可以成為框架的一部分,實現網絡內數據的共享與互操作.
4.1 EMIF框架內的子系統劃分
雖然我們說過EMIF不去考慮組成一個區域的子系統究竟有哪些,但對可能存在的子系統做出基本的劃分還是很有必要的.由于EMIF的最終目的是為了實現數據交換,那么統一的XML數據對象格式是交換的前提,而要確定統一數據對象,首先要確定數據對象的種類,這就需要先按照功能對子系統進行分類,進而確定每類子系統使用的主要的數據對象.另外,子系統的劃分有利于形成制定XML數據規范的工作組,同一類子系統的創建者可以成立一個工作組,制定相關的數據對象.
參考SIF工作組的劃分,同時在對我國EMIS系統組成的調研基礎上,我們初步提出了一個高等學校EMIS的體
系結構參考模型(見圖2),作為學校區域內的EMIF子系統劃分的基礎.這種分類是否科學還有待繼續討論.
4.2 EMIF的基本概念
EMIF涉及的基本概念主要包括:數據對象,事件對象的概念,數據傳輸的模式,加密保護,身份驗證,訪問控制等等.
4.2.1 對象與報文的概念
在EMIF中,"對象"與"報文"是兩個最基本的概念,這也是EMIF的核心.
"對象"包括數據對象和事件對象.EMIF中可以交換的數據是通過一系列數據對象進行定義的.數據對象是定義可由一個或多個應用程序管理的信息語義的模式.例如,StudentPersonal(學生個人數據),StudentschoolEnrollment(學生入學注冊),以及School(學校)都是數據對象.這些數據對象通過XML方式表示.事件對象簡稱"事件",它表示對數據對象所定義信息的更改.例如,StudentAdd/Delet/Change(學生添加/刪除/更改)事件可以是作用于StudentPersonal數據的動作,StudentschoolEnrollmentAdd/Delet/Change是StudentschoolEnrollment對象可能發生的動作,SchoolAdd/Delet/Change事件作用于School對象,以此類推.
"報文"報文可以看作是數據對象和事件對象的載體,數據對象和事件對象必須放在報文中才能夠傳遞.報文同樣使用XML元素和屬性來表示.
4.2.2 數據傳輸的模式
EMIF框架內系統之間的互操作的目的是各子系統能夠交換與使用彼此的數據,那么一方面是獲得對方的數據,另一方面是獲得數據后,需要隨時得到數據的更新信息,因此,EMIF的數據傳輸相應就產生了以下兩種模式.
(1)請求與應答模式
當一個應用程序(即"請求者")想要從一個數據對象那里收集數據時,首先需要發送一個請求報文給ZIS.這個請求中可以指定數據的提供者(即某個應用程序服務器),也可以不指定.如果報文中沒有指定提供者,那么ZIS也可以為這一數據請求尋找默認的提供者.任何應用程序服務器都可以成為數據的提供者,但首先必須向ZIS進行登記.而一個數據對象只能有一個數據提供者,因此,先登記的程序可以搶先成為某數據提供者.想要提供數據的應用程序代理首先使用登記報文(EMIF-Register)在ZIS中登記,得到一個統一的標識符,然后使用提供報文(EMIF-Provide),將自己可以提供的數據對象告知ZIS,經過ZIS的確認,可以成為該數據的提供者.ZIS在收到數據請求時,根據已有的登記可以迅速找到數據的提供者,將數據請求發送給數據提供者.提供者也要將應答報文(EMIF-Response)返回給ZIS,然后再由ZIS將應答報文傳遞給最初發出數據請求的應用程序.
舉一個例子,假定一個學校內的EMIF框架中包含學生管理系統,圖書館管理系統以及教學管理系統,如果后兩個系統需要從前一個系統獲取學生信息的數據,那么他們三者之間的報文傳遞過程是這樣的(見圖3):
①登記:各系統的代理向ZIS發出登記報文,進行注冊,具有了各自的ID.
②代理3向ZIS發出"提供"報文,成為某數據對象的提供者(Provider), Provider是該數據對象默認的應答者(Responder).
③代理1和代理2 分別發出各自的請求報文,請求獲得某數據對象.
④ZIS根據已登記的提供者名單,找到數據的提供
者為代理3,將請求報文發送給該代理3.
⑤代理3分別根據兩個數據請求報文的內容,返回相應的兩個應答報文,送回ZIS,ZIS再將其轉發給相應的數據請求者.
(2)發布與預約模式
代理程序可以通過發布關于EMIF數據對象的添加,改變,刪除的事件報文來傳遞數據的更新信息.如果其他應用程序需要隨時得到這些更新信息,就需要由代理程序進行預約.預約的方法就是發出一個或多個預約報文(EMIF-Subscribe)給ZIS.每當應用程序發布事件后,ZIS都會將這一事件按照預約清單將這一事件發送給每個預約程序.這一更新數據的過程稱為事件報告生成.
在上例中,數據更新的過程是這樣的(見圖4):
①代理1和代理2分別預約代理3中的某個數據對象;
②代理3中的數據對象的值發生改變時,會向ZIS發出一個表示數據變化的事件報文(EMIF-Event).
③ZIS根據數據的預約情況將該事件報文傳遞給相應的預約者.
4.2.3 安全保障策略
EMIF的安全保障策略用來保護報文傳遞的安全,提供數據的訪問權限等.主要有四個方面:加密保護(Encryption),身份驗證(Authentication),有效性驗證(Validation),以及訪問控制(Access Control).
加密保護提供了這樣一種機制:只有特定的發送者和接收者可以看到報文的內容.EMIF為代理提供的加密途徑是:代理在報文中告訴ZIS,它與ZIS之間通信要達到何種加密級別,ZIS的執行必須保證該報文的傳遞途徑必須達到這種加密級別,而不去考慮使用何種加密方式.加密級別分為5個等級,分別規定各級別的加密要求.
身份驗證的作用主要是確保報文的作者是實際的作者,它可以避免區域外的代理偽造報文來改變EMIF數據.為代理提供的身份驗證的途徑與加密保護的途徑類似,同樣是在報文中指出需要達到的身份驗證級別,由ZIS確保該驗證級別的實現.
EMIF報文的有效性驗證是保證報文能夠正確識別的前提.有效的報文是符合EMIF報文規范的XML文檔.由于EMIF報文規范會隨著報文種類的增加以及報文內容的改變做出新的調整,發布新的版本,因此代理程序和ZIS必須在報文中標識出使用報文規范的版本.我們計劃在EMIF規范的1.0版本中,根據EMIF報文規范的XML 文檔類型定義(DTD)進行有效性驗證.
EMIF還將對不同應用程序的訪問權限進行控制.例如,一個EMIF管理員可以決定哪些應用程序可以加入EMIF,它們可以提供或請求哪些數據對象,可以發布或預約哪些事件.
這些策略的具體實現方法會在EMIF的報文規范中詳細說明.
4.3 EMIF體系結構
這一部分應該主要闡明EMIF的基本結構,對代理和ZIS命名的規定,數據對象,報文標識符的規定,代理應該具備的功能以及ZIS應該具備的功能等等.
EMIF的基本結構,前文已經闡述的很多,這里不再贅述.
對代理和ZIS命名的要求是:對于ZIS,要反映地區的名稱,對于代理,既要反映地區的名稱,又要反映應用程序的功能.無論數據對象還是報文,必須有一個惟一的標識符來指代.我們將在規范中規定產生表示符的具體方法.
代理的功能應該主要包括:與ZIS建立連接,向ZIS提供事件信息,對數據請求進行反饋,根據事件報文更新系統數據,支持身份驗證與加密保護.ZIS的基本功能主要應該包括:對代理或其他ZIS進行注冊,建立訪問控制列表,建立提供者與預約者數據庫,提供報文隊列服務等.
5 EMIF報文規范
如上文所述,系統之間的互操作是通過報文的傳遞來實現的.這就涉及到兩個方面的問題:一是報文如何傳遞,二是報文如何制作.關于報文傳遞,需要制定報文處理協議,即對不同的報文,應該執行怎樣的處理程序;關于報文如何制作,需要規定報文的格式.
5.1 報文處理協議
報文處理協議是對報文傳遞過程中對報文進行處理的規則,EMIF框架內的ZIS和所有應用程序都應該遵循這些協議.這些協議主要有:
資格驗證:剛收到報文時,首先要驗證該代理是否有獲得報文所要求數據的資格.
注冊:任何一個代理在使用EMIF前都要先進行注冊,默認的傳輸協議是HTTP協議,如果該代理想要使用其他傳輸協議,也可在注冊報文中聲明,ZIS將在與之通信時使用所需協議.
數據提供聲明:一個代理要想讓某個數據對象為其他程序所共享,需要向ZIS發出提供報文(EMIF_Provide),如果想取消該數據對象的共享,可以使用取消提供報文(EMIF_Unprovide).
數據預約:如果一個代理需要得到某個數據對象隨時更新的信息,則首先要向ZIS發出預約報文,登記預約的數據對象.如果要取消預約,則使用取消預約報文(EMIF_Unsubscription).
事件報告:如果一個代理程序的某一數據對象發生了變化,需要向ZIS發出事件報文(EMIF_Event)表明該對象的變化,這樣ZIS才可以根據預約情況及時將該報文傳遞給需要知道這一變化的代理程序.
請求協議:代理程序可以通過請求報文(EMIF_Request)向ZIS提出對某種信息的索取需要,如果該報文中指明了對方代理的標識符,則ZIS可以在驗證資格通過后將報文傳遞給對方代理,如果報文中并未指出代理的標識符,則ZIS可以根據數據對象進行檢索,查出可提供該數據的代理,然后以同樣的方式進行處理.
應答協議:一旦一個請求被送到了相應的代理那里,這個代理首先要檢查報文中的EMIF版本信息(EMIF_Version元素) 和最大緩存值( EMIF_MaxBufferSize元素)的信息.如果該代理不能返回以該EMIF版本描述的數據對象,那么它將立即返回一個包含錯誤信息(EMIF_Error 元素)的通知報文(EMIF_Ack),以通知請求方.同樣,如果該代理要返回的數據對象的大小超過了請求方所能接納的最大值(即EMIF_MaxBufferSize的值),也會用通知報文進行通知.
5.2 報文格式規范
報文格式規范是對各種報文XML文檔的DTD的規定,關于DTD的內容將在數據規范中進行介紹.在EMIF中報文的種類繁多,在系統互操作中擔負著重要的使命,其中最基本的報文有11個,它們是EMIF-Ack,EMIF-Event,EMIF-Provide,EMIF-Register,EMIF-Request,EMIF-Response,EMIF-Subscribe,EMIF-SystemControl,EMIF-Unprovide,EMIF-Unregister,EMIF-Unsubscribe.任何報文都提供報文的名稱空間,報文名稱,報文來源,發送時間等.
通過使用這些報文來進行上文所介紹的數據請求與獲取,數據更新等操作.報文SIF_Event可以用來傳遞事件對象,SIF-Ack用來通知一個請求是否成功執行, SIF-Provide用來公布可提供的數據對象,SIF-Register向ZIS進行注冊登記,SIF-Request用來向一個代理程序發出獲取數據對象信息的請求,SIF-Response用來對 SIF-Request報文進行回復,SIF-Subscribe用來預約事件對象. EMIF-SystemControl 用來控制一個EMIF節點和另一個EMIF節點的數據流.EMIF-Unprovide 與EMIF-Provide作用相反,用來取消可提供的數據對象.EMIF-Unregister 用來取消注冊.EMIF-Unsubscribe 用來取消預約.
6 EMIF數據規范
我們知道,EMIF報文中承載的主要內容是數據對象和事件對象,那么數據以何種形式包裝,數據對象的結構如何,就是報文規范必須明確定義的內容了.雖然我們定義的數據對象是任何EMIF組件(包括ZIS和應用程序及其代理)都可以使用的,但是,一般情況是,某類應用程序主要使用某些數據.因此,根據應用程序的不同功能,對數據對象進行分類也是很有必要的.當然,對于應用程序來說,選擇使用哪些數據對象是它們自己的自由.
我們初步把數據對象分為十大類:學生信息,教職工信息,學習對象信息(教材,課件等軟件資源),基建信息,科研信息,財務信息,校產信息,學校綜合信息,其他信息.
然后要做的是選出每一類中典型的數據對象,對每個數據對象的Schema進行定義.
一般來說,Schema描述了XML文件的數據模型,即在有效的XML文件中的標記和字符數據的排列.Schema用兩種辦法建立數據模型:第一,為文件建立內容模型,即定義元素的順序和元素的嵌套;第二,建立文件數據的數據類型.目前有兩種建立數據模型的辦法,一種是DTD的方式,這是一種與XML語法規則不同的方式,另一種是XML Schema的方式,這種方式還是使用XML的語法.前者相對簡潔,但后者的可擴展性更強,是今后發展的趨勢.經比較,我們在目前還是使用DTD的方式,如果需要,以后還可以轉換成XML Schema的方式.
在本規范中,并不是直接給出每個數據對象的DTD,而是用簡單易懂的表格表示數據對象的Schema.
在制定數據對象規范時,必須堅持以下幾個原則:
(1)選擇出的數據對象具有代表性,在數據共享方面有現實意義.
(2)數據對象的Schema既要有很強的可操作性,又要有很好的擴展性.
(3)數據對象的選擇既要符合我國國情,又要有國際通用性.
(4)一個數據對象的確定需要經過多方審定,保證其實用性.
可見,EMIF的數據規范的制定是一項很大的工程,需要從事教育管理系統應用與開發的各方人士的共同努力.美國EMIF的數據規范就是由上百家公司,協會,社會團體組織等經過幾年的研究與實踐共同制定的.
目前,我們對EMIF數據規范的建立還處在起步階段,還有待更多團體與個人參與到規范的制定中來.
7 結論
教育管理信息系統互操作框架的建立,對于教育領域內的資源共享,教育管理信息的獲取,教育資源的節約,乃至教育的發展,社會的進步,都將有廣泛而深遠的意義.然而,從設想到實施還有一段很長的路要走,我們希望有更多的企業,學校,組織加入到EMIF規范的制定中來,參與EMIF區域的搭建,共同實現不同教育管理系統之間的數據共享與交換.
有人對SIF的出現曾經評論道:"SIF的出現,將掀起一場信息存儲,訪問,更新,傳遞方式的革命,并將明顯減輕學校人力資源和財政管理的負擔",我們希望,EMIF作為SIF在中國本地化的產物,也能擔負歷史的重任,為教育管理信息系統的發展提供一個新的空間.