하늘 아래 세상 이야기.

자바가 바라보는 XML

XML과 관련해 자바에서 필요한 자료는 대부분 이미 나와있다 해도 과언이 아니다. 다만 ‘언제 어떤 도구를 사용할 것인가’를 일목요연하게 정리한 자료를 좀처럼 찾기 어렵다는 것이 흠이라 할 수 있다. 따라서 자바 환경에서 간단한 XML 프로그램을 만들어 보고, DTD 등의 스키마에 맞춰 검증하는 등 XML 문서를 처리하는 기본적인 도구를 살펴보자.

김도형

필자가 현재 수행하는 프로젝트에 XML을 도입하기 시작한 것은 지난해 9월경부터다. 처음에는 개발중인 응용 프로그램에서 읽을 수 있도록 자바 컴포넌트에 관련된 메타 정보(metadata)를 기술하기 위해 XML을 사용했는데, IBM의 XML4J 파서(parser)를 이용해도 별 무리가 없었다. 하지만 올해로 접어들어 XML의 적용 범위가 넓어지고 그 형태가 복잡해짐에 따라 XML을 읽기 위한 가장 기본적인 도구인 DOM(Document Object Model) 파서 혹은 SAX (Sim ple API for XML) 파서만을 갖고는 팀 내의 개발자들이 유지보수가 용이한 XML 처리 코드를 작성하는 것이 어렵다는 것을 알게 됐다. 이로 인해개발하고자 하는 모듈의 특성에 따라 어떤 도구를 사용할 지에 대한 명확한 지침과 빈번히 사용되는 처리 유형에 적합한 도구를 만들어 구축할 필요성이 부각됐기 때문이다.

자바의 경우 XML과 관련해 필요한 자료는 이미 대부분 나와있다 해도 과언이 아니다. 다만 어떤 도구가 현재 나와 있고, 이들을 어떻게 사용해야 하는가에 대한 방침을 일목요연하게 정리한 자료가 좀처럼 없다는 것이 흠이다. 따라서 이 글에서는 XML을 간단히 만들어 보고, DTD(Docu ment Type Definition) 등의 스키마에 맞춰 검증하는 등 XML 문서를 처리하기 위한 기본적인 도구를 소개할 것이다. 덧붙여 언제 어떤 도구를 어떻게 사용해야 하는지를 살펴보고, 기존 라이브러리를 보완할 수 있는 라이브러리를 몇 개 만들어 볼 것이다.

이 글은 각 API나 XML 처리 도구의 사용법을 설명하기보다는 어떤 수단이 있고, 각각의 장단점은 무엇인지를 설명하기 위한 것임을 명심하기 바란다. 따라서 XML 자체나 API의 구체적인 사용법은 이미 어느 정도 알고 있다는 전제 아래 얘기를 풀어나갈 것이다.

XML에 어떤 도구를 사용할까

자세한 설명에 들어가기 앞서 여기서 사용할 도구를 간단히 살펴보면 다음과 같다.

◆ Xerces-J 1.2.0 : 자바로 쓰여진 대표적인 XML 파서. 원래는 IBM의 XML4J를 기반으로 아파치 프로젝트의 일부로 시작됐으나, 현재는 IBM이 Xerces-J의 코드를 기반으로 테스트한 후 XML4J를 배포하는 상황이다. SAX2, DOM2, XML 스키마 등 최근 완결됐거나 진행중인 웹 컨소시엄(W3C)의 표준은 물론 XML 문서를 생성하는 도구를 함께 지원한다(참고 자료 8).

◆ JDOM 1.0 베타 5 : 언어 독립적으로 작성된 W3C의 DOM(IDL로 정의된 인터페이스)을 대신해 자바 프로그래머가 사용하기 쉬운 형태의 객체 모델을 대신 제공하는 자바 패키지. 어떤 자바 파서와도 함께 사용할 수 있으나 반드시 Xerces-J를 함께 사용해야 한다(참고 자료 6).

◆ 오라클 클래스 생성기(Class Generator) : DTD로부터 XML 구조를 표현하는 자바 클래스를 위한 코드를 자동으로 생성해주는 시스템. 이를 이용하면 DOM보다는 해당 DTD의 구조에 가까운 자바 객체를 사용해 그 DTD를 따르는 XML 파일을 메모리에 객체로 구성, DTD와의 일치 여부 확인 및 출력이 가능하다. 현재 개발중인 XML 데이터 바인딩(data binding)과 비슷한 시도라고 볼 수 있지만 아직은 출력 전용이다.

XML 관련 자바 API의 표준화

C++나 다른 언어에 비해 자바가 갖는 장점 중 하나는 API의 표준화가 빠르다는 것이다. 이는 JCP(Java Community Process)가 효과를 발휘하고 있기 때문이다. 현재 XML과 관련해 다음과 같은 몇몇 표준 API가 개발됐는데, 가까운 장래에 XML 관련 API는 J2SE(JABA 2 Standard Edition) 혹은 J2EE(Java 2 Enterprise Edition)에 포함될 것으로 보인다.

◆ XML 처리 API(Java API for XML Processing) : 현재 버전 1.0이 나와 있으며, XML 문서의 파싱을 위한 표준 API를 정의하고 있다. XML 네임스페이스(namespace) 1.0, DOM 레벨 1, 그리고 SAX 1.0을 지원한다. 다음 버전인 1.1은 추가로 DOM 레벨 2와 SAX 2.0을 지원하고 단순히 파싱 이외에 최근 많이 사용되는 XML 변환 표준인 XSLT 1.0을 지원할 예정이다. 이 API는 JAXP라고 지칭하는 경우가 많은데, 이때 마지막 ‘P’는 1.0에서는 ‘Parsing’이었으나 1.1에서는 XSLT에 대한 지원이 들어가면서 ‘Processing’으로 바뀌었다.

◆ XML 데이터 바인딩 : DTD와 XML 스키마같은 XML 문서의 구조를 표현하는 스키마로부터 그에 맞는 자바 객체를 자동으로 생성하는 기술. 해당 스키마를 따르는 XML 문서를 파싱해, 문서 구조를 나타내는 자바 객체가 스키마에 맞는지 검증하거나 거꾸로 자바 객체로부터 XML 문서를 생성한다(참고 자료 3, 4).

◆ XML 메시징 API : ebXML 등 XML 메시지의 교환을 위한 표준 API(참고 자료 5).

