DOM을 구현한다는 표현은 반드시 binding이 되어야 할까요?

DOM 문서에는 OMG IDL로 정의되어 있는 인터페이스를 Java와 JavaScript로 바인딩하는 Appendix가 존재합니다. 그러나, 해당 내용을 소개하는 부분 바로 아래 쪽에 다음과 같은 문구가 존재합니다.

Note: OMG IDL is used only as a language-independent and implementation-neutral way to specify interfaces. Various other IDLs could have been used ([COM], [JavaIDL], [MIDL], ...). In general, IDLs are designed for specific computing environments. The Document Object Model can be implemented in any computing environment, and does not require the object binding runtimes generally associated with such IDLs.

DOM 모델은 IDL을 사용하여 binding으로 구현할 수도 있지만, 어떠한 컴퓨터 환경에서 DOM을 구현할 수 있다고 언급이 되어 있습니다. 그렇다면 DOM 문서를 한 번 들여다 보겠습니다. 모님이 주장하셨던 바에 따르면 DOM의 문서는 모두 implemented가 아니라 binding으로 되어야 하겠죠.

그러나, 위의 문서를 보시면 아시겠지만 implementation이라는 구현이라는 표현을 썼습니다. DOM 문서가 잘못된 걸까요?

출처: What is the Document Object Model?

P.S.1
DOM에서 제공하는 idl은 결국 인터페이스만 주기 때문에 Java로 binding하던 ECMAScript로 bindnig하던 브라우져 입장에서는 idl이 제공하는 인터페이스를 구현(Java로 보면 클래스를 구현해야하고, C/C++등에서 도 header파일을 제외한 body는 작성해야겠죠?)해야 합니다. binding만으로는 아무것도 할 수 없습니다.

P.S.2
e님의 댓글에 대한 추가 반론입니다.

 1. 논쟁이 되었던 내용

논쟁이 되었던 내용은 YUI 라이브러리의 get()의 리턴 값에 대해서

1. 저의 경우 HTMLElement 인터페이스를 구현했다고 얘기를 하자
2. e님께서 HTMLElement 구현은 틀렸다고 하셨으며, binding이라고 불러야 한다

는 주장을 하셨습니다. 여기에서 얘기한 바와 틀렸다고 하시면 더 이상 할 얘기는 없습니다.

 2. 제 주장에 대한 근거
HTMLElement 인터페이스를 만드는 방법에는 두 가지가 있습니다.

• 하나는 binding으로 생성하는 방법이고
  
• 하나는 해당 인터페이스를 직접 구현하는 방법입니다.
  

두 번째 사항이 구현이라는 점에는 의심의 여지가 없다고 생각이 됩니다. 그럼 첫 번째 방법으로 어떻게 인터페이스가 만들어지는 지 구체적인 예를 보도록 하겠습니다.

 2-1. Firefox의 예를 보도록 하겠습니다.
Firefox의 소스 코드를 다운 받아서 압축을 풀게 되면 dom이라는 폴더가 나오게 됩니다. dom > public > idl > core 를 들어가게 되면 DOM의 기본 core로 사용되는 idl 파일(정확히는 idl의 확장버전인 xpidl로 쓰여진)들이 정의되어 있습니다. (예를 들자면, nsIDOMElement.idl파일이 여기에 포함되어 있습니다. )

Firefox를 build하게 되면 idl이 정의되어 있는 core 폴더의 Makefile.in을 읽어서 rules.mk에 정의되어 있는 내용대로 파일을 생성하게 됩니다. (SDK_XPIDLSRCS에 정의되어 있음을 주의하시기 바랍니다.)

rules.mk파일을 살펴보게 되면 다음과 같이 XPIDL로 정의된 idl 파일들에서 header 파일을 생성해 내는 것을 보실 수 있습니다. xpt파일도 생성이 될 수 있습니다. idl파일로 부터 header를 생성하는 과정까지를 생성하고 cpp 파일 부분은 실제 브라우져에서 구현하게 됩니다.

이 외에도 xpidl을 이용해서 header, xpt, html, java 파일들을 만들 수 있습니다.

Firefox에서 YUI의 get으로 해서 얻어진 Element의 입장을 생각해 보면 다음과 같이 말할 수 있을 것 같네요.
Element는 DOM의 HTMLElement.idl 파일을 바인딩해서 생성된 헤더파일을 구현한 객체라 보면 되지 않을까 생각됩니다.

 2-2. Webkit의 경우
Webkit의 소스코드를 보게되면 Webkit_WebCore > html 폴더에 여러 DOM idl 파일들이 있는 것을 확인할 수 있습니다. 해당 idl 파일들은 build 시에 DerivedSources.make 파일을 호출하게되고 여기에서 .idl을 header 파일로 변경되는 것을 확인할 수 있습니다.

