XML(DOM&SAX)

파서가 필요한 이유
XML 문서는 단지 계층적 구조 형식의 문서이다.

→ XML 문서의 내용을 읽어 들여 처리하는 기능의 프로그램이 필요하며 이 프로그램이 파서이다.

텍스트 형식인 XML 문서가 컴퓨터에 의해 처리되기 위해서는 그 구조를 프로그램에 의해 처리 가능한 데이터 구조나 구조화된 정보 등으로 변환하는 것이 필요하다.

파서는 XML 응용 프로그램 개발 시 세부적인 XML 문법으로부터 프로그램을 분리시켜 주는 역할을 하는데 동작하는 방식에 따라 DOM 과 SAX 파서가 있다. DOM은 W3C가 표준으로 정한 파서이다.

파서는 XML 문서의 내용을 읽어 들이는 기능의 각 프로그래밍 언어 모듈(API)을 제공한다.

파서의 목적은 XML 문서의 내용을 검증하여 그 내용을 응용프로그램에게 전달하는 데 있다.

SAX

SAX는 XML 문서를 하나의 긴 문자열로 간주한다.

SAX 는 문자열을 앞에서 부터 차례로 읽어 가면서 요소, 속성이 인식될 때 마다 Event 를 발생시킨다.

각각의 이벤트가 발생될 때 마다 수행하고자 하는 기능을 이벤트 핸들러 기술을 이용하여 구현한다.(콜백 메카니즘)

DOM

DOM에서는 XML문서를 읽어들이는 중간에는 아무일도 일어나지 않고 XML문서의 모든 element, text, attribute 등에 대해 객체를 만든다. 이후에 Document 객체를 리턴하며 그 때부터 작업을 할 수 있다. 즉 DOM 파서는 XML 문서로부터 DOM API 에 알맞는 객체 구조를 생성하는 역할을 한다.

XML 문서는 엘리먼트(element), 속성(attribute), 텍스트 등으로 구성된 트리 구조의 계층적인 정보이다.

→ XML 문서의 각 요소들에 대하여 트리 구조의 Java 객체로 표현

DOM API 는 XML 문서를 나타내는 각 구성 요소에 대한 객체들의 인터페이스를 표준으로 정해 놓은 것이다.

DOM 이냐? SAX 냐?

파싱하는 방식에 의한 DOM 과 SAX 의 주요 차이점

→ 문서에 접근하는 방식의 차이

DOM 은 몇 번이고 원하는 요소 정보를 바로 찾아가 추가 및 수정할 수 있는 수단인데 비해, SAX는 문서를 처음에서 끝까지 순차적으로 처리하며 읽는 기능으로만 처리할 수 있다.

[ DOM 을 선택하는 경우 ]

- 문서의 구조 전체가 메모리에 올려져 있게 되므로 다음과 같은 경우
적합하다.

- 문서의 일부를 두 번 이상 읽어야 할 때
- 문서를 수정해야 할 때
- 문서의 구조적인 처리가 필요할 때

→ DOM 방식은 XML 문서의 구조를 그대로 적용할 수 있으며 임의의 엘리먼트나 속성에 바로 접근할 수 있고 값의 수정이 가능하다

[ DOM 의 단점 ]

- 메모리 사용이 많다.

DOM 은 문서 전체를 메모리에 올려 둔다. 따라서 문서가 어느 정도 이상 클 경우 메모리 사용량이 지나치게 커질 수 있다.

- 속도가 느리다.

DOM 구조를 여러 번 이용하는 경우엔 효과적이지만 DOM 구조를 한번만 읽어 처리하거나 다른 형식의 문서 구조를 처리하고자 하는 경우 비효과적이다.

- DOM 은 IDL(인터페이스 스펙만 정의하는 언어)로 정의되어 있다. (?)

구현 언어 중립이라는 장점도 있지만, DOM API 가 인터페이스 구성이므로 Java 로 매핑(mapping)한 DOM API 는 Java 프로그래머 입장에서는 매우 부자연스럽고 사용이 불편하고 Java만의 장점을 살릴 수 없다. 예를 들면 노드 등 객체들의 집합을 처리할 때 vector를 쓸 수 없다. DOM에서 Vector를 쓸 수 있도록 인터페이스를 개발하면 다른 언어에서는 쓸 수 없기 때문이다. 그래서 모든 API를 다시 제공한다.