API가 표준화되면 응용 프로그램이 파서 등 특정 XML 처리 도구에 묶이지 않고, 이러한 표준 API를 매개로 다양한 XML 처리 도구는 서로 연동할 수 있는 기반을 마련하게 된다. 하지만 아직 XML 관련 처리 도구가 XML 파서와 함께 제공되거나 XML 파서의 내부 정보에 의존하는 경우가 많아 응용 프로그램을 작성할 때 많은 부분을 특정 모듈에 맞춰 작성하는 것이 현실이다. 이런 문제점은 앞으로 점차 해결될 것으로 보이나, 현재로서는 가능한 한 표준 API를 사용하는 것이 최선이라고 하겠다.

DOM과 SAX의 세계로의초대

XML 문서는 기본적으로 컴퓨터로 처리하기 위한 문서이다. 또 흔히 자바에서 메타 정보를 저장하기 위해 사용하는 프로퍼티 파일(pro perties file, java.util.Properties를 사용해 읽고 생성)과는 달리 구조적인 정보를 표현할 수 있는 문서 형식이다. 단순히 비트 혹은 문자들의 연속인 XML 문서가 컴퓨터에 의해 처리되기 위해서는 그 구조를 복원, 프로그램에 의해 처리 가능한 데이터 구조나 구조화된 정보의 흐름 등으로 변환하는 것이 필요하다. 이런 일을 해 주는 것이 XML 파서이고, 파서가 처리한 XML 문서를 응용 프로그램에 전달하는 수단 중 표준화된 것이 바로 DOM과 SAX이다.

DOM은 HTML에서 자바스크립트를 사용해 본 사람들이라면 상당히 친숙한 개념이다. XML 문서는 요소(element), 속성(attribu te), 텍스트 등으로 구성된 나무 구조의 계층화한 정보로 볼 수 있다. 따라서 이들을 각각 자바 객체에 대응시키면 XML 문서를 나무 구조의 자바 객체로 표현할 수 있다(실제는 XML 문서의 한 부분에서 다른 부분을 지칭할 수 있으므로 그래프라고 볼 수 있겠다). 이와 같은 XML 문서를 나타내는 객체들의 인터페이스를 표준으로 정해 놓은 것이 바로 DOM이다. 일반적인 DOM 파서는 바로 XML 문서로부터 DOM 구조를 생성하는 역할을 한다.

반면 SAX는 XML 문서를 앞에서 뒤로 읽어가면서 어떤 요소, 속성 등이 나타났는지 알려주는 구조 API이다. 즉, 문서의 구조를 일련의 사건(이벤트) 흐름으로 표현한다고 볼 수 있다. 이런 이벤트들은 일종의 정보 덩어리로 볼 때, SAX 파서는 XML 문서을 정보 덩어리의 흐름으로 바꾸는 도구이다.

일반적으로 DOM과 SAX를 파싱 단계에서 필요한 파서와의 인터페이스 정도로 생각하는 사람이 있는 듯 하다. 하지만 앞서 장황하게 설명한 것처럼 XML 문서를 컴퓨터 내에서 표현하는 대표적인 방법으로, 응용 프로그램의 다양한 모듈 간에 XML 문서를 주고받는 표준적인 방법이라고 보는 것이 옳다. 실제 많은 툴이 단순히 XML 파일 혹은 스트림을 입출력 형식으로 지원하는 것 외에 DOM이나 SAX DocumentHandler를 추가로 지원하는 경우가 많은 것은 단적인 예라고 하겠다. 이 둘은 그 성격이 판이하게 다르므로 어떤 경우에 어떤 것을 사용할 것인가를 명확히 파악해 두는 것이 매우 중요하다.

DOM이야? SAX야?

파싱 후 문서를 처리하는 면에서의 DOM과 SAX의 주요 차이점은 DOM이 몇 번이고 원하는 부분을 추가 및 수정할 수 있는 수단인데 비해, SAX는 문서를 처음에서 끝까지 순차적으로 처리한다는 것이다. 우선 DOM뿐 아니라 일반적으로 문서의 구조가 메모리에 있을 때 유리한 점은 다음과 같다.

• 문서의 일부를 두 번 이상 읽어야 할 때
• 문서를 빈번히 수정해야 할 때
• 문서 구조 처리가 특별히 중요할 때

즉, 문서의 일부분을 정렬하거나 GUI를 통해 사용자가 빈번히 수정해야 할 때가 바로 이런 경우에 해당한다. 하지만 이런 경우에는 XML 파일로부터 반드시 DOM 객체를 생성할 필요가 없다. XML 데이터 바인딩으로부터 생성된 객체를 사용하거나 또는 SAX 파서를 통해 문서를 읽으면서 그 내용을 다른 자바 객체의 나무 구조로 변환한 경우에는 SAX가 오히려 DOM보다 유리하다.

이런 맥락에서 이 글에서는 DOM 객체의 대용으로 JDOM을 소개하고, SAX를 이용해 특정 구조를 갖는 XML 파일를 자바 객체 구조로 쉽게 변환할 수 있는 도구를 만들어 본다. 참고로 실제 DOM 파서들은 대부분 SAX 파서를 내부적으로 사용해 DOM 객체를 만들어 낸다. 이런 점을 고려하면 DOM은 다음의 경우에 적합하다.

1. 응용 프로그램이 다양한 종류의 XML 문서를 다루는 경우
   (특정한 문서 구조를 가정할 수 없는 경우)
2. XML 문서의 구조가 충실히 보존돼야 하는 경우
   (XML 편집기나 XPath 등 XML과 연관된 다른 표준들을 처리하는 처리기를 만드는 경우)
3. 별도의 자바 객체들을 정의하기에는 배보다 배꼽이 커지는 경우

다음은 DOM이 갖고 있는 단점을 정리한 것이다.

1. 메모리 사용이 많다 : DOM은 문서 전체를 메모리에 올려둔다. 따라서 문서가 어느 이상 클 경우 메모리 사용량이 지나치게 커질 수 있다. 또 특정 XML 문서의 구조와 무관한 일반적인 구조이므로 실제 처리되지 않는 공백 등도 메모리에 할당한다.
2. 속도가 느리다 : DOM 구조를 빈번히 이용하는 경우면 상관없다. 그러나 DOM 구조를 한번 처리하거나 다른 자바 객체의 나무 구조로 변환하고 버리는 경우에는 DOM 객체의 생성 비용을 정당화할 수 없다.
3. DOM은 IDL로 정의돼 있다. 따라서 이를 자바로 매핑(mapping)한 현재 DOM API는 자바 프로그래머 입장에서는 매우 부자연스럽고 사용이 불편하다. 또 특정 형식의 문서를 처리할 경우 DOM은 지나치게 일반적이므로 문서의 특성을 충분히 반영하지 못한다.

DOM에 비해 SAX는 일반적으로 다음과 같은 경우에 적합하다.