즉, Webkit도 Firefox와 마찬가지로 IDL 파일로는 header파일만 생성이 되고 구현은 브라우져에서 직접 구현을 해야된다는 얘기입니다. YUI의 get()으로 생성되는 element의 입장에서 본다면 binding이 갖는 의미는 header를 생성해준다 여기까지만 해당되고 구현은 브라우져 자체의 문제가 되는 것이지요.

 3. 결론
Firefox, Webkit이 아닌 브라우져의 경우에는 소스를 볼 수 있는 방법이 없어서 확인을 하지 못했습니다. 여기 두 브라우져에서 살펴본 결과 구현이라는 표현을 사용못할 이유는 전혀 찾지 못하였습니다.

e님께서 말씀하신 '자신의 카테고리 범주'가 뭔지 e 님께서 말씀하시는 '깊은 의미'가 뭐길래 구현이라 부를 수 없는 지 구체적 근거에 의해서 반론을 해주시기 바랍니다. 진정한 기술자란 말로서 비난하는 자세가 아니라 논리적 근거와 코드로서 답할 수 있어야 한다고 생각합니다.

반론에 대해서는 언제든지 환영합니다.

DOM으로 <input type='checkbox'>를 생성할 때 checked가 안되는 문제점

IE에서 dom으로 input을 생성할 때 (type은 checkbox입니다.) checked설정이 안되는 문제가 있습니다.
MSDN을 보면 checked attribute에 boolean값을 설정할 수가 있습니다.

그러나, IE에서 DOM을 이용하여 checkbox를 생성하는 경우 checked속성을 true로 설정하는 경우 설정이 안되는 문제가 있습니다. (Mozilla  계열의 브라우저는 동작합니다.)
Side-X에 올라와있는 실험 내용을 보면 다음과 같습니다.

결과로 1, 2는 설정이 되지 않으며 3, 4의 경우에는 설정이 됩니다. checked 속성이 설정이 되는 경우는 document에 input이 append되는 경우 또는 document.createElement를 생성할 때 <input checked>로 생성이 되는 경우에 해당이 됩니다.

참고로 mozilla 계열의 브라우져에서 <input chekced>로 생성할 경우 exception이 발생합니다.

출처:

MSDN의 CHECKED attribute
Side-X의 [DOM] checkboxにデフォルトでチェックする

graft()

DOM을 사용하여 html을 생성해내는 코드를 작성할 때 부딪치는 가장 큰 문제가 상당히 많은 양의 코딩이 필요하다는 점입니다. 코드가 많아질 수록 당연히 Bug가 생길 가능성도 증가하게 되겠죠. 이를 해결하기 위해서 나온 방법이 html구조를 쉽게 표현하는 구조와 이를 파싱하여 DOM으로 자동 생성해주는 코드를 만드는 방법입니다.

생성할 html 코드

Graft function이 이러한 해결책을 위해서 나온 function인데요.
동작원리는 간단합니다. Array로 구성된 Html구조를 파싱하면서 recursive하게 DOM객체를 생성하거나 attribute를 설정해주는 코드입니다.

Grant로 파싱할 대상인 html array

사용방법은 간단합니다. []로 태그를 감싸는데요. Array의 처음은 태그의 이름이 두번째는 태그에 들어갈 text나 속성(Hash Object인 {})이 들어갑니다. 동일한 html을 생성하는 DOM 생성 코드와 비교하면 상당히 많은 줄의 차이를 갖습니다.

DOM 생성 코드

대략 25줄대 2~3줄 정도의 차이니까, 코딩양으로 본다면 엄청난 양을 줄일 수 있는 장점이 있습니다.
Grant의 실제 코드를 보면 다음과 같습니다.

graft의 경우에는 release된 version이 없습니다. function만 올려진 상태구요. 댓글 달린 것과 경험상 봤을 때 setAttribute를 사용하여 Class설정하는 코드는 IE에서 동작하지 않을겁니다. className으로 설정하도록 수정이 필요하구요.

검증이 100% 안된코드로 보시고 작업하셔야 될 걸로 생각되네요..
그래도, 이런게 어딥니까 ^^

출처 :

Ajaxian의 Garft: Making JavaScript DOM a Piece of Cake
Making Javascript DOM a Piece of Cake with the graft() Function

P.S. 1:
graft란 단어는 '접목하다', '이식하다'라는 의미를 가진 단어입니다. (사전 찾아봤습니다. ^^;;)

P.S. 2:
Ajaxian에 최근에 올라왔던 DOMTool(html을 코드를 읽어들인 다음 동일한 html을 생성해내는 DOM 생성 코드를 만들어내는 툴입니다.)에 대한 기사를 읽다가 Graft가 생각나서 정리해봤습니다.

P.S. 3:
Graft()는 Sean Burke씨와 그의 책, Higher Order JavaScript에 나와있는 코드를 기반으로 하여 만들어졌습니다. [얼핏 기억으로는 Perl로 만들었다는 글을 본 것 같기도 합니다. 미확인 정보 --;;]