• 沒有找到結果。

Access Control in XML-以醫院病歷為例

N/A
N/A
Protected

Academic year: 2021

Share "Access Control in XML-以醫院病歷為例"

Copied!
61
0
0

加載中.... (立即查看全文)

全文

(1)

逢甲大學資訊工程學系專題

Access Control In XML-

以醫院病歷為例

學生:吳明晃(四丙)

陳明德(四丙)

指導教授:李維斌

中華民國九十一年十二月九日

(2)

~目錄~ Chapter 1 前言… 1-1 研究動機………....5 1-2 研究目標………...6 Chapter 2 存取控制 2-1 Access Control 概述……….7

2-2 Access Control Model………9

Chapter 3 XML 技術介紹 3-1 DOM 物件介紹………...14 3-1-1 載入 XML 文件………14 3-1-2 建立 Document 物件……….14 3-1-3 NodeList 介面………14 3-1-4 Node 介面……….15 3-1-5 選取單一節點………18 3-1-6 選取多個節點………18 3-1-7 運用元素取得節點………19 3-1-8 新增節點………20 3-1-9 DOMDocument 物件變數 CreatElement 方法………21 3-1-10 DOMDocument 物件變數 Creat3TextNode 方法………...21 3-1-11 Node 物件 appChild 方法………22

3-1-12 Node 物件 insertBefore 方法與 insertAfter 方法………….22

3-1-13 刪除節點………25 3-1-14 利用 XPATH 刪除………...26 3-1-15 節點的屬性刪除新增與取得……….28 3-1-16 屬性刪除……….28 3-2 SAX 介紹 3-2-1 SAX 結構………...31 3-2-2 SAX 機制………...31 3-2-3 SAX 優點與缺點………...32

(3)

3-2-4 DOM 優點與缺點……….33 Chapter 4 系統設計 4-1 系統概述………35 4-2 系統檔案規劃………36 4-2-1 醫生個人資料檔案………36 4-2-2 病人病例與個人資料檔案規劃………38 4-3 系統架構………41 4-4 系統運作流程………44 4-5 系統檔案統計………50 Chapter 5 結論 5-1 專題分工………51 5-2 專題遭遇之困難與解決………52 5-3 組員心得………57 5-4 參考文獻………60

(4)

~圖錄~ 圖 2-1……..subject 圖……….8 圖 2-2 ……..object 圖………..8 圖 2-3……...RBAC 階層圖 ……….12 圖 2-4………ROLE 分配圖 I………12 圖 2-5………ROLE 分配圖 II………...13 圖 2-6………ROLE 分配圖 III………..13 圖 3-1……..DOM 樹狀圖………..17 圖 3-2…….利用 getElementByTag 方法………...20 圖 3-3……..將元素新增至特定元素前………....23 圖 3-4……..新增元素節點………24 圖 3-5……...節點刪除………...26 圖 3-6……...利用 XPATH 刪除節點……….27 圖 3-7………屬性的取得………..29 圖 3-8………屬性的刪除………..30 圖 4-1………employee.dtd……….37 圖 4-2………patient.dtd……….39 圖 4-3………case.dtd……….41 圖 4-4………一般架構圖………..42 圖 4-5………目前架構圖………..43 圖 4-6………登入首頁………..44 圖 4-7………輸入 ID………45 圖 4-8………輸入驗證碼………..45 圖 4-9-1…….總覽………..45 圖 4-9-2……..搜尋……….46 圖 4-10………查詢病例……….46 圖 4-11………MARY 醫生查詢 P001 病例畫面………..47 圖 4-12………AMY 醫生查詢 P0011 病例畫面………...47 圖 4-13……….流程圖………49

(5)

圖 5-1………分工圖………...51 圖 5-2………DOM 版本涵蓋圖……….54 ~表錄~ 表 3-1………Node 介面屬性圖………15 表 3-2……….NodeType 名稱與傳回值圖………..16 表 5-1………DOM VS SAX……….56

(6)

Chapter 1 前 言

在 1969 年,全球資訊網協會(World Wids Web Consortium,簡稱

W3C),利用 SGML 的彈性與其強大功能,並結合廣為使用的 HTML 開始 設計可擴展標記語言(extensible markup language),這種語言稱為 XML。XML 主要是根據 SGML 的規格再加以簡化,可以說是 SGML 的子 集合,在 SGML 之下因為他的彈性及多樣性,使得 SGML 的 parser 難 以設計,相對於 XML 因為是 SGML 的簡化延伸版,XML 在 parser 上的 設計就顯的較容易,因為 XML 是 SGML 的子集合,所以 XML 也同時具 有向上相容性,這使得 XML 在發展上得到很大助力,因為企業不需要 再花大量成本去將 SGML 轉換成 XML 資料,使得企業界可以很樂意的 接受 XML 的問世。 1998 年二月,W3C 正式將 XML1.0 規格正式成為推薦標準 (Recommendation)。 隨著網路應用發達,一個好的標記語言更顯的重要,XML 未來將 是運用在網路上的資料傳輸重要的一角,XML 的 TAG 可以由使用者自 訂,所以 XML 的 TAG 可以是有意義的,再加上 XML 同時具有跨平台及 跨語言兩種能力,以此 XML 為資料交換的媒介,可以自由自在的在任 何平台上攸遊,這項特性將是決定未來 XML 成為王者的雄厚資本,未 來資訊發展一定是伴隨著網路,在網路上最重要的不同的地方可以透 過網路溝通,而 XML 可以適時扮演資訊溝通的媒介,SOAP 這是個很 重要的發展,它讓 XML 可以是個網路協定,在這種種的特點下,XML 已經蠢蠢欲動要躍上標記語言的王者寶座上。

1-1 研究動機

(7)

正如前面所提的,XML 將來的發展一直受各界注意,但是雖然 XML 從 1998 年至今也過了不少年頭,但是它的完成度並沒有完全成熟, 很多方向都有待研究開發,大三在找專題時決定坐網路相關的方向, 然後找了李維斌老師做專題,一開始要選擇題目時真是傷透了腦筋, 再跟老師多次的討論後覺得 XML 是個不錯有潛力的發展方向,於是決 定以 XML 為發展方向,但是 XML 的領域相當廣,在老師建議以及組員 去蒐集資料,88 年有兩組學長研究 XML 他們的重點放在利用 DSO 載 入 XML 檔案及利用 XSLT 建構網站資訊,90 年有一組學長做的是 XML 與 SQL server 結合,旨在將資料庫整合 XML 資料,當時 XML 的 API DOM 跟 SAX 尚未問世普及,所以對於 XML 資料 TAG 的操作較不靈活,所 以現在有這些 API 我們想利用它去做 access control 去玩 XML 的 pareser 操控 TAG。

1-2 研究目標

ACCESS CONTROL 在各領域發展可以算是相當健全的,但是我們發 現目前的 XML 因為還處於成長階段,現在最多應用 XML 的地方大部分 還是在用在存放網站資料,將網站上的資料以 XML 的格式存放,用 XSLT 搭配 HTML 等語言去建構一個網站,但是幾乎很少看到有人利用 access control 的精神去控制 XML,在 ASP,PHP 等語言作 access control 可以說是司空見慣的,但是 XML 上的 access contrl 卻很少 人去做,目前只有少數幾篇國外論文有相關研究理論,國內的 XML 書 籍也沒有提到這方面的做法,但是未來將成為標準的 XML 確實也有這 方面的需求,所以我們這組的目的是希望將 access control 應用在 XML 上面,利用 DOM 跟 SAX 去操控 XML 資料的 TAG,然後以簡單的醫 院醫生、病人、病例間的階層關係去表達 access control 在 XML 上 的可行性,並且進而測試專為 XML 設計的 API:DOM&SAX 的功能測試, 這兩個 API 在 XML 發展上是很重要的一個里程碑,但是同樣的 DOM& SAX 跟 XML 一樣還是在成長中的小孩,我們在這個時候研究 access control 的可行性,在 XML 還在發展中的階段去發現他無限的潛能,