1. XML 문서를 순차적으로 일괄 처리하는 경우
2. 상대적으로 XML 문서가 간단하고 그 구조 자체가 주요 관심사가 아닌 경우

결국 SAX를 사용하는 것은 DOM과 같은 메모리, 속도와 관련된 문제점을 해결하기 위함이다. 하지만 SAX는 이와 달리 DOM 생성 작업이 단순하지 않다. 실제로도 DOM 파서는 SAX 파서를 이용하되, DOM 생성 부분을 추가하고 있는 경우가 대부분이다. SAX는 그야말로 단순하게 어떤 요소를 읽었는지 등의 정보를 줄 뿐, 현재 이 요소가 어떤 요소의 일부인가 등의 문맥 정보를 자동으로 유지해 주지 않는다. 이는 사용자가 문서의 구조로부터 정보를 추출하기 위해 보다 많은 일을 해야함을 의미한다.

결국 SAX를 사용하는데 있어 성패는 SAX의 단점을 보완할 만한 도구를 적절히 만들 수 있느냐에 달렸다고 해도 과언이 아니다. 따라서 여기서는 그런 종류의 도구를 하나 만들어 볼 것이다. 참고 자료 10은 이런 맥락에서 SAX를 사용하는 방법에 대한 좋은 지침서이다.

DOM을 이용한 XML 문서 처리

DOM 파서를 사용해 DOM 객체를 메모리에 생성시킨 이후 하는 일은 결국 이 DOM 객체의 나무 구조를 따라가며 필요한 정보를 얻거나 필요한 출력을 만드는 것이라 볼 수 있다. 다음과 같은 간단한 XML 파일을 생각해 보자.

<?xml version=”1.0” ?>
<student-file>
<student>
    <name>A</name>
    <id>1</id>
</student>
<student>
    <name>B</name>
    <id>2</id>
</student>
</student-file>

<리스트 1>은 이를 파싱해 내용을 원하는 형식으로 화면에 출력하기 위한 프로그램이다. 표준인 JAXP(Java API for XML Proce ssing)를 사용했으므로 실상 JAXP를 제공하는 아무 파서에서나 실행된다.

<리스트 1>처럼 흔히 DOM을 사용한 XML 처리 부분은 루프(loo p)와 조건 분기가 빽빽하게 들어있어 읽기가 힘든 코드가 되는 것이 보통이다. 지금은 문서의 구조가 단순하지만 문서의 구조 자체가 복잡하다고 생각하면 들여쓰기(indent)가 끔찍할 수준에 이를 것이다.

주로 DOM으로 하는 일이 특정 순서에 의해 XML 각 부분을 처리하고 지나가는 것인데 비해, DOM API 자체는 DOM 구조를 특정 순서로 방문하기 위한 쉬운 방법을 제공하지 않는다. 이런 맥락에서 현재 아직 최종 버전이 나오지 않은 DOM 레벨 2에서는 필요한 노드만 추출해 DOM 객체의 나무 구조를 쉽게 방문하기 위한 API를 추가했다. 여기서는 DOM과 같이 나무 구조로 된 데이터 구조를 훑어가기 위해 자주 사용되는 디자인 패턴인 방문자(visitor) 패턴을 사용한 일반적인 라이브러리를 구현해 보도록 하겠다. DOM 구조의 특정 부분을 골라내는(filtering) 부분은 DOM 레벨 2의 모델을 빌려 왔고, 방문자 구조는 일반적인 모델과는 다소 다르게 DOM 객체들 자체에는 아무런 변화를 주지 않고 구현하는 방법을 사용했다(방문자 패턴에 대해서는 참고 자료 12 참고).

다음은 주요 객체에 대한 설명이다. 소스코드는 지면관계상 ‘이달의 디스켓’을 참고하기 바란다.

◆ Visitor : 인터페이스로서 특정 종류(no detype)의 특정 이름(nodename)을 가진 노드를 방문했을 때 불리는 두 가지의 메쏘드를 정의하는 객체. voidvi sitPre(Node)와 void visitPost (Node)가 그 예로, 전자는 자식 노드를 방문하기 전에 그리고 후자는 자식 노드를 모두 방문한 후에 불린다. 관심있는 종류마다 사용자가 만들어줘야 한다. DefaultVisitor는 두 메쏘드를 아무 일도 하지 않도록 구현해 놓은 편의 객체이다. 두 메쏘드 중 하나만 구현하고자 할 때 사용한다.

◆ NodeFilter : DOM 객체의 구조를 따라갈 때, Visitor에게 넘겨줄 노드인가를 판단하는 객체. 사용자가 만들어줘야 한다. NodeFilter에는 int accept(Node) 메쏘드가 있는데, 여기서 돌려줄 수 있는 값은 세 가지이다. NodeFilter.ACCEPT는 Visitor에게 넘겨주고, NodeFilter.REJECT는 해당 노드와 그 자식 노드까지 모두 무시하며, NodeFilter.SKIP은 해당 노드만 무시하되 자식 노드들은 Visitor에게 넘기라는 뜻이다. NodeFilter.ACCEPT_ALL은 모든 노드를 받아들이는 NodeFilter 객체이다.

◆ DOMTraverser : DOM 구조를 깊이 우선(depth-first)으로 훑는 객체. 실제 NodeFilter로 노드를 시험하고 적절한 Visitor를 찾아 호출해 주는 역할을 담당.

사용법은 <리스트 2>를 보자. 이것은 <리스트 1>과 동일한 역할을 하는 객체이다. 각 Visitor 객체들이 요소별로 정의돼 있고, DOMT raverser가 이 객체에 정의된 메쏘드를 필요에 따라 불러준다.

SAX를 이용한 XML 문서 처리

SAX는 이름이 의미하는 대로 그야말로 단순함 그 자체이다. <리스트 3>은 Xer ces 파서를 사용한 예로, 표준인 JAXP를 쓰지 않았다. 이는 JAXP 1.0이 아직 SAX2를 지원하지 않기 때문이다. <리스트 1>의 DOM을 사용한 예제보다는 다소 정돈된 느낌을 준다.

SAX 파서는 문서를 훑어가면서 태그를 만났을 때 startEle ment(...)를 불러주는 식으로 정보를 주기는 하지만, 그 정보를 어떤 체계적인 형태로(이를 테면, DOM과 같은 나무구조) 저장해 주지는 않는다. 따라서 SAX를 사용해 프로그래밍하는 경우 가장 중요한 것은, 과연 특정 메쏘드를 불렀을 때 이 부분이 문서의 구조상 해당 부분을 유지하는 것이다. <리스트 3>은 XML 문서의 내용을 조금 다른 형식으로 표시하는 것뿐이므로 구조적인 정보는 별도로 유지할 필요가 없어 비교적 단순해 보인다.