** JDOM - 자바로 재설계된 API를 가지고 있는 DOM 기술. 자바로만 구현할 수 있다. 구현할 때 보다 편하고 자바스럽다. W3C가 표준으로 정하지 않았고 자바 개발자들 사이에서만 사용된다. Sun에서도 JAVA의 기본 API로 사용하지 않는다.

[ SAX 를 선택하는 경우 ]

SAX 의 장점은 속도와 단순함에 있으며, 모든 문서의 내용을 메모리에 올리지 않으므로 메모리를 적게 사용하게 된다.

XML 문서를 읽으면서 그 내용을 다른 Java 객체의 트리 구조로 변환하는 경우 또는 단지 XML 문서의 내용을 읽기만하려는 경우에는SAX 를 사용한다.

- XML 문서를 순차적으로 일괄 처리하는 경우
- 상대적으로 XML 문서 구조가 간단하고, 그 구조 자체가 주요 관심사가 아닌 경우
- 메모리, 속도와 관련된 문제점을 우선적으로 고려해야 하는 경우

ex) 환경파일 처리(Tomcat의 server.xml, web.xml 등의 문서 등)

[ SAX 의 단점 ]

- 문서 일부분에 대한 임의 접근이 불가능 하다.

- 이벤트 및 작업 상태를 직접 보관해야 한다.

- SAX 는 단순하게 어떤 요소를 읽었는지 등의 정보를 줄 뿐, 현재 이 요소가 어떤 요소의 일부인가 등의 문맥 정보를 자동으로 유지해 주지 않는다.

→ 사용자가 문서의 구조로부터 정보를 추출하기 위해 보다 많은 일을 해야 한다.

- SAX 는 한번에 문서를 훑어 내려가면서 읽기 때문에 성능은 높일 수 있지만, 내용 수정이 불가능하다.

[ DOM 과 SAX 의 비교 ]

DOM SAX

접근 방법 트리 기반 이벤트 기반

장점 문서에 임의 접근 메모리 효율, 빠른 속도

단점 메모리 사용량, 속도 느리다 구조에 대한 접근 곤란, 읽기 전용

적용분야 구조적 접근이 필요한 경우 문서 일부분만 읽을 때

문서 정보를 쉽게 파악하고자 할 때 데이터 변환 시, 유효성 처리

DOM(Document Object Model)을 이용한 XML 문서 처리

DOM 파서를 사용해서 element 단위로 DOM 객체를 메모리에 생성시킨 이후 하는 일은 이 DOM 객체의 트리 구조를 따라가며 필요한 정보를 얻거나 필요한 출력을 만드는 것이다.

DOM 파서는 XML 문서를 계층적인 노드의 형태로 나타낸다.

DOM 은 1998 년 10 월 1 일에 World Wide Consortium에 의해 Recommendation 으로 제정되었다.

[ DOM 의 레벨(버전을 레벨이라 한다) ]

DOM Level 1
DOM 코어(core)라고도 한다. HTML과 XML 문서 모델 중심이다. 이 부분은 문서 Navigation(특정 부분으로의 접근)과 Manipulation(조작)에 대한 기본적인 기능을 포함하고 있다. HTML을 위한 DOM을 XML을 위한 DOM으로 바꾼 것 뿐이기 때문에 CDATA 섹션이나 DTD 등을 인식하지 못한다.

DOM Level 2
스타일 쉬트 모델과 문서에 첨부된 스타일 정보를 조작하는 기능을 포함시켰다. 또한 문서의 특정 위치로 쉽게 이동할 수 있게 하며, 이벤트 모델을 정의하며, XML 네임스페이스에 대한 지원을 제공한다.

DOM Level 3(not recommended)
문서의 validation 을 지원하는 DTD 스펙 보완, Schema 와 같은 컨텐트 모델지원 추가, 문서의 로딩과 저장 그리고 키 이벤트와 이벤트 그룹에 관한 부분에 관한 부분을 포함하게 된다. XPath 기술 지원 스펙이 추가되었다.

[ DOM 레벨과 표준화 과정 ]

- DOM Level 1 : 1998 년 10 월 W3C Recommendation

- DOM Level 2 : 2000 년 11 월 W3C Recommendation

- DOM Level 3 : 2001 년 8 월 W3C Working Draft
2004 년 12 월 현재 ....
일부 스펙 최종 Recommendation
Load&Save, Validation