(8)

我們不求能發展出什麼驚人的成果,但是希望藉由這次專題,培養研 究新東西的經驗,及增加對 XML 的認識。

Chapter 2 Access Control

2-1 Access Control 概述

Access control 是一種安全機制,用來規定 USER 與 SYSTEM 間 的互動關係,還有 USER 與 RESOURCE 間的從屬關係,Access control 提供一個保護機制,使得 SYSTEM RESOURCE 可以透過一個認證的程序 保護過濾想要 access resource 的 user,透過驗證程序 USER 必須要 擁有特定的權力階級才能通過驗證。

而 Access Control 的機制最主要的就是定義 SUBJECT 與 OBJECT 間的相互關係,而 SUBJECT 與 OBJECT 又是指什麼呢,簡單的歸納來 說:

¾ SUBJECT:SUBJECT 是主動的實體,他會對系統提出對於 OBJECT 的 access 要求動作或著是 OBJECT 中的資訊,

SUBJECT 可以是 users,programs,process。舉例 來說:當一個 progarm 去請求一個 file 時,program 就是一個 SUBJECT,而 file 就是一個 OBJECT。 ¾ OBJECT:OBJECT 相對於 SUBJECT 他就是個被動的實體,而且 是內涵資訊的實體,OBJECT 可以是 computer, database,file,directory 等。舉例來說:當你要 去調閱資料庫中的資訊時,你本身就是個主動的 SUBJECT,而被要求查詢的 database 就是個被動的 OBJECT。 下圖是表示 SUBJECT 與 OBJECT 間的範疇與關係圖:

(9)
(10)

圖 2-2 OBJECT

2-2 ACCESS CONTROL MODELS

Access control 雖然是個安全機制,但是經過前人的研究,我 們可以歸納出幾個主要的 model,這些主要的 model 我們可以分成三 類,敘述如下:

¾ DAC:

這類型的 model 全名是 Discretionary Access Control, 主要就是一個 SUBJECT(A)被允許賦予他人任意類型的權限去 access SUBJECT(A)他所擁有的 OBJECCTS。舉例來說:一個某 部門的 manager,他擁有一些 data,那麼他就有完全的自主 權決定這些 data 他要給什麼人看,給什麼人修改等動作。 而最主要的做法是用 ACL(Access Control List),支配 權在於擁有者,由 OS 來執行。

但是這個 model 有個缺點,舉例來說:A 可以分享他電腦 裡的硬碟給 B,B 就可以在 A 的硬碟裡抓取他的 MP3 或電影等, 但是 A 又可以把總經理擋在他的 share 名單之外,這樣

(11)

manager 就不知道 A 跟 B 再上班時間偷懶濫用公物!這就是所 有權全部集中在擁有者身上的缺點。

¾ MAC:

他的全名是 Mandatory Access Control,相對於 DAC 的 無條件式,MAC 就是有限制性的 model,data 的擁有者他所被 賦予的權力雖然也不少但是相較於 DAC model 之下的權能就 少了很多,在 MAC model 模式下,資源擁有者一樣可以設定 他所擁有的資源權限給他人,但是最後的系統 ADM 卻擁有最 後的決定權,此法可以防治資源擁有者任意的發放權限。 這個模式的運作方式是利用 Security label,每個使用 者都被賦予一個通行證,這個通行證裡記載了該 user 所屬的 層級,而每個 object 也將被分類,當使用者進入系統將會被 要求檢查通行證,然後看他要求 access 的資訊機密等級是否 屬於該 user 層級所能觀看的,如果符合則予以通行,不符合 則被拒絕,Security label 則記載所有 object 的機密等級相 關資訊。

¾ Nondiscretionary:

他又被稱為 RBAC(Role Based Access Control),這個 model 主要是整個系統有個中心的 ADM,而這個 ADM 必須負責 所有的 SUBJECT 與 OBJECT 間的從屬關係,而不是像 DAC,MAC 是由資源擁有者設定,而 SUBJECT 與 OBJECT 的從屬關係可依 據下列三種方式分類: „ Task Based: 根據公司賦予 user 的任務,根據公司分派的任務給 予 user 不同的權限。 „ Lattice Based: 根據 user 所屬的安全層級,此法主要的特點是提供 所有 SUBJECT 與 OBJECT 的 upper bound 跟 lower bound

(12)

的關係,舉例來說:有五級權限由低到高 1~5,如果 userA 被分類成 4 層級的身分,那麼他的 upper bound 就是 4, 而 lower bound 就是 1,user 可以在這個範圍內行使職權。 „ Role Based:

(這是本次專題主要使用的 model)。

何謂 Role:一種語意上的結構是整個 model 的基礎,是將 權力與責任實體化,Role 定義了哪些資源可以使用哪些 資源被使用了。

何謂 ROLE 跟 PERMISSION 的結合:在 RBAC 中,其每一 個 ROLE 都會有自己的 PERMISSION,根據 ROLE 在組織架 構中,所扮演的職位,定義該職位的行為。 他有幾個特點敘述如下: ‹ 根據 user 在整個公司中所扮演的角色,最少的特權, 定義 user 扮演的 role 在任務中做的動作而已,不會 造成 role 的特權過多或權力不清。 ‹ 責任分擔,role 和 role 之間可以有繼承的關係,稱 role-role relation,而互斥的 role,同一個 user 是不被允許同時擁有的,利用這些互斥的 role 共同 完成一件工作責任不會集中在一個 role 之上,可以 有更好的 security policy。 ‹ 資料的抽象化,有別於一般的 write,read,modify 等傳統 permission 而是用更詳細的動作描述,像是 借和貸兩種抽象的動作被用在一個帳戶裡面。 ‹ 利於 adm 修改架構,因為用 role 定義關係,權限隨 著人的職位狀態有所改變,而 adm 只需要修改該 user 的職位所扮演的 role 即可,對於系統的維護與增建 相當方便。

(13)

在各個 RBAC MODEL 中,利用繼承關係,RBAC0 MODEL 可以由 RBAC1 跟 RBAC2 這兩個 MODEL 繼承其 PERMISSION 與 ROLE 與各個條件的限制,而 RBAC3 MODEL 方面也可以利 用轉移特性經由 RBAC2 與 RBAC1 來繼承 RBAC0 MODEL 的 PERMISSION 與 ROLE 與等各個條件.如下圖:

圖 2-3 Role 繼承圖

Role-based 到底該如何依照 user 在公司中所扮演的 角色去分配權限呢,以下用簡單的圖說明:

(14)

圖 2-4 Role 關係圖-1

圖 2-5 Role 關係圖-2 圖 2-6 Role 關係圖-3

(15)

等阿拉伯數字代表不能的動作,因此上圖中,我們先將不同的動 作拆開分成 1,2,3 等數字,然後再依據不同的 user 他們所能做 的動作先做分類,如圖 2-6,然後再將分類後的結果結合成圖 2-4,最後我們可以得到一個有階層關係的圖 2-5,而該圖的每一 個階層就是代表整個公司裡面我們歸納出來的各種 ROLE,而根據 每個不同的 user 在我們這階層圖裡面所佔的位置,就是他在 RBAC model 下的 role 值。