‘현재 문서 구조에서 어느 부분을 처리하고 있는가’ 하는 문맥 정보는 일반적으로 SAX의 ContentHandler(SAX1이라면 Document Handler) 객체 내 필드 변수에 저장해 ContentHandler의 각 콜백(callback) 메쏘드 사이에서 공유한다. 경우에 따라서는 스택을 사용하는 것이 많은 도움을 주기도 한다. 흔히 전역 변수(global variable)를 지나치게 사용하면 프로그램의 각 부분이 얽혀 유지보수가 어려운 것처럼 공유 변수도 처리할 XML 문서가 복잡해지다 보면 결국 마찬가지 결과를 가져올 수 있다(참고 자료 10).

참고 자료 10의 두 번째 기사에서는 이런 문제를 쉽게 해결할 수 있는 수단으로 TagTracker와 SAXMapper라는 라이브러리를 제시하고 있다. 자바월드에서 내려받을 수 있는 소스코드에는 TagTracker .java와 SaxMapper.java, SaxMapperLog.java의 최종 버전이 빠져 있는데, 필자가 손을 봐서 ‘이달의 디스켓’에 넣어뒀다. 이 자료에는 예제가 충분히 나와 있으므로 여기서는 기본적인 소개와 간단한 예제만을 다루도록 한다.

TagTracker라는 객체는 일종의 콜백 객체로서 앞서 소개한 바 있는 Visitor 객체와 유사한 역할을 한다. 단, 여기서 메쏘드는 네 가지로 각각의 의미는 다음과 같다.

◆ onStart(String uri, String localName, String qName, Attributes attr) : TagTracker에 연관된 요소가 시작될 때 불린다. Visitor의 visitPre와 같은 기능을 수행.

◆ onEnd(String uri, String localName, String qNa me, CharArrayWriter contents) : TagTracker에 연관된 요소가 닫힐 때 불린다. Visitor의 visitPost와 같은 기능을 수행.

◆ onDeactivate() : 현재 TagTracker가 담당하는 요소의 자식 요소의 처리가 시작되기 전에 현재의 TagTracker에게 그 사실을 알려주기 위해 호출된다.

◆ onReactivate() : 현재 TagTracker가 담당하는 요소의 자식 요소의 처리가 완결되자마자 불린다.

특정 요소에 대응하도록 만들어진 TagTra cker는 마치 파일 경로명을 적어 주듯 상대 경로명과 함께 다른 TagTracker의 track 메쏘드를 사용해 등록시켜 준다. 이렇듯 나무구조 형태로 TagTracker의 등록을 마치면 SaxMapper가 스스로 XML 파일을 파싱해 가며, 필요한 TagTracker를 찾아 앞서 설명한 onXXX 메쏘드를 호출해 준다.

<school-file>
<student>
    <name>Student</name>
    <id>12</id>
</student>
<teacher>
    <name>FirstTeacher</name>
    <id>AA</id>
</teacher>
<student>
    <name>NextStudent</name>
    <id>13</id>
</student>
<teacher>
    <name>SecondTeacher</name>
    <id>1A</id>
</teacher>
</school-file>

앞의 소스는 맨 처음 소스를 약간 변형한 것으로서 학생뿐 아니라 이제는 선생님들에 대한 정보를 섞어 나열하고 있다. 여기서 선생님의 ID는 16진수, 학생들의 ID는 10진수로 표현돼 있다고 가정하자. 자, 이제 이 XML에 담긴 정보를 <리스트 4>와 같은 객체로 연관시키려고 한다. 이를 TagTracker를 사용해 작성하면 <리스트 5>와 같은 프로그램이 만들어진다.

우선 문서 요소에는 별 관심이 없으며 루트 TagTracker에 track (“school-file/student”, student)과 같은 식으로 더해 주고 있음을 알 수 있다. <리스트 4>에 대해서는 별도로 TagTracker를 등록한 적이 없으므로 아무런 처리 없이 넘어간다. SAX는 DOM 대신 독자적인 자바 객체를 생성하는데 상당히 유용한 도구라고 볼 수 있다.

표준 DOM의 대안, JDOM

비록 DOM이 많은 단점이 있다지만 프로그래머 입장에서는 메모리에 있는 데이터 구조를 다루는 방식이 이벤트 방식보다 자연스럽다. JDOM은 DOM의 장점을 살리는 동시에 자바 프로그래머에게 부자연스럽다는 DOM의 문제점을 자바2의 컬렉션 등을 사용해 해결한다. 따라서 보다 자바에 특화된 직관적인 형태의 인터페이스를 제공하는 XML 처리 도구이다(참고 자료 6). 또 일반적으로 저성능에 메모리를 많이 차지하는 DOM 파서에 비해 매우 적은 메모리를 사용하며, 속도도 SAX 파서를 사용하는 경우와 필적할 만큼 빠르다.

JDOM은 API가 작고 간단해 쉽게 사용할 수 있다(<리스트 6>). 이를 <리스트 1>과 비교해 보자. 우선은 java.util의 컬렉션 클래스를 그대로 사용하며, 상대적으로 일반적인 자바 객체를 다루는 것처럼 작업할 수 있음을 알 수 있다.

문제는 일반적으로 JDOM이 아닌 DOM 객체나 SAX 이벤트가 응용 프로그램 내에서 XML 문서를 전달하는 수단이라는 점인데, JD OM은 이를 위한 배려도 잊지 않고 있다. org.jdom.output 패키지 안에 있는 DOM Outputter나 SAXOutputter(아직 구현되지 않았음) 등을 이용하면 쉽게 DOM이나 SAX로 바꿀 수 있다. 또 SAX Builder 대신 DOMBuilder를 사용하면 DOM 구조를 직접 JDOM으로 바꿀 수도 있다.

참고로 이 글을 쓰는 현재 JDOM은 1.0 베타 5까지 나와 있다. 따라서 JDOM 사이트에는 미리 컴파일해 둔 바이너리는 물론 API 문서도 제대로 올라와 있지 않다. 불행히도 직접 라이브러리와 API 문서(javadoc으로 소스코드에서 생성)를 생성해야 한다.

오라클의 XML 클래스 생성기