[ Node : DOM 의 핵심 인터페이스 ]

Node(노드)는 DOM 트리의 노드를 추상화한 인터페이스로 XML 문서의 6 가지 문법적 요소를 노드(객체)로 다룰 수 있게 해준다.

[ DOM 처리 예 ] 최상위에 Document 객체가 만들어 진다.
그 밑에 루트 엘리먼트 객체(root), 그 밑에 자식객체들이 만들어진다. 항상 XML문서에 자식엘리먼트가 나온 순서대로 첫 번째, 두 번째 객체가 만들어지며 각각의 컨텐트는 그 컨텐트의 엘리먼트의 자식 노드가 된다.

아래 그림에서 child의 자식은 텍스트 노드 "자식1"이다. 바로 아래는 자식이고 자식 밑의 모든 노드는(손자는) 자손이다. 분리문자로만 이루어진 텍스트 들도 (리턴,탭)이 하나의 텍스트 노드가 되며 이것을 비어있는 텍스트 노드라고 부른다. 이 비어있는 텍스트 노드는 항상 만들어진다. 그러므로 root의 자식은 1개가 아니고 3개 이다. 비어있는 텍스트 노드가 만들어지지 않도록 설정할 수있지만 DTD가 있는 경우에만 해당된다.

파싱이 되면 Document 객체를 리턴한다.

엘리먼트의 속성은 자식이 아니고 엘리먼트 노드에 정보가 들어가며 getAttributes()로 추출할 수 있다.

DOM 은 위와 같은 형태의 XML 문서를 하나의 덩어리로 인식하여 처리한다. → DOM 객체

SAX를 이용한 XML 문서 처리

SAX 는 xml-dev 메일링 리스트를 통한 많은 사람들의 조언을 통해, David Megginson 이 개발하였다.

SAX 1.0 - 1998 년 5 월
SAX 2.0 - 2000 년 5 월

SAX 는 XML 의 파싱에 대해 이벤트-구동(event-driven) 인터페이스를 갖는다.

문서가 매우 큰 경우, 불필요한 트리를 구축한다는 것은 상당한 리소스 낭비일 수 있는데 트리 기반보다는 이벤트 기반의 API 가 더 간단하다.

[ SAX 처리 예 ]

이 XML 문서를 SAX 를 통해서 읽는다면, 다음과 같이 event 가 발생한다.

- 문서시작
- root element 시작
- parent element 시작
- child element 시작
- 텍스트 data : 자식 1
- child element 끝
- child element 시작
- 텍스트 data : 자식 2
- child element 끝
- child element 시작
- 텍스트 data : 자식 3
- child element 끝
- parent element 끝
- root element 끝
- 문서 끝

위와 같은 순서대로 발생하는 event 를 처리하는 핸들러를 구현하는 방식으로 SAX 기반의 프로그램을 개발한다.

[ 학습 정리 ]

1. DOM
DOM 은 XML 문서를 나타내는 객체들의 인터페이스를 표준으로 정해 놓은 것으로 DOM 파서는 바로 XML 문서로부터 DOM 구조를 생성하는 역할을 한다.

2. SAX
SAX 는 문자열을 앞에서 부터 차례로 읽어 가면서 요소, 속성이 인식될 때 마다 Event 를 발생시킨다. 각각의 Event 발생에 대하여 핸들러를 구현하는 프로그래밍이다.

3. DOM 과 SAX 의 주요 차이점

DOM 은 전체 문서를 메모리상에 올려놓고 처리하므로 원하는 요소를 바로 찾아가 추가 및 수정할 수 있는데 비해, SAX는 문서를 처음에서 끝까지 순차적으로 처리하며 문서의 일부분만을 메모리에 올려 처리하므로 메모리를 적게 사용하는 반면 특정 요소를 찾아 수정하는 기능은 불가능하다.

4. DOM 과 SAX 의 적용 분야

DOM 은 XML 문서에 대한 구조적 접근이 필요한 경우, 문서 정보를 쉽게 파악하고자 할 때 사용되며 SAX 는 문서의 일부분만 읽을 때 데이터 변환 시, 유효성 처리 시 사용한다.

출처 : http://blog.naver.com/megaissue/140108333860

[출처] SAX VS DOM|작성자 고화영