由此我們可以發現 RBAC 相當適合是合一個高流動性以及組織 架構鮮明的公司使用,而且這種 model 有個相當好的特點,當有 人離職、升官或有新人加入時,系統 ADM 不需要去動到 OBJECT 的任何設定, 也不需要去更動既存的組織架構,他只需要針對 有變動的人也就是 SUBJECT 去根據他在公司中扮演的角色,重新 設定他的 role 即可輕鬆融入系統中,對於不管是系統的維護及 更新都有相當優良的效率,這也是本次為何選用此 Access Control Model 的主要原因。

Chapter 3 XML 技術介紹

3-1 DOM 物件介紹

3-1-1:建立 DOCUMENT 物件

利用 DOM 去建立 DOCUMENT 文件,系統使用 VBSCRIPT 的語言建立 DOCUMENT 物件語言,其語法如下:

SET 物件變數=CREATOBJECT(“MSXML2.DOMDOCUMENT”)其中 MSXML 為 MISCROSOFT 的物件,在新版的瀏覽器下 IE6.0 下仍使用 MISCROSOFT XML PARSER ,並不支援最新的 MSXML4.0 部分。

3-1-2:載入 XML 文件

完成 DOCUMENT 物件建立後,將再利用 DOCUMENT 物件的 LOAD 方法 載入方法,如 DOCUMENT 物件.LOAD(檔案路徑) :

(16)

如檔案 URL=Îhttp:www.bite.com.tw/book.xml

3-1-3:NODELIST 介面

在 DOM 物件中,某一個節點若包含數個子節點時,透過 CHILDNODES 屬性將可以取得該節點所有子節點所組成的節點集合物 件,節點集物件的型態為 DOM 物件的 NODELIST 介面,用於操作容納 數個節點的節點集物件,我們可以利用 FOR 迴圈配合節點集的長度 (也就是節點的個數),並利用 NODELIST 物件的 ITEM 方法,依序取得 節點集內的節點,語法如下: NodeList 物件變數.length 且可以用 CURNODE 去引用節點 範例如下:

For i=0 to (objectDOM.document.childnodes.length-1) Set curNode=objDOM.documentElement.childNode.item(0) Next 也可以利用 FOR EACH 去輸出節點 for each 物件變數 in 節點集物件 ……….. next

3-1-4:NODE 介面

在 DOM 物件的觀念中,XML 文件內不論是元素 ”屬”或是元素的 內容,都被視為節點,因此,NODE 介面在 DOM 物件內,是非常重要 的物件。圖形表示如 3-1DOM 樹狀圖

if not objDOM.load(“book.xml”) then document.write “無法載入” else

(17)

表 3-1 屬性 說明 Firstchild 第一個節點 Lastchild 最後一個節點 Nextcsbling 包含同一個節點下的下一個節點 Previousbling 包含同一個節點下的上一個節點 parentNode 節點的父節點 childNodes 包含所有子節點的節點集 ownerDocument 取得節點的根元素 NODENAME 屬性 依據不同的屬性,傳回不同的資料,如節點的類型為元素(ELEMENT), 則會傳回元素標籤的名稱,下表將說明各種不同類型節點 NODEVALUE 屬性的傳回值。 表 3-2 NODETYPE 類型 傳回值 NODE_ATTRIBUTE 屬性名稱 NODE_CDATA_SECTION #cdata-section NODE_COMMENT #comment NODE_DOCUMENT #document NODE_DOCUMENT_TYPE 包含文件型態名稱,如在 <!DOCTYPE xxx….>的 xxx 值 NODE_DOCUMENT_FRAGMENT #document_fragment NODE_ELEMENT 包含名稱空間的元素名稱 NODE_ENTITY 實體名稱 NODE_ENTITY_REFERENCE 被參照的實體名稱,不包含 引用實體時,實體名稱前 的” &”,以及實體名稱後的 “ ; ”,但包含名稱空間 NODE_NOTATION 記號名稱

(18)

NODE_PROFESSION_INSTRUCTION 處理區塊的內容

NODE_TEXT #text

(19)

3-1-5:選取單一節點

欲選取單一節點時,可以配合 XPATH 語法,呼叫 selectSingleNode 方法,即可以從 XML 文件的某個節點下選取出 XPATH 指定的子節點。 Node 物件變數 selectSingleNode(xpath 敘述) 回傳值為選取到的子節點物件,當 XPATH 敘述可選取數個節點時,則 將傳回第一個被選取到的節點,若未選取到任何子節點時,將傳回 NULL 值.語法中各部分的說明: Node 物件變數 @欲選取子節點的節點物件 XPATH @指定欲選取子節點的 XPATH 敘述 例如: 如欲選取 patient 節點下的 address 節點的物件,則語法可以寫 成 Set selNode=root.selectSingleNode(“/patient/address”)

3-1-6:選取多個節點

若運用 XPATH 語法選取多個節點時,則必須呼叫 selectNodes 方 法,則可以從 XML 文件中,選取出 xpath 指定的子節點。 Node 物件變數.selectNodes(XPATH 敘述)

(20)

回傳值為選取到的節點所組成的節點集物件,若選取到任何節 點,則傳回一個空的節點集物件。 Node 物件變數 @欲選取子節點的節點物件 XPATH 敘述 @指定欲選取子節點的 XPATH 敘述 例如 如欲選取 patient 下的所有子節點 Set objNodelist=objDOM.documentElement.selectNodes(“patient”)

3-1-7:運用元素取得節點

若想取得 XML 文件內,某節點名稱的節點時,可以運用 Document 物件的 getElementByTagName 方法。 如 Document 物件變數.getElementByTagName(“標籤名稱”) 回傳值為代表完成新元素的節點集物件. Document 物件變數 ----表 XML 文件的 DOMDocument 物件 標籤名稱 ----取得元素的標籤名稱之字串,若使用* 則表示將取得 XML 文件內所有的元素。

(21)

圖 3-2 利用 getElementByTag 方法

3-1-8:新增節點

利用 DOM 物件,新增節點至 XML 文件下(但只限於物件中,離開 物件使得改變的 XML 物件不可以儲存)

STEP1:運用 DOMDocument 物件的 CreatElement 方法,建立新 增元素。

STEP2:運用 DOMDocument 物件的 CreatTextNode 方法,建立包 含欲新增元素之內容的文字節點。

STEP3:呼叫節點物件(Node 物件)的 appendChild 方法,將 STEP2 完成建立的文字節點,加到 STEP1 建立的元素。

STEP4:從 XML 文件內,取得欲加入新節點的元素。

STEP5:呼叫節點物件(Node 物件)的 appendChildNode 方法, insertBefore 方法,或是 inserAfter 方法,完成節點的新增。

(22)

3-1-9: DOMDocument 物件變數 creatElement 方法

DOMDocument 物件變數 creatElement(標籤名稱) 說明: @Document 物件變數 代表 XML 文件的 DOMDocument 物件 @標籤名稱 欲建立的標籤名稱 例建立 ssn 節點 Set objNewNode=objDOM.creatElement(“ssn”)

3-1-10: DOMDocument 物件變數 creatTextNode 方法

DOMDocument 物件變數 creatTextNode(內容字串) 說明: @Document 物件變數 代表 XML 文件的 DOMDocument 物件 @內容字串 欲建立文字節點的內容 利用內容為 P006 為內容的文字節點 Set objNode=objDOM.creatTextNode(“P006”)

(23)

3-1-11:Node 物件 appChild 方法

Node 物件變數.appChild(節點物件) 說明: @Node 物件變數 引用欲新增的節點元素 @節點物件 引用欲加入的節點物件的元素 objNewNode.appendChild(objTextNode)

