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. 논쟁이 되었던 내용

- 저의 경우 HTMLElement 인터페이스를 구현했다고 얘기를 하자
- 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 파일 부분은 실제 브라우져에서 구현하게 됩니다.

Firefox에서 YUI의 get으로 해서 얻어진 Element의 입장을 생각해 보면 다음과 같이 말할 수 있을 것 같네요.
Element는 DOM의 HTMLElement.idl 파일을 바인딩해서 생성된 헤더파일을 구현한 객체라 보면 되지 않을까 생각됩니다.
2-2. Webkit의 경우
Webkit의 소스코드를 보게되면 Webkit_WebCore > html 폴더에 여러 DOM idl 파일들이 있는 것을 확인할 수 있습니다. 해당 idl 파일들은 build 시에 DerivedSources.make 파일을 호출하게되고 여기에서 .idl을 header 파일로 변경되는 것을 확인할 수 있습니다.

3. 결론
Firefox, Webkit이 아닌 브라우져의 경우에는 소스를 볼 수 있는 방법이 없어서 확인을 하지 못했습니다. 여기 두 브라우져에서 살펴본 결과 구현이라는 표현을 사용못할 이유는 전혀 찾지 못하였습니다.
e님께서 말씀하신 '자신의 카테고리 범주'가 뭔지 e 님께서 말씀하시는 '깊은 의미'가 뭐길래 구현이라 부를 수 없는 지 구체적 근거에 의해서 반론을 해주시기 바랍니다. 진정한 기술자란 말로서 비난하는 자세가 아니라 논리적 근거와 코드로서 답할 수 있어야 한다고 생각합니다.
반론에 대해서는 언제든지 환영합니다.
다른 사람의 말에 담겨진 의미를 자신의 카테고리 범주에서 생각하는 것은 그리 바람직한 모습이 아니라고 생각합니다.
답글삭제내가 혹시... 저 사람이 말하는 보다 깊은 의미는...
이런 생각을 갖고 뒤돌아 보는 것이 진정한 기술자의 자세라고 생각합니다.
if () 조건은 항상 있습니다.
@e - 2008/03/06 13:29
답글삭제네 맞습니다. 그러나, 자신의 카테고리 범주안에서 판단하고 결론을 내리고 무조건 틀리다는 결론을 내리는 것도 개발자의 바른 자세는 아니겠죠.
if()에 대한 얘기를 하지도 않고 너는 틀리다라고 말하는 것도 그렇다고 생각합니다. e님의 주장은 '구현되었다고 말하는 것은 틀렸다'였으니 if()가 있으시다면 여기에 대한 반론 부탁드립니다.