오라클의 XML 클래스 생성기는 DTD로부터 DTD에 정의된 문서 구조를 반영하는 자바 클래스를 생성해 준다. 단, 앞서 언급한 바와 같이 이 도구는 절름발이이다. 왜냐하면 메모리에 자바 객체로 XML 문서를 표현하고 DTD에 맞는지 점검한 뒤 다시 XML 파일로 바꿀 수 있을 뿐, XML 파일로부터 거꾸로 생성된 객체들의 구조를 생성해 주지는 못하기 때문이다. 물론 이 기능도 유용하다고 할 수 있지만, XML 데이터 바인딩이 줄 편의를 생각하면 여러 가지로 부족한 면이 없지 않다. 이 글에서 클래스 생성기를 소개하는 주된 이유는 XML 문서의 구조를 반영한 클래스를 사용하는 것이 얼마나 편리한가를 보여주기 위해서다. 참고로 이 생성기는 오라클의 XML 파서에 의존한다. 즉, 클래스 생성기나 이것으로 생성된 코드를 사용하기 위해서는 반드시 오라클 파서가 설치돼 있어야 한다(클래스 생성기만 내려 받아도 그 안에 포함되어 있다). 이제 실제 예를 통해 살펴보도록 하자.

우선 가장 먼저 소개한 XML 소스코드에 대한 DTD가 필요한데, 그 내용은 다음과 같다.