3-1-12:Node 物件 insertBefore 方法 insertAfter 方法

上述的 appendChild 方法,只是將新增元素,加至特定元素所包 含的最後一個元素,如果想要指定新增節點的位置,則必須運用 insertBefore 方法或是 insertAfter 方法,將元素新增到參考點之 前後之後: Node 物件變數,insertBefore(新增節點,參考節點) Node 物件變數,insertAfter(新增節點,參考節點 說明: @Node 物件變數 引用置欲新增的節點 @新增節點 引用制將被新增節點的物件變數 @參考節點 引用置節點插入的位置之節點的物件變數 例如將 objCurNode 節點包含的第二個節點前,插入 objNewNode 物件變數引用的節點,範例如下 3-3 圖

(24)
(25)
(26)

3-1-13:刪除節點

運用 DOM 物件可刪除 XML 文件內的節點,以 selectNodes 方法, 配合 XPath 敘述選取節點,並運用 Nodelist 物件的 removeAll 方法, 將選取出來的節點,一次就從 XML 文件中刪除。

子節點刪除:

STEP1:取得欲刪除的上一層節點。 STEP2:取得欲刪除的節點。

STEP3:呼叫節點物件(Node 物件)的 removeAll 方法,將 STEP2 取得的 節點,從 STEP1 取得的節點中刪除。 Node 物件變數.removeChild(節點物件) 說明: @Node 物件變數 引用包含欲刪除的節點物件 @節點物件 引用置欲刪除節點得物件變數 例如由 objNode 節點,移除 objRmvNode 節點 objCurNode.removeChild(objRmvNode) 如圖 3-5

(27)

圖 3-5 節點刪除

3-1-14 利用 XPath 刪除節點:

欲一次刪除 XML 文件內的數個節點時,可以運用 selectNodes 方 法配合 XPath 敘述選取欲刪除的節點,再運用 NodeList 物件的 removeAll 方法,一次將選取出的節點從 XML 文件內刪除。 NodeList 物件變數.removeAll @NodeList 物件變數 引用至 selectNodes 方法選取出節點的節點集物件 例如: objNodeList.removeAll 如圖 3-6

(28)
(29)

3-1-15:節點的屬性新增刪除與取得

屬性的取得: 欲取得節點的屬性時,可以使用節點物件(Node 物件)的 getAttribute 方法 Node 物件變數.getAttribute(屬性名稱) @Node 物件變數 引用欲取得的屬性之節點的物件變數 @屬性名稱 欲取得的屬性名稱 例如: objCurNode.getAttribute(“SSN”) 欲取得屬性節點,則可以用 getAttributeNode 方法。 Node 物件變數.getAttributeNode(屬性名稱) @Node 物件變數 引用欲取得的屬性之節點的物件變數 @屬性名稱 欲取得屬性名稱

3-1-16 屬性的刪除

欲刪除集點的屬性時,可以使用節點物件(NODE 物件)的 removeAttribute 方法: Node 物件變數.removeAttribute(屬性名稱) @屬性名稱 引用欲刪除屬性之節點的物件變數

(30)

@屬性名稱

欲刪除屬性的名稱

objCurNode.removeAttribute(“sale”) 如下圖 3-7

(31)
(32)

3-2 SAX 介紹

3-2-1 SAX 的結構

SAX 的英文全名為 Simple API for XML 是由許多介面組成的,運 用事件回呼機制,執行 XML 文件的剖析,介面具有方法,及其所需要 的參數,它純粹是一個規格,在方法呼叫時不被提供任何執行的程式 碼,但是它是一種具體的規格,JAVA 編譯器會檢查此介面應用程式 的類別來使其運作正常,類別提供可執行的方法,包括那些可被成其 他類別程式碼呼叫的公用方法,類別可能會使用一個以上的介面。在 許多情形下,SAX 會指定一些理論上可被幾個類別應用的介面,但實 際上這些介面會結合在一起,而由單一的類別所應用,為了使用介 面,類別需支援每一個介面中所定義的方法的程式碼。

3-2-2 SAX 的機制

SAX 的機制是以事件回呼運作,分為如下: 1 剖析 XML 文件的 SAX 剖析器 2 處理 XML 文件的處理器(handler) SAX 剖析器負責剖析 XML 文件,並在剖析過程發出事件,呼叫處 理器加以回應,這些事件包含開始與結束 XML 文件剖析的事件與開始 與結束元素的剖析事件。 剖析器只負責確認 XML 文件的是否合乎要求與執行解讀 XML 文件 的工作,至於實際的處理,則須由處理器決定,當然在 SAX 剖析器剖 析 XML 文件前,必須先取得處理器,在 JAVA 方面有提供 SAX 的套件, 程式設計師可以利用 SAX 套件來設計自己的處理器,套件如下: 套件 說明 Org.xml.sax 提供撰寫 SAX 程式的類別與介面 Org.xml.sax.exl 提供撰寫 SAX 程式的延伸類別與 介面 Org.xml.sax.helpers 提供撰寫 SAX 程式的類別與介面

(33)

SAX 的運作方式和 DOM 非常的不同,DOM 剖析器在完成 XML 文件 剖析後將產生一個 DOM 物件,並以樹狀圖結構來描述 XML 文件內容, 程式設計師可以透過 DOM 物件,操作 XML 文件的內容,而 SAX 剖析器 則是在剖析 XML 文件的過程中,就呼叫了對應的方法,執行 XML 文件 的處理。 因此,SAX 是比 DOM 更低階的 XML 文件處理介面,程式設計師可 以在以 SAX 剖析器剖析 XML 文件的過程中,就執行 XML 文件的處理, 因此執行 SAX 時,所需要的記憶體空間就比較少。

3-2-3

SAX 與 DOM 的優缺點

優點:

1:可剖析任何大小的檔案 因為 SAX 不需要將整個檔案載入記憶體,記憶體的消耗量比 DOM 小很多,而且它不會增加檔案的大小,當然 DOM 實際使用的記憶體數 量和剖析器有關,但在許多情況顯示,100kb 的文件至少需要 1M 的 記憶體。 2:對於小部分需求十分有用 若我們只想知道圖書館在本週到了幾本書,則所有資料讀入記憶 體就顯的沒有效率,SAX 的好處之一可以忽略我們不想知道的資料。 3:簡單,快速

缺點:

1:無法隨機存取物件 因為文件不是存在記憶體中,所以必須以資料的擷取的順序來處 理,當文件包含許多內部的交叉參照時,SAX 會變的相當難用,如外 部實體的參照。

(34)

2:難以計形複雜的搜尋 在資料量龐大時,SAX 較難去做出搜尋的工作,如搜尋跟元素的 屬性。 3:無法使用 DTD SAX1.0 沒有包含過任何 DTD 的內容,實際上,DOM 也沒有對此說 明太多,但 DTD 主要是跟剖析器有關。 4:目前瀏覽器並不支援 SAX 雖然有許多的 XML 剖析器支援 SAX 介面,有些瀏覽器定不支援 SAX.。

3-2-4 DOM

優點:

1:DOM 能確保文法即語法的確定性 因為 DOM 能將文字檔轉換成抽象節點樹表示,類似未關閉標籤及 不適當的巢狀標籤等問題可以完全的避免,以 DOM 操控 XML 文件時, 設計師可以不用擔心文件的表達格式,只需要注意相關資訊的父子關 係即可,此外 DOM 也可以防止文件中不適當的父子關係存在。 2:DOM 將內容從文法中抽出 DOM 產生的節點樹是 XML 內容的邏輯表示方式,而且不需要受限 於 XML 文法,節點數列的資訊可能用於更新資料庫或是產生 HTML 網 頁,而且設計師不需要關心 XML 語言的細節。 3:DOM 簡化內部文件操控 若設計師使用 DOM 來修改 XML 文件的結構,則會比傳統的檔案操 控機制來的簡單,此外全域性的操控可以於幾個指令來完成,而不需 要完成整個檔案的掃描來進行標籤的移除。 4:DOM 緊密的對應典型的階層式及關連式資料庫結構 DOM 對於資料元素的表現方式類似目前的階層式與關連式的資料 庫,這使得它可以很輕易的讓資訊在資料庫與 XML 檔案之間移動

(35)

缺點:

1:DOM 比 SAX 佔記憶體,因為 DOM 必須把整份文件載入記憶體中,所 以所需的記憶體會比 SAX 大,所以必須要比較大的記憶體資源。 2:因為 DOM 會比 SAX 速度慢,因為 DOM 必須呼叫函式庫,再去做 XML 文件的存取動作,不如 SAX 一邊剖析且一邊呼叫 FUNCTION,所以當 資料量大時 DOM 會變的很慢,沒有效率。

(36)

Chapter4 系統設計

4-1 系統概述

本次專題實做主題,主要是將 Access Control 的法則以 XML 實 做出來,而我們所選的實作主題是以醫院為主,原因不外乎是醫院有 明顯的階層關係,而醫生與病人間的相互關係也相當的鮮明,整個系 統概述如下: ¾ 環境背景設定: 我們設定醫院內部有許多的醫療部門,而以往的病例 多數是以紙上作業完成,而我們認為往後醫生可能遇到些 問題病症,而醫生在當下可能無法做出正確的判斷,醫生 可能會需要回家參閱書籍,在下班之後在家裡也能夠研究 病人的特殊病症,而病例是紙上作業無法帶回家裡,所以 我們利用 XML 將病例建檔,在利用 Access Control 機制 將醫生透過 ROLE 值判斷,以達到過濾使用者,讓適當的 使用者查閱適當的欄位。 ¾ 實作環境:

P-III 1.1G 256RAM WINXP IE6.0 NOTEBOOK 一台 P-III 850 128RAM WIN2K IE6.0 NOTEBOOK 一台 K6-2 500 256RAM WINME IE5.X PC 一台

我們要達到的效果是,醫院有不同的部門,每個部門也有數名醫 生,而每位病人一份病歷,這份病例上面有該病人在數個部門的病歷 資料,而透過 Access Cotrol 可以使不同部門的醫生看同一位病人時 所看到的病歷是他們責任範圍內的病歷。

(37)

4-2 系統檔案規劃

4-2-1 醫生個人資料檔案

我們的做法是將每位醫師個人資料都分開建立,也就是一個醫生 有一個 XML 個人資料檔,而這資料內不包含所有的個人基本資料,但 包含最重要的 role 值,這個 role 欄位相當重要,是我們用來判斷該 位醫生的 role 並依此去分配他的權限與所能使用的功能,而 SSN 是 我們假設當醫生來任職時我們會發給醫生一個安全序號,用來當作登 入時我們核對身分時使用,下例是一個醫生的 XML 檔的範例: <?xml version="1.0" encoding="BIG5"?>

<!DOCTYPE Employee SYSTEM "employee.dtd"> <Employee> <Name SSN="A3456">mary</Name> <Address POSTALCODE="123"> <Country>中華民國 </Country> <City>台中市 </City> <Street> <Road>文華路 </Road> <Number>100 號</Number> <Floor>1F</Floor> </Street> </Address> <Phone>28825252</Phone> <Phone>0911111111</Phone> <Birthday> <Year>2002</Year> <Month>1</Month> <Day>1</Day> </Birthday> <Department>內科 </Department> <Sex> 女 </Sex> <Role>內科醫生

(38)

</Role> </Employee>

而下圖是我們所定義的醫生個人資料的 DTD 用來協助我們達到 XML 資料 WELL_FORM 統一規格,我們用一套 XML SPY 軟體來表現:

(39)

4-2-2 病人病歷與個人資料檔案規劃

關於病人的檔案規劃我們為了利於使用 DOM 去實做 parse 的時候 能夠好做,我們將病人的部分分成兩個部分,第一個部分是病人的個 人基本資料,第二個部分是病例部分。 第一部分的基本資料我們是將每位病人的基本資料結合在一份 XML 檔案裡面,而第二部分也就是病歷的地方則是會在第一部份將每 位病人編號,然後我們將每位病人的病歷檔分開建檔,檔名是以病人 的編號命名方便查詢。 下面是病人第一部分的部分 XML 檔案: <?xml version="1.0" encoding="Big5"?> <PEOPLE> <PERSON PERSONID="p001"> <NAME>病人 A</NAME>

<ADDRESS>8 Fl.-3, #118, Guangfu S. Rd., Taipei, Taiwan

106, R.O.C.</ADDRESS> <TEL>(02)2123 4567</TEL> <EMAIL>eric@hotweb.net</EMAIL> </PERSON> <PERSON PERSONID="p002"> <NAME>病人 B</NAME>

<ADDRESS>5 Fl.-3, No. 111, Dahu St., Taipei, Taiwan 107,

R.O.C.</ADDRESS>

<TEL>(02)2623 4567</TEL> <EMAIL>alex@mail.com</EMAIL> </PERSON>

(40)

這裡則是我們設計的病人第一部分的 DTD

(41)

而下面則是病人 A 的病歷部分:

<?xml version="1.0" encoding="BIG5"?> <!DOCTYPE Case SYSTEM "case.dtd"> <Case> <num>P001</num> <phy> <Condition>外科病況 1</Condition> <Prescription>外科病況 1 之處方</Prescription> </phy> <phy> <Condition>外科病況 2</Condition> <Prescription>外科病況 2 之處方</Prescription> </phy> <bone> <Condition>骨科病況 1</Condition> <Prescription>骨科病況 1 之處方</Prescription> </bone> <bone> <Condition>骨科病況 2</Condition> <Prescription>骨科病況 2 之處方</Prescription> </bone> <Condition>骨科病況 3</Condition> <Prescription>骨科病況 3 之處方</Prescription> </bone> <thr> <Condition>內科病況 1</Condition> <Prescription>內科病況 1 之處方</Prescription> </thr> </Case>

(42)

這是我們第二部分病歷的 DTD

(43)

4-3 系統架構

目前網站的製作還是以 ASP、PHP 配上 SQL、MYSQL 等的結合去製 作較佔多數,但是實際上使用 XML 去做網站的人並不多,原因不外乎 是 XML 並未完全普及,還有 XML 再製作上所需要花費的時間成本會比 就多,首先會用 XML 的人就已經算少數的了,而 XML 在實作時資料與 畫面要分開處理,如果又要去使用 DOM 或 SAX 等 API 來實做又缺乏良 好的編譯器幫忙 debug,整個系統在實作上所要花費的時間就跟著延 長,但是我們還是可以先歸納出大部分的做法,如下圖:

圖 4-4 一般架構圖

早期 DOM 跟 SAX 等 API 尚未問世時,XML 的資料處理並不靈活, 跟已經成熟的 SQL、 ACCESS 等資料庫系統相比,功能遠遠不及,所 以大部分都是選擇利用既有的資料庫,而 XML 扮演的是中間資料傳輸 時負責傳遞訊息,也可以說是中間值,然後透過 XSLT 或 CSS 等技術 去顯示資料庫內的訊息。

(44)

實作起來因為不需要使用 DOM 或 SAX,所以 XML 不需要負責處理資料 欄位的處理,XML 只要做到處理資料庫系統整理完的結果,透過 XSLT 或 CSS 傳遞給提出要求的使用者,或將使用者提出的訊息傳遞給資料 庫系統,總而言之,在這個體系下 XML 扮演的是中間媒介的角色。 但是隨著 DOM 跟 SAX 的出現及發展,XML 也漸漸的可以像一般資 料庫系統般作欄位的控制,資料的搜尋變更等的能力,雖然目前 DOM 跟 SAX 都還在成長階段,XML 在做同樣的動作時還是顯得有些笨拙, 功能也還未如那些資料庫系統般的健全,但是已經可以讓我們產生生 出如下的架構圖: 圖 4-5 本次架構圖 在這種架構下,我們將完全不使用資料庫系統,我們完全使用 XML

(45)

來取代資料庫系統,利用 DOM 或者是 SAX 來做搜尋等的動作,採用 這個架構比較沒網站那麼多,原因主要是必須使用 DOM 或 SAX 這些技 術支援,而這些技術的親合力還不是那麼的高,再加上表現的效能還 沒有到一定的程度,所以想要去用的人並不是那麼多,所以這個體系 的結構較少人使用,不過也不少人是不使用 DOM 或 SAX,他們只是將 XML 當做資料的存放,然後在使用 XML 資料時適用 XSLT 或 CSS 直接 呈現給使用者,因為這些動作並不需要使用負責的資料處理,也就不 需要 DOM 跟 SAX 來幫他們達到目的,所以他們可以很輕易的使用這種 結構,不過功能相當有限。

4-4 系統運作流程

大略敘述一下流程,首先使用者在登入系統時,我們會先要求使 用者輸入他的 ID 與我們給醫生的安全識別碼,在經過系統的驗證過 後,我們會去搜尋使用者的個人檔案,去搜尋他的 ROLE 欄位內容, 圖 4-6 登入首頁

(46)

圖 4-7 輸入 ID

圖 4-8 輸入驗證碼

接著根據不同的 ROLE,使用者會被分配到不同的頁面,在考慮病 人名稱可能會有重複的情況下我們還有規劃一個搜尋的頁面:

(47)

圖 4-9-1 總覽

圖 4-9-2 搜尋功能 接著輸入欲查詢之病人病歷,輸入病人編號

(48)
(49)

圖 4-12 amy 醫生查詢 p001 病歷畫面 <Case> <num>P001</num> <phy> <Condition>外科病況 1</Condition> <Prescription>外科病況 1 之處方</Prescription> </phy> <phy> <Condition>外科病況 2</Condition> <Prescription>外科病況 2 之處方</Prescription> </phy> <bone> <Condition>骨科病況 1</Condition> <Prescription>骨科病況 1 之處方</Prescription> </bone> <bone> <Condition>骨科病況 2</Condition> <Prescription>骨科病況 2 之處方</Prescription> </bone> <bone> <Condition>骨科病況 3</Condition> <Prescription>骨科病況 3 之處方</Prescription> </bone> <thr> <Condition>內科病況 1</Condition> <Prescription>內科病況 1 之處方</Prescription> </thr> <thr> <Condition>內科病況 2</Condition> <Prescription>內科病況 2 之處方</Prescription>

(50)

</thr> 從圖 4-11 跟圖 4-12 相比我們可以發現不同的醫生查詢同樣的病 人所能看到雖是同一份病人檔,但是看到的內容卻是完全不同,上面 的程式碼就是病人 p001.xml 裡面病歷的紀錄。 而我們把整個的動作流程整理成如下圖所示: 圖 4-13 流程圖

(51)

4-5 系統檔案程式碼統計

此處我們將對本系統中所有的程式與檔案做統計: XML 檔案---11 筆 ,行數 619

網頁---23 筆,程式碼 1183 行 DTD---3 筆, 行數 54 行

(52)

Chapter5 結論

在本專題製作過程中,有不少的難題,也有不少的心得,並且對於 XML 的特點及未來的展望,是否在未來能夠長足發展,及目前 XML 的 一些缺點都將在本章做說明,並且希望本章可以給欲研究 XML 的學 弟們一些借鏡,讓他們能夠避免我們過程中所犯的錯誤,讓他們能夠 更順利的發展 XML。

5-1 專題分工

圖 5-1 分工圖

(53)

5-2 專題遭遇之困難與解決

¾ Q: 對於 XML 的不熟悉,與陌生 A: XML 是種標記語言,對於我們一般在校所使用的 C、JAVA、等 的語言結構是完全不同的,但是相對於同樣是標記語言的 HTML 卻又是兩種截然不同的架構,如前面幾章所說,XML 主要是資料 的描述,但是 XML 本身是完全無標籤適用來描述外觀的,必須要 配合 HTML、XSLT、CSS 等技術,對於這種新式的語言需要一段時 間的適應期,就我們接觸 XML 以來覺得 XML 算是入門難度較高的 語言,想要駕馭自如需要花不少時間,因為裡面牽涉到的技術面 不少,包括最重要的 parser 部分,你要怎麼去做,這些都是不 小的問題。 ¾ Q: 資料的來源缺乏 A: 對於 XML 雖然比起當年學長們在製作的時候,國內的書籍資 料比當年多了,但是跟別的語言書籍比較起來,XML 書籍的比例 真的還是很少,別的語言大概洋洋灑灑可以列出幾十本,XML 大 概就十來本,而且這些書籍的內容重複率相當高,大部分都是介 紹 XML、DTD、SCHEMA、XSL、CSS,對於更深的介紹多半是大概提 過,不過大部分的原因還是在 XML 發展未完善,所以要寫本書也 有難度。 研究 XML 的同好少之又少,在接到專題時,便開始著手蒐集 各方資料,雖然大家都說 XML 的優點將來會在網路上大放異彩, 但是真正有在用的人可以說是相當少,我們上了很多討論版與 BBS,相較於其他程式語言的版動輒每天好幾十篇文章,完善的 精華區與過來人的經驗,XML 的版面卻都是久久一篇文章,有在 討論的也多半是才剛接觸的人,缺乏有相當經驗的前輩能更給予

(54)

資料,所以在資料來源上也是相當缺乏,原因不外乎 XML 的架構 跟別的語言相差甚大難入手,親合力不佳的關係,所以大部分的 資料來源還是在國外原文的論文資料。 ¾ Q: Access control in XML 的研究資料不多 A: 我們的題目主要是做 access control 然後用 XML 來實做,這 方面的技術不能說沒有,我可以說這方面的研究我們不是第一 個,也不是第一個創造出這種方法的,但是國內的書籍資料是完 全沒有這方面的知識的,問了 XML 的同好,也都是搖搖頭說這方 面目前需求不高,做這個的人相當少,因為目前 ASP 等語言與 SQL 這些資料庫的結合運作 access control 的發展已經相當成熟, 大家也都相當滿意那些效果,所以用 XML 來做 access control 可以說是種挑戰,剛開始接觸時發現國內找不到這樣的研究資 訊,於是轉而去挖掘國外原文的研究論文,找到的論文幾乎都是 碩博士論文在研究這 access control in XML,而且這些論文在 我們多次閱讀之後,他們多半是屬於理論階段,比如說要做 access control 那 XML 的 TAG 該怎麼設定去配合 access control,在資料方面該怎麼設計,權限與資料間的關係怎麼去 釐清,真正實作上也是幾乎沒有提到,所以再研究實作方式時真 的是處處碰壁,求助無門,都靠組員們共同努力不斷的失敗與摸 索去實做出來。 ¾ Q: DOM 尚在發展階段與版本差異 A:

DOM(Document Object Model),是 W3C 的一個標準,而微軟 也支援 DOM(微軟強力推動 XML 的標準化,對於 XML 的發展有很 大的助力),並且微軟自行為 XML 製作了相關的 XML DOM 物件,

(55)

但是它並非完全依照 W3C 的標準製作,舉個例子來說,微軟在 IE5.x 系列中支援的 DOM 的物件符合 W3C DOM Level 1 的所有規 定,但是對於 W3C DOM Level 2 卻只支援部分,此外微軟自行訂 定出有別於 W3C DOM 的體制,屬於 Microsoft.XMLDOM,這是獨立 於 W3C 標準之外,所以我們是用 DOM 作為我們實作的工具,但是 有 W3C 跟微軟兩方不同的 DOM 書籍上的資料有時候編的有點混 亂,兩邊夾雜用所以會出現問題。 ¾ Q: 受到瀏覽器的限制 A: 這個問題其實還是在因為我們使用 DOM 所產生的一些問題, 我們的實作是在網頁上,也就是要透過瀏覽器來瀏覽程式,但是 前面提過了,IE5.x 系列它支援的並非完整的 DOM 架構,所以雖 然我們提到 XML 跨平台跨語言的優越性,但是在網路上留纜還是 必須受限於瀏覽器,也就是說大家用的版本不同,程式在上面的 結果有些人看會是正確的,但是有些人怎麼看卻都是錯誤訊息, 這點還有待改進,但是這也不能全說是微軟的錯,因為現階段 XML 在發展中,兩大瀏覽器網景跟微軟大廠,網景的瀏覽器它所能支 援的 XML 功能遠遠不及微軟所提供的,而且微軟對於推動 XML 相 當積極,微軟有意要將 XMLl 推向網路上的標準資料格式。 DOM level2 DOM level 1 IE5.x 所支援的 XML DOM 圖 5-2 DOM 版本涵蓋圖

(56)

¾ Q: 缺乏良好的發展平台,DEBUG 的困難 A: 目前 XML 有些人跟公司為它寫了一些剖析器(像是目前公認 最好的剖析器 XML SPY),這些剖析器可以將您的 XML 檔案連結 DTD 並且 parse 過.xml 跟.dtd 檢查是否符合 well-form,並且將 您的.xml 各個節點呈樹狀排列,這些做的相當完善,但是這些都 僅止於 XML DTD XSL CSS 這些檢驗,但是最重要的 DOM 跟 SAX 這 類的 API 卻沒有個 compiler 能夠幫助工程人員檢查它所寫的 DOM 或是 SAX 是否有錯,這點相當困擾我們因為我們主要是用 DOM 實 作卻沒有辦法有個 compiler 能夠幫我們 debug,每次寫錯程式就 是顯示(此處需要物件)這對寫 DOM 而言是相當痛苦的,不過如 果只是利用 DSO 去顯示 XMLl 檔案或是 XSL 顯示 XML 資料這些應 用都沒什麼問題,而這也是最廣為人用的領域,目前有用 XML 製 作網站的都是在這個範疇內居多,但是像我們要用 DOM 去設計網 頁的話就顯的相當費功,我想這點的不便也許就是為什麼使用 XML 的比例還不是那麼多的關係,不過 DOM 也是個發展中的東西, 或許等它穩定之後才會開始陸續有人專門為它量身打造個好用 的 compiler 吧。 ¾ Q: 對於 Access control 的陌生 A: 對於 access control 當初只知道它是幹麻用的,但是對裡面 運作的情形還是不甚了解,於是我們開始上網找相關的論文,找 到的 accesss control 資料不少,找到後也才發覺原來 access control 裡面有好多的 model,剛開始我們本來是用 ACL(Access Control List)這個 model,後來發現這個 model 實作的話,在 日後的維護及新增會相當的不方便,於是開始把之前研究的通通 歸零重來,後來選定 RBAC(Role Base Access Control)這個 model,可以算是眾家學說中表現相當不錯,大家認為相當好的 一個 model,所以這時才算是完成了 access control 部分的研究。

(57)

¾ Q:

DOM 與 SAX 之間的抉擇 A:

目前要操控 XML 中的 TAG 就必須要用到 DOM 或著是 SAX 這兩 者 API,因為有選擇所以我們當初便開始上各有關 XML 討論區去找人 討論,雖然只有幾個 XML 同好,但是根據大家討論的結果有個結論 是:DOM 以空間換取時間、SAX 以時間換取空間,為什麼會這麼說呢, DOM 在做 parse 時會需要不少記憶體去作暫存節點以便利用,再資料 量不大時還好,但是當資料量龐大時,則會消耗許多記憶體這是它的 缺點,而 SAX 的缺點比起 DOM 就相當多,SAX 是唯讀的它只負責讀出 文件其他一律不管,當資料量多時維護資料結構的開發者就必須負擔 龐大複雜的搜尋,且 SAX 不能讀取 DTD,再此建立一個比較表格來敘 述較為易懂。 表 5-1 DOM VS SAX DOM SAX 優點 1:能確保文法及語法的適當 性 2:DOM 對應典型的階層式及 關聯式資料庫 3:DOM 能簡化文件內部操控 1:簡單 2:最快速 缺點 文件是再記憶體中需要有一 定量的記憶體協助操作所以 當資料量大時記憶體需求相 對增加 1:無法隨機存取文件 2:不適合複雜的搜尋 3:無法使用 DTD 驗證 4:它是唯讀的 5:目前瀏覽器不支援 SAX (致命傷!)

(58)

5-3 組員心得

¾ 吳明晃: 這次的專題可以說是個新的體驗跟挑戰,以往四年在課業雖 然也有些科目也要分組做專題報告,但是那些東西的範圍都比畢 業專題來的小,也多半是老師給你該有的相關知識,然後讓你去 跟組員互相溝通分工實做出來,但是畢業專題就不一樣了,尤其 我們這次選的題目,XML 是個我們組員沒有接觸過的一種標記語 言,而且 XMLl 有別於目前大家常用的 C,VB JAVA 等語言,XML 是 個 98 年萌芽,到目前尚在成長極具潛力的語言,他的多樣性與 無限的擴充性,確實令人著迷,不過也因為這樣我們在開始學習 XML 的時候碰到不少麻煩,一開始很難接受 XML 標記規格,再加 上第一次碰到一個程式語言只負責編輯資料要顯示資料還要用 XSLT 或 CSS 等函數去控制,實在很不習慣,而且雖然 XML 被各界 認同他的實力與潛力,但是真正在用的人其實不多,所以我們在 學習的時候只能兩人一起互相研究,之後真的找不到答案我就開 始上各大程式語言討論區去找,有 XML 的版實在少的可憐,好不 容易找到版看看最近的一篇文章居然是好久以前的文章,簡單的 說大部分都廢版了,好不容易才找到幾個有經驗的網友可以跟他 們問問題討論,現在專題能夠做出來除了感謝老師跟組員之外真 的很感謝那群未曾謀面的網友肯抽出時間來提共諮詢。 想當初剛開始的時候遇到個很嚴重的問題,現在提出來希望 能夠給未來學弟妹們一些借鏡,當初專題剛起步的時候我們這組 是三個人,但是到三下中的時候另外兩位成員有溝通上的問題, 最後很遺憾大家無法再繼續下去,最後出走一為組員剩下我們兩 位繼續做,這次經驗雖然不好,但是當初如果身為第三者的我能 夠及時知道,那我可以成為潤滑劑,當初就不會這樣,這是個很 寶貴的經驗,不管以後學弟妹要做專題或是我們出了社會,大部 分都是團隊合作,大家要怎麼樣的包容對方跟沉澱自己的情緒, 如何不要引想到團隊的士氣與和諧這都是這次專題我覺得最深 切的體悟,眼睜睜看著本來是好友的一個 team 卻因為雙方的賭 氣造成全隊的損失與打擊,所以給學弟妹們些建議作專題既然找

(59)

定了同學一起做,那麼大家就該知道怎麼克制自己的情緒,怎麼 樣在團隊中即使不是扮演 leader 的角色,但是也要能夠扮演適 當的催化劑,學校是個可以容忍錯誤的地方如果不能在這裡學到 這些相處方式,等到了出社會情況會更慘。 在專業技能方面,算是個很大的挑戰,在前面的困難與解決 已提到,這個專題的困難度,做的功能是別的語言可以輕易作出 來的,但是在 XML 方面卻是個陌生的東西,那怎麼去挖掘出自己 所缺乏的知識,怎麼在貧乏的資源中去擷取出那微小可是卻助益 頗大的資源,這都是個全新的感受與體驗,這都是做專題前所沒 有去想過所沒有去體驗過的。 這個專題的歷時不短,中間經歷過組員退出,欲到瓶頸停滯 不錢而開始萌生退意想要逃避轉換題目,到重新整理心情克服難 關,到專題有成果出來,是個不錯的體驗有酸有甜,不過最後還 是要感謝李維斌老師與助教的提攜與教導,還有跟自己一起撐到 最後的組員陳明德。 ¾ 陳明德: 心得:最於 XML,說起來一堆該苦談,在當初未接觸 XML 之前, 認為他是一種從來沒聽過的東西,也不知道他是啥東東,只有一 些印象,認為他可能是只是 HTML 的一些新功能罷了,如 CSS 或 是一些樣式表示法,但事實卻是不然,在剛開始接觸 XML 時,完 全和 HTML 的觀念不一樣,它是一種文件的表示方式,但是它比 HTML 嚴謹多了,XML 在資料的規定下,每一份文件的內容必須要 有 TAG,所謂的 TAG 就是把資料內容加上一些標籤來顯示其中的 內容,利用其 TAG 的內容來建立完整的 XML 文件,有些定義的地 方一開始不知道它的意思,也是摸索了好久,才慢慢有感覺,對 於新東西,我覺得要有耐心去學習,慢慢的去思考它的定義,而 不是想之前的態度,一遇到不會的東西,就覺得心中滿是挫折, 導致做不下去的結果,在做專題的研究之中,重要的是成員對工 作的分配與合作的事情。剛開始時,對於分配工作的方面,必須

(60)

分配好工作,而自己的部分,有不懂的地方可以跟其他的組員, 一起去討論,總是會有結果的,總比一個人獨自在那努力奮鬥, 來的有效率一點,且對於合作方面,我是學到的蠻多的,對於組 員,因為是同班同學,但是也是會有意見不合的問題發生,此時, 雙方面必須冷靜下來,再做其他思考,也可以和其他的組員再討 論去解決,之前因跟同學意見不合而導致跟同學鬧翻的問題,其 實冷靜下來,也沒有啥大問題,只是當時會啥不能冷靜下來,好 好思考再去,研討其問題,在做完專題時,當初所考慮的疑慮都 是多餘的,只是鑽牛角尖,經過組員的開導之後,也學了好多東 西,專題也是訓練組員的合作關係與人際關係的溝通與如何去協 調,記得老師之前曾經講過,假如果我們已經畢業,且在公司擔 任設計系統的 TEAM 的一員,如果沒有良好的合作關係與人際關 係,只會使得工作無法完成,且會使得自己處處碰壁。 在企業中,講求的是團隊合作,而不是一個人去獨挑大樑, 一個人把工作完成,但是人際關係也會漸漸消失甚至是不見,純 粹只是一個工作的機器,所以慢慢的,自己也是慢慢試著去如何 學習如何管理情緒,也就是 EQ 的管理,有人說過人生的成就有 百分之 80 是靠 EQ,而百分之 20 是 IQ,所以摟,學好 EQ 變成是 當下自己要努力的目標,同時也要去訓練溝通,在良好的溝通之 下也是重要的一環,把自己的意見和組員工溝通,去結論出好的 意見,兩者相輔相成,才能邁向成功之路,與學弟共勉之。

(61)

5-4 參考文獻

1:陳錦輝 [XML 與 ASP 網站實做大全] 金禾出版社

2:陳勤意,陳長念 [XML&ASP 網頁程式設計] 知城出版社 3:Steven Holzner [Inside XML] 維科圖書有限公司

4:勞虎 [勞虎 XML] 網路免費電子書

5:小綠網研究室 [XML 專業程式設計] GOTOP 6:位元文化 [XML 技術實務] 文魁資訊

7:施威銘研究室 [XML 網頁設計與實做] 知城出版社 8:RBAC http://hissa.nist.gov/rbac/

9:RBAC in Healthcare http://hissa.nist.gov/rbac/

10:A REVISED MODEL FOR ROLE-BASED ACCESS W. A. Jansen July 9, 1998

11:Application of XML Tools for Enterprise-Wide RBAC Implementation Tasks

Ramaswamy Chandramouli

National Institute of Standards and Technology Gaithersburg, MD 20899,USA

12:INHERITANCE PROPERTIES OF ROLE HIERARCHIES W.A. Jansen

National Institute of Standards and Technology Gaithersburg, MD 20899, USA

13:Role-Based Access Control Features in Commercial Database

Management Systems

Chandramouli Ramaswamy & Ravi Sandhu

14:Proposed NIST Standard for Role-BasedAccess Control DAVID F. FERRAIOLO

RAVI SANDHU

數據

圖 2-1 SUBJECT
圖 2-2 OBJECT
表 3-1  屬性 說明  Firstchild 第一個節點  Lastchild 最後一個節點  Nextcsbling 包含同一個節點下的下一個節點 Previousbling 包含同一個節點下的上一個節點 parentNode 節點的父節點  childNodes 包含所有子節點的節點集  ownerDocument 取得節點的根元素  NODENAME 屬性  依據不同的屬性,傳回不同的資料,如節點的類型為元素(ELEMENT), 則會傳回元素標籤的名稱,下表將說明各種不同類型節點 NODEVALU
圖 3-1 DOM 樹狀圖
+7

參考文獻

相關文件

。當時人們發現的引擎在啟動後,機器會去尋找適合

建模時,若我們沒有實際的物理定律、法則可以應用,我們 可以構造一個經驗模型 (empirical model) ,由所有收集到

相當清楚的是, Avalokiteśvara 這個複合詞是由 avalokita 跟 īśvara 結合而成。avalokita 為觀,而 īśvara 為自在,所以譯為 觀自在。因為連音或連聲 (saṃdhi)的關係,avalokita

結 果發現這個新解跟greedy choice一樣好(也是一個 最佳解) 或者發現這個新解更好(矛盾, 所以最佳解

結 果發現這個新解跟 greedy choice 一樣好 ( 也是一個 最佳解 ) 或者發現這個新解更好 ( 矛盾 , 所以最佳 解裡面不可能沒有 greedy choice)... 證明

結 果發現這個新解跟greedy choice一樣好 (也是一個 最佳解) 或者發現這個新解更好 (矛盾, 所以最佳解 裡面不可能沒有greedy

多黨制:若一國之內有三個以上的政黨在活動,而且在國會中各占有相當議 席,但卻沒有一個政黨可以單獨贏得大選而執政。..

由於醫療業導入 ISO 9000 品保系統的「資歷」相當資淺,僅有 三年多的年資 11 ,因此,對於 ISO 9000 品保系統應用於醫療業之相關 研究實在少之又少,本研究嘗試以通過