문서 객체 모델
![]() HTML 문서 내의 DOM 계층의 예 | |
최초 출판일 | 1998년 10월 1일 |
---|---|
마지막 버전 | DOM4[1] 2015년 11월 19일 |
조직 | 월드 와이드 웹 컨소시엄, WHATWG |
기초가 되는 표준 | WHATWG DOM Living Standard W3C DOM4 |
약어 | DOM |
HTML |
---|
비교 |
문서 객체 모델(영어: Document Object Model 도큐먼트 오브젝트 모델[*], DOM)은 XML, HTML 문서의 각 항목을 계층으로 표현하여 생성, 변형, 삭제할 수 있도록 돕는 인터페이스이다. W3C의 표준이다. W3C의 표준화한 API들의 기반이 된다.
DOM은 HTML 문서의 요소를 제어하기 위해 웹 브라우저에서 처음 지원되었다. DOM은 동적으로 문서의 내용, 구조, 스타일에 접근하고 변경하는 수단이었다. 브라우저 사이에 DOM 구현이 호환되지 않음에 따라, W3C에서 DOM 표준 규격을 작성하게 되었다.
DOM은 문서의 기반이 되는 데이터 구조에 제한을 두지 않는다. 잘 구조화된 문서는 DOM을 사용하여 트리 구조를 얻어낼 수 있다. 대부분의 XML 해석기와 XSL 처리기는 트리 구조의 이용에 대응해 개발되었다. 이 같은 구현에서는 문서의 전체 내용이 해석되어 메모리 저장되어야 한다. 때문에 DOM은 문서 요소가 임의적으로 접근되고 변경할 수 있어야 하는 응용 프로그램에 가장 적합하다. 한 번 해석 시 단 한 번의 선택적 읽기/쓰기가 이루어지는 XML 기반 응용 프로그램에서, DOM은 메모리에 상당한 부하를 가져온다. 이 경우처럼 속도와 효율적인 메모리 소비가 중요한 상황일 경우 SAX 모델이 장점을 가진다.
역사
[편집]문서 객체 모델의 역사는 1990년대 말 웹 브라우저의 자바스크립트 엔진에 널리 구현된 최초의 스크립트 언어들인 자바스크립트와 J스크립트의 역사, 그리고 넷스케이프 내비게이터와 인터넷 익스플로러 간 브라우저 전쟁의 역사와 뒤얽혀있다.
자바스크립트는 1995년 넷스케이프 커뮤니케이션스에 의해 넷스케이프 내비게이터 2.0과 함께 출시되었다. 넷스케이프의 경쟁사 마이크로소프트는 자바스크립트의 재구현체인 JScript와 더불어 인터넷 익스플로러 3을 이듬해 출시하였으며 JScript는 웹 개발자들이 클라이언트 사이드 상호작용으로 웹 페이지를 만들 수 있게 한다. 이 언어들의 1세대에서는 사용자가 생성한 이벤트를 감지하고 HTML 문서를 수정하는 기능에 제한이 있었으므로 이를 "DOM 레벨 0", "레거시 DOM"이라고 부르게 되었다. DOM 레벨 0을 위해 어떠한 독립적인 표준도 개발되지 않았으나 HTML 4의 사양에는 부분적으로 기술되었다.
레거시 DOM은 접근 가능한 요소의 종류에 제한을 받았다. 폼, 링크, 이미지 요소들은 루트 문서 객체로 시작하는 계층 이름으로 참조가 가능하였다. 계층 이름은 경유되는 요소의 이름이나 일련의 색인을 이용할 수 있었다. 이를테면, 폼 입력 요소는 document.formName.inputName
또는 document.forms[0].elements[0]
으로 접근이 가능하였다.
이 레거시 DOM은 클라이언트 사이드 폼 유효성 확인 및 대중적인 롤오버 효과를 가능케 하였다.
1997년, 넷스케이프와 마이크로소프트는 각각 넷스케이프 내비게이터 4.0과 인터넷 익스플로러 4.0을 출시하였으며 여기에는 로드된 HTML 문서의 변경을 가능케 하는 동적 HTML(DHTML) 기능 지원이 추가되었다. DHTML은 레거시 DOM 구현체에서 사용이 가능하였던 초기 문서 객체의 확장이 요구되었다. JScript가 자바스크립트에 기반을 둔 덕에 레거시 DOM 구현체들이 상당히 호환성이 좋았으나 DHTML DOM 확장은 각각의 브라우저 개발사가 병렬로 개발되었기 때문에 비호환 상태로 유지되었다. 이 DOM 버전들은 "중간 DOM"(Intermediate DOM)이라는 이름으로 알려져 있다.
ECMA스크립트의 표준화 이후 W3C DOM 워킹 그룹은 표준 DOM 사양의 초안화를 시작하였다. "DOM 레벨 1"이라는 이름의 완성된 사양은 1998년 말 W3C 권고안이 되었다. 2005년, W3C DOM의 대부분이 공통 ECMA스크립트 지원 브라우저들에 양호하게 지원이 되었으며 이 브라우저들에는 마이크로소프트 인터넷 익스플로러 버전 6(2001년부터), 오페라, 사파리, 게코 기반 브라우저(예: 모질라, 파이어폭스, 시몽키, 카미노)가 포함된다.
DOM 단계
[편집]현행의 DOM 규격은 단계 2이다. 그러나 일부 단계 3 규격 역시 현재 W3C의 권고안이다.
- 단계 0
- DOM이 만들어지기 이전의 모든 벤더 종속적인 DOM을 포함한다. 예:
document.images
,document.forms
,document.layers
,document.all
. 그러나 이것은 W3C이 공식적으로 공개한 규격이 아니며, 표준화 이전에 있던 단계를 말한다. - 단계 1
- DOM 문서에 대한 탐색과 조정
- 단계 2
- XML 이름공간(네임스페이스; namespace) 지원, 필터링된 뷰(view)와 DOM 이벤트.
- 단계 3
- 6가지 다른 규격으로 구성:
- 코어
- 불러와서 저장(Load and Save)
- XPath
- 보기 및 초기화(formatting)
- 요구사항
- 유효 확인
웹 브라우저간의 비호환 문제
[편집]브라우저간의 DOM 구현의 차이 때문에 상호 운용성 문제가 생기게 되었다.
마이크로소프트의 인터넷 익스플로러 브라우저는 2005년 현재 사실상의 표준 웹 브라우저의 위치를 차지하고 있기 때문에, 모질라와 같이 표준을 준수하는 브라우저에 대한 개발에 곤란한 문제가 된다. 만약 개발자가 마이크로소프트의 DOM 확장을 사용한다면 표준 준수에 대한 신뢰성을 잃을 수 있으며, 반대의 경우라면 비표준 확장을 사용하지 않음으로 생기는 기능적 제약 때문에 사용자가 이탈할 수도 있다. 얄궂게도 마이크로소프트와 넷스케이프 양쪽 다 표준 경쟁의 와중에서 비표준 기능을 퍼트리게 된 것에 대한 책임을 피할 수 없다. 더구나 최근의 상황을 빼면, 역사적으로 언제나 인터넷 익스플로러의 표준 지원이 넷스케이프의 그것에 비해 우위에 있었다.
만약 표준 호환 브라우저가 웹 시장에서 주목할 만한 점유율을 차지하게 된다면 이 같은 상황이 바뀌게 될 것이며, 비표준 확장을 사용하는 것이 작성자에게 상업적 불이익으로 다가올 것이라는 것에 대해서는 일반적으로 의견이 일치하고 있다.
같이 보기
[편집]- 문서 객체 모델 이벤트
- SAX - 순차적 방법으로 XML 문서에 접근/수정하는 API 집합
- JDOM - DOM, SAX, 그리고 문서를 작성을 위한 사용자 해석기를 통합한 XML용 자바 기반 문서 객체 모델
각주
[편집]- ↑ 모든 버전은 W3C DOM만을 가리킨다.
외부 링크
[편집]- DOM Living Standard by the WHATWG
- Original W3C DOM hub by the W3C DOM Working Group (outdated)
- Web Platform Working Group (current steward of W3C DOM)