<!ELEMENT student-file (student*)>
<!ELEMENT student (name, id)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT id (#PCDATA)>

다음으로 클래스 생성기를 실행해야 하지만 불행히도 javac와 같이 별도 명령으로 제공하는 것이 아니므로 직접 프로그램을 작성해야 한다. 여기서는 일을 간단히 하기 위해 클래스 생성기에 따라오는 예제를 이용하도록 한다. SampleMain.java가 그것으로, 클래스 생성기 zip 파일을 풀면 sample 디렉토리 아래 위치해 있다.

java SampleMain -root student-file student-file.dtd

앞의 명령에서 “-root”는 외부 DTD인 경우에 루트 요소를 지정하기 위해 필요하다. 이렇게 생성된 파일들이 바로 Student_file.java, Student.java, Name.java, Id.java, Student_file_dtd.txt(이 파일은 XML 파일에 포함된 경우에 특히 중요하다. 내용은 DTD 정의와 거의 동일)이다. <리스트 7>은 이들 객체를 이용해 새로운 XML 파일을 만드는 예제이며, <리스트 8>은 이를 실행한 결과이다.

<리스트 7>에서 주의할 부분은 주석 처리된 내용으로, 이 부분을 다시 넣을 경우 validateContent()에서 예외가 발생한다. 이는 메모리에서 해당 객체들이 DTD에 합당한 문서를 구성하고 있는가를 점검하기 때문이다. XML 편집기 같은 소프트웨어는 사용자가 편집하는 내용이 그때그때 DTD에 만족하는지를 점검할 필요가 있을 경우에 상당히 유용하다.

참고로 Xerces의 org.apache.xerces.parsers.Revalidating DOMParser도 이런 용도에 사용할 수 있다. validate(Node)라는 메쏘드가 그 역할을 수행하는 메쏘드이다. 이것 역시 일반적인 XML 문서 편집기를 만들거나 다른 데이터로부터 XML을 만드는 경우, 실제 XML 파일을 출력해서 다시 파싱하지 않고도 DTD가 정하고 있는 구조적 조건을 만족하는지 확인할 수 있도록 해 준다.

도구 연마는 각자의 몫

지금까지 XML 문서를 처리하기 위한 기본적인 도구들을 비교해 살펴봤다. ‘언제 어떤 도구를 사용할 것인가’가 얼마나 응용 프로그램에 영향을 미칠 수 있는지 충분히 전달됐으리라 생각한다. 또 DOM의 경우에서와 같이 같은 도구라도 어떤 방식으로 사용하는가에 따라 응용 프로그램의 복잡도를 높이기도 낮추기도 한다는 것도 잘 알았으리라 믿는다. 결국 어떤 문제든지 흔히 발생하는 경우를 쉽게 해결할 수 있도록 도구를 만들어 두고, 프로그래밍 패턴을 정리해두는 것이 성공의 열쇠이다.

마지막으로 이 글에서 제시한 일부 도구들은 아직 충분히 다듬어지지 않았다. 이를 테면 네임스페이스를 활용하는 경우 다소 불편한 부분이 있을 지도 모르겠다. 날이 서지 않은 도구를 갈아 날이 서게 하는 것은 독자들의 몫이다.

필자 연락처 : 김도형 dynaxis@4dl.com
정리 : 박은정 whoami@sbmedia.co.kr　

* XML Schema는 DTD를 실무에 활용하면서 나타난 기능상의 부족한 점을 개선하기 위하여 만들어졌다. 예를 들면 DTD에는 자료형이 없고 좀 덜 체계적이다.

* XML Schema의 작성

1. level1 : 기본적인 XML Schema 작성

2. level2

3. level3

* XML Schema의 잡다한 기능들

Group, choice, union, annotation드을 이해

* Summary

1. XML Schema는 DTD의 단점을 극복하기 위하여 만들어진 것으로

- 다양한 기본자료형의 제공

- 복합자료형의 제공

- program과 유사한 추상과 기능을 제공한다.

2. XML Schema는 기본적인 제작방법이 없으며, 작성자의 취향에 따라 다양한 모습으로 제작될 수 있다.

3. XML Schema는 DTD를 대신하는 기술이고, 많은 장점이 있기 때문에 반드시 이해해야 한다.

* XSL이란 무엇인가?

XML 문서를 Web Browser에서 볼 수 있도록 만든 기술

많은 기술들이 XSL을 바탕으로 파생되기 때문에 중요하다.

XML이 정보 그 자체를 나타낸다면 XSL은 보여줄때 어떤 형식, 어떤 포멧으로 보여줄 것인지를 결정한다. 이를 위해서 CSS와 XSL 기술이 존재하는데 CSS은 event-driven 방식(user가 액션을 취했을 경우 적용)이고 XSL은 programming-driver 방식(그 자체가 언어처럼 기술) 이다.

실제로는 CSS가 더 중요한 기술이다.

* XSL ---------XSLT : XML 문서를 변환할 때 사용되는 기술

             |

             |----- XML-FO(XSLF) : XML 문서를 report로 print할 경우 사용되는 기술

* Namespace

왜 만들어 졌는가? : Namespace란 XML문서내의 element가 중복될 경우를 피하기 위하여 만들어졌다.

사용방법 과 Range에 대한 내용도 정리가 필요

* XSL에 있어서 가장 중요한 key point는 XSL 문서는 element 단위로 서술하며 element 단위 하나가 처리 process 임을 상기해야 된다.

* XLL : 아직 표준은 아니지만 앞으로 표준으로 될 가능성이 있다.

XLL ------------- X Pointer : 동일한 문서내에서의 이동

                |

                |------ X Link : 서로 다른 page로 이동

* web : 정보전달을 서비스

   internet : 망의 개념

  web의 가장 큰 목적은 정보공유로써 현재까지의 web의 주류는 사람이 눈으로 읽는것. 즉

  human-oriented 이나 앞으로는 사람대신 기계가 대신 읽어서 summary(요약) 해 주는 형태의

  machine-oriented로 발전할 것이다.

* XML 강의에서 앞으로 배울 내용들

 - XML 그 자체

요약하는 기술 : XML Schema

                      DTD

Link : XLink/XPointer

XML을 WebBrowser로 보여주기 위한 기술 : XSL, CSS

- XML 변형 : XSLT, SAX/DOM

- XML 응용사례

       VoiceXML (음성)

       XVL : button, list box등의 UI

       SVG : 모든 chart에 대해 XML로 표현

       UML -> XMI : 아직 완전히 정립되지 않았음

       LogML -> log를 XML형태로 남긴다.

* 기존의 HTML은 보여주는 거에 초점을 맞추었지만 XML은 정보 그 자체에 초점을 맞춘다.

   현재의 web은 너무 데이타가 많아서 검색에 드는 비용도 많을 뿐더러 그걸 일일히 하나씩

  확인하기에는 너무나 힘든 작업이다. 이런 정보들은 쓰레기와 다를바 없다.

* XML 의 원리

- 기계가 사람을 대신하여 문서를 읽을 수  있도록 구조화하는 것

- 인간의 지식도 대부분 XML로 표현 가능하다.

- 인간의 사상들을 문장으로 표현할 수 있고 이를 XML로 표현하는 것도 가능하다.

* DTD가 나오게 된 배경

- 어떤 채소가게 주인이 XML을 만들어 데이타를 관리하는 것을 보고 옆에 있던 정육점 주인도

따라 하고 싶었졌다. 그래서 채소가게 주인에게 XML 좀 달라고 했다.

이때 어떤 문제가 생길까?

고객의 데이타가 넘어가서 문제가 생길 것이다.

이를 위해서 XML의 구조를 정의하는 것이 필요했는데 이를 DTD라고 한다.

* 과제로 적당한 예제

- 메모지를 XML로 표현

- 결제 양식을 XML로 표현

* SYSTEM - 내가 만들었다.

   PUBLIC - 남이 만든 DTD를 link할 때

* XML의 경우의 수

1. DTD 없는 간단한 XML

2. DTD가 XML 문장내에 포함

3. DTD가 다른 파일로 존재하고 XML에서는 링크

*

#PCDATA - 데이타

#CDATA - 데이타 값에 < 가 들어가 있을 경우, 교수님도 지금까지 써 본적이 없다.

*

#IMPLIED - 값을 줘도 되고 안 줘도 된다.

* 일반개체 -> XML 문서내에 반복되는 pattern을 치환하고자 할 때

* 매개변수개체 -> DTD내의 반복되는 pattern을 치환하고자 할 때

* DTD의 응용사례 - cXML

B2B는 회사와 회사간에 자료를 교환할 때 문서의 표준이 중요하다. 그런데 A라는 회사와

B라는 회사가 있을 경우 서로 자기들 표준을 채택할려고 해서 문제가 발생한다.

cXML은 Ariba라는 회사에서 만든 회사와 회사간의 자료를 교환할 때 사용하는 표준이다.

이 회사는 지금은 망했지만 아직 cXML은 여전히 쓰이고 있다.

- 수업은 XML File 교재 활용

- Advanced XML 은 다음학기 강의 예정

- chominhokr@korea.com 으로 메일 전송

- 다음주 부터 수업은 7시 30분에 시작

* client와 server의 구분

- 역할에 따라 구분

- client : 요청하는 놈

- server : 요청받고 응답하는 놈

* Browser 란 무엇인가?

- tag를 해석해서 tag의 의미를 화면에 보여주는 역할을 한다.

- 어떤 tag를 해석하느냐에 따라

- Web Browser : HTML tag 해석

- WAP Browser : wml

* Architecture란 무엇인가?

- 구성요소와 요소간의 상호관계를 정의한 것

* tier - Roll에 따라 구분

* XML의 등장

- 똑같은 페이지를 Web Browser를 위해서 html로 만들고 핸드폰과 같은 무선 client를 위해서

wml로 만드는 것은 불합리하다.

- 가장 중요한 이유는 현재의 web은 정보를 얻기 위해 문서를 확인해야 된다.

이것은 1년마다 10배씩 폭발적으로 증가하는 데이타를 검색하는 데 한계가 있다.

* 현재의 internet : Human - Oriented Internet (사람이 직접 읽어서 정보를 얻는다.)

미래의 internet : Machine - Oriented Internet (사람은 찾고자 하는 정보에 대한 검색조건만 입력하면 컴퓨터가 알아서 최적의 결과를 보여준다.)

* 쿠키

1. 쿠키를 저장할 때 document.cookie = "쿠키정보"형식을 사용하는데,

    쿠키 정보 중 꼭 입력해야 하는것이 name이다.

2. 쿠키정보를 다른 사람이 쉽게 알아볼 수 없게 암호화시키는 과정을

    인코딩이라고 하며 escape(쿠키정보)형식으로 사용함.

3. 쿠키정보중 expires는 쿠키의 유효기간을 나타내며, 이 시간이 되면 쿠키는 자동 소멸된다.

    이기간을 정해 두지 않을 경우, 쿠키는 계속해 디스크에 남아있게 된다.

================== 예제 소스 시작 ======================================================

사용자가 ' 하루 동안 보지 않겠다'고 체크하면 그 정보를 쿠키로 저장해 두었다가, 메인 창에서 새창을 열기전에 쿠키부터 확인하는 것이다.

쿠키정보는 팝업창 뿐만 아니라 팝업창의 부모창에도 들어가야한다.

여기선 팝업창을 gongi.html이라하고 부모창을 main.html이라하겠다.

근데 중간중간 소스 해석하기 무지어렵구먼....

선생님이 직접 작성한 소스가 아니라 선생님도 자세한 해석은 안해주심... -.@;

gongi.html  ============================

<script language=""Javascript">
<!--
function closeWin()
{
  if(document.forms[0].Notice.checked)
  {
     setCookie("Notice","done",1);
   self.close();
   }
}

function setCookie(name,value,expiredays)
{
  var todayDate = new Date();
  todayDate.setDate(todayDate.getDate() + expiredays);  // expiredays는 쿠키유효기간
  document.cookie = name + "=" + escape(value) + "; path=/; expired="
  todayDate.toGMTString() + ";"  // 쿠키정보 암호화 

}

// -->
</script>

<form>
       <TD background ="images/gongji_08.gif" WIDTH=308 HEIGHT=44>
  <input type="checkbox" name="Notice" value="ok">
  <font size="2">하루 동안 창 열리지 않음</font>&nbsp;
  <input type="button"  value="닫기" onClick="closeWin()">
    </TD>
  </form>

main.html ============================

<SCRIPT LANGUAGE="JavaScript">
<!--

function setCookie(name,value,expiredays)
{
  var todayDate = new Date();
  todayDate.setDate(todayDate.getDate() + expiredays);
  document.cookie = name + "=" + escape(value) + "; path=/; expired="
  todayDate.toGMTString() + ";" // path= 는쿠키가 저장될 위치 , 위치지정안하면 웹문서가 있는폴더로 저장된다.
}

function getCookie(name)
{
  var nameOfCookie = name + "=";
  var x = 0;
  while(x <= document.cookie.length)
  {
    var y = (x+nameOfCookie.length);
 if(document.cookie.substring(x,y) == nameOfCookie)
 {
   if((endOfCookie=document.cookie.indexOf(";",y)) == -1)
      {
        endOfCookie = document.cookie.length;
      }
   return unescape(document.cookie.substring(y,endOfCookie));
 }
     x= document.cookie.indexOf(" ", x) + 1;
  if(x==0)
     break;
  }
   return " ";
}

if(getCookie("Notice") !="done")
{ 
noticeWindow = window.open('gongji.html',"공지","width=400,height=450,top=0,left=0,menubar=no,resizable=no,status=no,toolbar=no,location=no,scrolls=no,directories=no"); 

noticeWindow.opener = self;
}
// -->
</SCRIPT>

================== 예제 소스 끝 ===================================================

1.메인 페이지

<head>
<script language="javascript">

 <!--

 function getCookie( name ){

         var nameOfCookie = name + "=";
         var x = 0;

         while ( x <= document.cookie.length ) {

                 var y = (x+nameOfCookie.length);

                 if ( document.cookie.substring( x, y ) == nameOfCookie ) {
                         if ( (endOfCookie=document.cookie.indexOf( ";", y )) == -1 )
                                 endOfCookie = document.cookie.length;
                         return unescape( document.cookie.substring( y, endOfCookie ) );
                 }
                 x = document.cookie.indexOf( " ", x ) + 1;

                 if ( x == 0 ) break;
         }
         return "";
 }

 if ( getCookie( "Notice" ) != "check" ) {
         noticeWindow  =  window.open('newwin.htm','notice','left=0, top=0, width=250,height=300');
 }

 // -->

</script>
</head>

2.공지 창(newwin.htm)

<html>
 <head>
 <SCRIPT language="JavaScript">
  <!--
 
  // 쿠키를 만듭니다. 아래 closeWin() 함수에서 호출됩니다
  function setCookie( name, value, expiredays )
  {
          var todayDate = new Date();

          todayDate.setDate( todayDate.getDate() + expiredays );

          document.cookie = name + "=" + escape( value ) + "; path=/; expires=" + todayDate.toGMTString() + ";"

          }

 
  // 체크후 닫기버튼을 눌렀을때 쿠키를 만들고 창을 닫습니다

  function closeWin()
  {
          if ( document.pop.Notice.checked )

           setCookie( "Notice", "check" , 1);  // 오른쪽 숫자는 쿠키를 유지할 기간을 설정합니다

          self.close(); //자기자신을 닫습니다
  }
  // -->
</SCRIPT>
</head>

<form name=pop>
<input type=checkbox name="Notice" value="" onclick="javascript:closeWin();">
<font size=1>오늘 하루 열지 않기
</form>

특정 js 파일에서 다른 js 파일을 참조하기 위해서는 필요한 js를 먼저 로딩할 수 있어야 한다.
이러한 방법에는 몇 가지가 알려져 있다.

1. script 엘리먼트를 만들어서 현  문서에 추가한다. (A)
   var scr = document.createElement("script");
   scr.src = "a.js";
   document.getElementsByTagName("head")[0].appendChild(scr);
   
2. document.write / innerHTML을 이용한 직접 태그를 추가한다. (B)
   document.write("<script type='text/javascript' src='b.js'><"+"/script>");
   
3. 기타 등등.. (현재 기억 안남)

그러나 위의 방법 중 어떠한 것을 사용해도 수행의 순서를 원하는대로 제어할 수는 없다.
파싱은 기본적으로 다음과 같은 순서로 진행된다. 설명에 사용될 call.js 에는 위에서 설명한 스크립트를 로딩하는 루틴이 모두 포함되어 있다고 가정한다.

1. html 페이지를 순차적으로 파싱한다.
2. html 페이지에서 <script src="call.js">태그를 만나면 call.js 파일을 읽어들인다.
3. call.js 에서 위에 설명한 방법으로 스크립트를 로딩하는 루틴 A를 만나면 call.js 파싱이 모두 끝난 후 A에서 지정한 파일을 읽어들인다.
4. call.js 내에서 루틴 B를 만나면 html 페이지를 모두 파싱한 후에야 B에서 지정한 js 파일을 읽어들인다.

call.js :
(A 루틴)
(B 루틴)
window.alert("call.js");

a.js :
window.alert("a.js");

b.js :
window.alert("b.js");

라고 각각 쓰여져 있으면,  alert이 나타나는 순서는 call.js, a.js, b.js 순서이다. 아무리 A루틴과 B루틴이 call.js 를 표시하는 루틴보다 앞에 있지만, 파싱 순서상 절대 앞에 나오지 않는다.

즉, 위의 방법으로는 어떤 방법을 써도 브라우저는 먼저 현 페이지의 스크립트를 파싱하고 진행한다.

수행제어를 위한 유일한 돌파구는 SJAX 이다 (비동기가 AJAX니까... ;; 동기식은 S(ynchronous)JAX ;;;)
아래 코드는 IE6, FF2.0에서 테스트되었다.
(참고로, dojo 소스를 보아하니 ipv6관련 지원 문제로 uri 파싱도 수정이 가해져야 하는 듯하다. 오마이갓.)

활용은 다음과 같은 형태로 한다.
eval(require_once("/some_path/some.js", true));

해결해야 할 과제.

1. 어떻게 하면 eval을 쓰지 않게 할 수 있는지.

해결된 과제

1. require 대상 js 파일의 경로를 이 js 파일로부터 어떻게 하면 상대경로로 잡을 수 있는지.

요즈음 ActiveX, 정확히는 'ActiveX 컨트롤'이란 기술이 시끄럽다. 브라우저 밑으로 손을 뻗어 그 밑에 깔린 시스템의 기능을 만지작거릴 수 있게 하는 요물. 웹은 웹이로되 PC가 할 수 있는 모든 일을 하게끔 하는, 웹을 웹 이상으로 조작하기 위한 '만능 컨트롤' 도구, ActiveX. 90년대의 프로그래머들은 ActiveX가 포함된 COM이라는 테크놀로지 조합으로 PC 전성기를 풍미했다.

그런데 새 버전의 인터넷 익스플로러와 새 OS 윈도우 비스타는 자신들의 기술 ActiveX를 유리 상자 안에 가둬 버리고 만다. ActiveX란 뭐든지 만들 수 있지만, 뭐든지 망칠 수도 있는 양날의 검이었다. 새 플랫폼이 ActiveX에 거리를 두는 이유는 '시스템의 기능을 만지작거리는 일'이 악인에 의해서도 자행될 수 있다는 자각 때문이다. ActiveX는 모두가 순박했던 목가적 시절에나 어울리는 기술이었던 것이다.

게다가 이미 업계는 웹을 임의로 '컨트롤'하여 변경하는 일이 그리 바람직한 일도 아님을 공감하고 있다. 웹 표준 운동도 그 일환이다. ActiveX같은 로우레벨 아키텍처에 의존한 플랫폼을 만드는 일이란 플래시 수준의 입지를 지닌 플랫폼 제공자가 아니라면 비즈니스적으로도 별 의미가 없다는 것을 깨달았다. 마치 고급 언어를 배운 이래 어셈블리어를 만질 필요가 없듯, 굳이 웹을 개선한다는 목적만으로는 ActiveX라는 위험한 칼을 만질 이유가 없는 것이다.

물론 아이디어란 표준으로 묶어 놓기에는 너무나 자유분방한 것이기에, 올해도 내년에도 웹의 확장은 일어날 것이다. 그렇기에 웹을 초월한 무언가를 덧붙이려는 확장 욕구는 건전한 것이다. 브라우저로 하지 못하는 일을 새로운 아이디어로 '확장'하려는 욕망은 멈추기 힘들고, 이 점을 강조하기 위해서 일까? 파이어폭스가 ActiveX '컨트롤(Controls)'을 금지하고 대신 파이어폭스 '확장(Extension)'이란 개념을 도입한 의도는 그 용어에 잘 나타나 있다. 마이크로소프트도 이미 닷넷을 중심으로 기술 구조를 재편한지 오래다. ActiveX를 위시한 Win32의 리거시 기술들은 배후로 밀려나고, 웹의 확장 기능도 ActiveX라는 칼을 직접 만지지 않도록 유도하고 있다. 더 편하고 더 쉬운 확장을 할 수 있는 방안과 로드맵이 따로 있는 것이다.

그러나 우리는 유난히 ActiveX라는 날카로운 칼을 좋아했다. 그리고 무척이나 잘 드는 이 칼로 웹을 확장한 것이 아니라 오히려 웹의 여기저기를 도려내며 우리만의 아키텍처를 만들었다. 대한민국의 웹을 서핑하다 만나게 되는 수 없는 경고창들, 칼을 조심하라는 시스템의 경고지만 개의치 않는다. 수저가 필요한 곳에 칼이 놓이고 있다. 손잡이가 필요한 곳에 날이 서 있다.

칼날이 난무한다. 특히 은행 일이라도 한번 보려면 여러 개의 컨트롤을 일단 깔아댄다. 뭐가 뭔지 도무지 모르겠지만, 여하튼 설치하지 않으면 아무 것도 못하니 방법이 없다. 게다가 왜 이렇게 회사마다 종류가 골고루인지. 그렇게 내 PC를 유린하듯 설치되는 컨트롤의 면모는 살펴 보니 하나 같이 '보안 모듈'.

여기에서 의문이 생긴다. 왜 보안을 웹의 외부 기능에 의존해야 하는 것인가? 사실을 말하자면, 한국 수준의 보안은 모르겠으나 적어도 세계 수준의 보안은 브라우저 만으로도 얼마든지 확보할 수 있다. 외국 굴지의 은행들은 브라우저만으로 인터넷 뱅킹을 무리 없이 수행하고 있다. IE와 파이어폭스 모두 필요 충분한 수준의 암호화 기능은 물론 인증서 관리 기능도 들어 있다.

[배포버전이름]

#cat /etc/redhat-release

[리눅스버전]

#cat /proc/version

[cpu]

#cat /proc/cpuinfo

[memory]

#cat /proc/meminfo

1. 사회 정의에 부합하며, 도덕적으로 옳은 일입니다.

// 메인

 function server_stop() {
   var popup_stop = getCookie('popup_stop');
    if(popup_stop != 1){
     server_stop = '/notice/070711/server_stop.jsp';
     window.open(server_stop,'stop','width=420, height=335, left=0, top=100');
    }
 }

//메인하단

<script>
 server_stop();
</script>

//check_cookies.js

function makeCookie2(cookieName,cookieData){
 if (cookieData != "")
 {
     var expiry = new Date();
     expiry.setTime(expiry.getTime() + (24 * 60 * 60 * 1000));
     setCookie(cookieName, cookieData, expiry);
 }
}

function setCookie(cookieName, cookieData, expiry){
// document.cookie = cookieName + "=" + cookieData + ";domain=.ktedi.com;path=/;expires=" + expiry.toGMTString();
 document.cookie = cookieName + "=" + cookieData + ";path=/;expires=" + expiry.toGMTString();
}

function getCookie(varname) {

 startpos = document.cookie.indexOf(varname);

 if (startpos >= 0) {
  startpos += varname.length;
  endpos = document.cookie.indexOf(";", startpos);
  if (endpos == -1) endpos = document.cookie.length;
  return unescape(document.cookie.substring(startpos+1, endpos));
 } else{
  return '';
 }

}

어젯 밤 6시40분부터 거의8시까지 우리나라의 대부분의 국민들이 본 프로그램은 바로 "무한 도전 지구특공대편"
이날 무한도전은 지구특공대가 되어 일반 시민들을 도와준다는 컨셉...
무한도전에 재미를 더해 이제는 공익성을 더하는듯...

4일 시청률 조사회사 TNS미디어코리아에 따르면 지난 3일 방송된 `무한도전`은 22.3%(이하 동일기준)의 시청률을 기록했다.

P/S
움직이는?
깜빡이는?
제목을 정하기가 좀 어려운데, 어쨋거나 기존의 정적인 아이콘에 비해 동적으로 바뀌었으니, 움직이는 아이콘이라고 표현하는 수 밖에..
다운로드는 마우스 오른쪽을 이용하면 되는 것이라 별 다른 링크는 제공하지 않음..