공룡호가 사는 세상 이야기

XML은 이제 선택이 아니라 필수가 되어가고 있다.
구조적인 문서와 데이터를 교환하기 위한 통신 형식으로 충분한 계획/설계 없이 개발 중에 즉흥적으로 선택하는 경우가 많다. 올바른 XML 형식의 설계가 선행되어야, 통신에 참여하는 모든 이들의 요구를 만족시킬 수 있다. 한 개의 XML 스키마를 유지보수 하는 일은 상대적으로 간단하다. 그러나 수백 개 조직에 영향을 미치는 변화는 엄청난 충격이 될 수 있다. 이번 아티클에서는 이 충격을 관리하고 최소화 하는 두 가지 논제에 대해 다룬다.

원문 : http://www.ibm.com/developerworks/kr/library/x-extensxml.html

 

지난 2달간, Ajax에서 XML을 처리하는 방법(Part 1, Part 2)을 리뷰했었다.
이제 연재의 마지막인 Part 3가 소개되었다.
Part 1 링크 : http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt1
Part 2 링크 : http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt2

1. DOM 트리 탐색 - Part 1
2. 서버쪽 XSLT - Part 2
3. 클라이언트쪽 XSLT - Part 2
4. JSON과 동적 스크립트 태그

Part 3에서는 JSON과 동적 스크립트 태그를 이용하는 방법을 알아본다.
위 1,2,3 방식 모두 Ajax 에서 자바스크립트 XMLHttpRequest 객체를 사용하는 방법이었다. 즉, 모두 일종의 웹 프록시를 사용하여 원격지 서버의 XML 데이터를 가져오는 방법으로 Ajax의 '같은 도메인'문제를 해결했다.
Part 1에서도 언급되었고, Part 3에서도 잠깐 언급하고 있는데 '같은 도메인'문제는 Ajax프로그램이 원래 페이지를 가져온 서버로만 XMLHttp Request를 보내야 한다는 보안 제약을 말한다. 그러나 현실적으로는 Ajax 프로그램에서 가져오는 정보는 한 서버에 국한되지 않는다. 그래서 흔히 웹 서버 구성을 변경하거나 특수한 스크립트를 생성하는 방법으로 '같은 도메인' 문제를 해결한다.
그러나, 또 다른 방법이 있다. 해당 문제를 우회하여 프로그래머가 위와같은 제약사항에 신경쓸 필요가 없다.
Part 3에서는 JSON을 이용하여 이 문제를 해결한다.

JSON은 JavaScript Object Notation 을 줄인 약자로, 자바스크립트 언어가 기본적으로 이해하는 자료 형식이다. XML과는 달리, JSON은 자바스크립트 코드이므로 별도의 구문 분석이 필요 없다.
Part 1, 2에서도 그랬듯 날씨 정보 NWS(XML)을 가져와 야후 파이프를 이용, JSON으로 변환한다.

그림: 야후 파이프
야후 파이프 편집기

JSON으로 변환 후, 해당 변수에 할당하면 코드 내에서 바로 참조가 가능하게 된다.
전체 파이프 라인을 보면 다음과 같다.

접근 방식 4가 따르는 파이프라인

자세한 방법 및 수순은 아래 링크에서 확인하도록 하자. 더불어 각 방법의 장단점에 대해서 고민해 보고,
해당 방법을 변형하여 새로운 접근을 만들어 낼 수도 있을 것이다.

Part 3 링크 : http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt3/

지난 달에 'Ajax에서 XML 처리하기, Part 2' 을 리뷰했었다. 그 때는 DOM 트리 탐색 방법을 이용한 예제를 사용했었는데, 기다렸던 대로 Part 2가 소개되었다.
(Part 1 링크: http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt1/)

1. DOM 트리 탐색
2. 서버쪽 XSLT
3. 클라이언트쪽 XSLT
4. JSON과 동적 스크립트 태그

Part 2 에서는 2,3번 방법을 살펴본다. 모두 XSLT를 사용한다는 공통점이 있다.

Part 1 : DOM 트리 탐색 방법
접근 방법 1을 위한 자료 파이프라인

Part 2 : 서버쪽 XSLT
접근 방식 2가 따르는 자료 파이프라인

Part 2 : 클라이언트쪽 XSLT
접근 방식 3이 따르는 자료 파이프라인

3가지 방식은 비슷하나 조금씩 다른 면이 있다.
간단한 예제라면 브라우저에 아무런 부담이 없겠지만 XML 이 커지면 문제는 달라진다.
또한, 사용자가 사용하는 브라우저와 컴퓨터도 고려해야 한다.
어떤 방법을 사용할 것인가는 각기 다른 모델에 대한 충분한 이해와 적용하는 환경에 따라 선택해야 할 것이다.

좀 더 자세한 설명과 튜토리얼은 아래 링크로.
http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt2/

이제, XML은 선택이 아니라 필수가 되어가고 있다.
Ajax에서 XML데이터를 처리하는 방법은 제각기 다르다. 무식하게 엘리멘트/노드 들을 파싱하는 단순 노가다의 반복부터 DOM, XSLT 등을 이용하는 방법까지.
과연 어떤 방법으로 XML을 다루는 것이 좋을까? 정답은 '없다'다. 모든 것은 상황에 따라 변하니까.
하지만, 최적의 방법을 선택하기 위해서는 많은 방법들을 알고 있어야 하며, 그 방법들의 장/단점에 대해서도 알고 있어야 함은 물론이다.

dW에서 이달 초에 다룬 기사 중에서 이러한 접근을 보다 수월하게 가능케 해 주는 기사가 있어 소개코자 한다.
XML을 처리하는 Ajax 뱃지(위젯)을 간단하게 작성하는 과정을 다루는데, 다음 4가지 방법으로 XML에 접근한다.

링크: http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt1/

1. DOM 트리 탐색
2. 서버쪽 XSLT
3. 클라이언트쪽 XSLT
4. JSON과 동적 스크립트 태그

Ajax 날씨 뱃지

Part 1에서는 DOM 트리 탐색 방법을 이용하고 있는데, 사실은 2,3,4번 방법이 업데이트 되면 비교해서 리뷰하려 했지만 아직 소식이 없다.(곧 업데이트 될 듯 한데, Part 2에서는 2,3번 방법을 다룬단다.) 접근 방법 1을 위한 데이터 라인을 보면 다음과 같다.
접근 방법 1을 위한 자료 파이프라인

대충 감이 오는지?
세부 내용을 읽고, 기사에서 말하는 장/단점 외에도 추가적인 부분이 있는지 고민해 보는 것도 좋을 듯.
Part 2를 기다려 보자.

링크: http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt1/

- 전통적인 RSS
RSS는 RDF site Summary, Rich Site Summary 등의 약칭으로 뉴스나 블로그와 같이 컨텐츠 업데이트가 잦은 웹사이트에서 업데이트된 정보를 사용자들에게 쉽게 제공하기 위해 XML을 기초로 만들어진 데이터 포멧이다.
기존 웹 사이트들이 서비스했던 일방적인 메일링 서비스는 해당 사이트 관리자가 일방적으로 내용을 요약하여 발송하는 수동적인 형태였다면, RSS는 하나의 웹 사이트 내에서도 원하는 카테고리의 내용만을 수집할 수 있다는 점에서보다 진보적이고 능동적인 형태를 취한다.

- 새로운 한계 RSS
이것이 많은 사람들이 RSS를 사이트 피드 같은 배급의 목적에 사용한다고 알고 있는 내용이나, 몇 년 전부터 데이터 배포나 연락처 관리와 같은 목적으로 여타 애플리케이션의 저장 포멧으로도 쓰여왔다.
즉, 데이터를 RSS 형태로 저장함으로써 RSS 수집/구독 프로그램을 데이터에 접근하는 데에도 사용할 수 있다는 의미가 되는데, 예전의 관계형 데이터에서 저장되었던 방식으로 RSS를 사용하여 정보를 저장할 수 있게 된다.

- 튜토리얼에 대해
RSS 포멧과 몇 가지 실제 피드 샘플을 소개하는 것을 시작으로 기존 포멧을 바꿔 이를 다른 목적을 위해 재정의 한다. 테이블 세 개로 데이터베이스 포멧을 정의하고 이 테이블들을 쿼리하여 전통적인 SQL SELECT 모두를 흉내낼 수 있음을 보여주고 결합적 룩업을 제공한다. 마지막으로 쿼리의 결과를 처리하거나 XML폼으로 남겨두거나 이를 XSLT를 사용하여 사용자에게 보여줄 수 있는 다양한 방법으로의 변환법에 대해서도 다루고 있다.

- 코멘트
RSS를 데이터 수집을 보다 효과적으로 하기 위한 용도로 사용되는 것이나, 대부분 웹사이트, 블로그, 뉴스 등의 기사들을 수집하는데 이용되었던 것이 사실이다. 하지만 기본 포멧만 갖춘다면 기존의 수집기를 사용하면서도 또 다른 의미를 가지는 데이터들을 효과적으로 수집/관리할 수 있게 해 줄수 있다는 점에서 재미있는 시도이다. 그리고 실제로 충분히 흥미롭다. 그룹 내에서 서로의 연락처와 그에 관련된 각종 정보들을 공유하는 방법, 일정 관리에 적용하는 방법 등 시도해 볼 만한 곳이 많을 것이다. 아래 원문의 튜토리얼과 그에 따른 참고사항을 링크한다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/x-rssdatabase/index.html
참고 : http://www.ibm.com/developerworks/kr/library/tutorial/x-rssdatabase/resources.html

이 튜토리얼을 어렵지 않게 수행해 낸 사람이라면, "사용자 정의 가능한 RSS 피드 수집기 구현하기" 기사에도 관심을 가져보기 바란다. ( http://www.ibm.com/developerworks/kr/library/wa-aj-rssphp/ )

오픈오피스가 무엇인지는 다들 알 것이다. (모르시는 분들은 살짝 검색을 -ㅁ-)
무엇이든지 오픈되어 있다는 것은 입맛대로 커스터마이징이 가능해진다는 점이 가장 큰 장점이다.
XML로 저장된 데이터로 워드 프로세싱 문서를 만들기 위해 필터를 만들 수 있다.
이번 Article은 튜토리얼(Tutorial)로 이루어져 있어 난이도는 중급에 속하나, 크게 어렵지 않을 것이다.

오픈 오피스에는 가져오기/내보내기(Import/Export)필터 기능이 존재하는데, 이것을 사용하여 일반 문서인 XML데이터를 열 수 있는 방법을 다룬다. 이를 이용하면 사용자들은 더욱 자연스럽게 문서를 편집하고,
이를 네이티브 포맷으로 다시 저장할 수 있게 된다. 또한 이 특징을 사용하여 문서를 XML데이터로 쉽게 변경이 가능해 진다.

XML 파일 포맷의 구문에 익숙하고 XSLT(XML Style Language Transformations)를 조금 다루어 본 사람이라면 오픈오피스를 XML 기반 데이터를 위한 맞춤 편집기로 사용할 때 그 발전가능성은 무궁무진하다.
이 튜토리얼에서는 XSLT필터 파일과 함께 작동하여 플러그인에서 XML형식으로 된 어떤 데이터라도 지원할 수 있도록 한다. 즉, 데이터를 기계가 처리하기 좋은 XML로 저장하면서 이를 사람에게 편한 방식으로 편집할 수 있다는 것이다. 전자는 쉬운 검색, 의미 맥락(semantic context)과 정보 찾아오기를 가능케 하고 후자는 더 높은 수준의 하이퍼텍스트 환경에서 효율적인 편집을 가능하게 한다.

먼저 XSLT에 대해서 조금 알아보자 (Article에서는 XSLT를 알고 있다는 전제를 하고 있으므로)

XSLT는 XML문서에 XSLT를 적용하여 또다른 XML, HTML, TXT등으로 변환하는 방법을 기술한 표준 방법이다. 확장 스타일시트 언어(XSL)의 확장으로서 XML문서가 다른 데이터 형식으로 재구성되는 방법이라고 간단히 보면 된다. 자세한 내용을 일일이 열거하기에는 어렵고 XSL에 대한 이해가 부족한 사람은 아래 링크에서 간단히 학습을 하면 이번 튜토리얼을 따라하는데 큰 어려움이 없을 것이다.

IBM XSLT 입문 : http://www.ibm.com/developerworks/kr/library/tutorial/x-xsltopenoff/section3.html
Lecture #1 : http://cafe.naver.com/javalove/217
Lecture #2 : http://cafe.naver.com/javalove/218
Lecture #3 : http://cafe.naver.com/javalove/219
Lecture #4 : http://cafe.naver.com/javalove/220

이제 XSL이 무엇인지 어느정도 이해할 수 있을 것이다. 그럼 이번 튜토리얼을 따라하기 위해,
다음과 같은 것이 필요하다.
오픈오피스 2.0(+), 이번 예제에는 2.2를 사용한다. 리눅스 용, 윈도우 용 모두 상관없다.
XML편집기는 XML과 XSLT파일을 편집할 수 있어야 한다. 기본적인 Text Editor라면 상관없다 유닉스에서는 vim.
순서는 다음과 같이 진행된다.

  • 개요
  • XSLT입문
  • 가져오기 필터
  • 내보내기 필터와 다른 포맷으로 내보내기
  • 요약
  • 다운로드
  • 참고자료
  • 필자소개

튜토리얼이 자세하게 나와 있어(XSL에 대한 부분이 조금 약하긴 하지만), 1시간만에 튜토리얼을 따라할 수 있었다. XML의 모든 장점을 가지면서도 리치 텍스트 편집을 쉽게 가능하게 해 준다.
XML을 사랑하고 오픈오피스를 사용하는 사람이라면, 한번쯤 꿈꿔본 일이 아닐까.
또한, XSLT를 사용하면 편집된 문서를 어떻게 XML이 아닌 포맷으로 내보낼 수 있는지도 설명되어 있다.
XML이라는 것을 가장 처음 접했을 때가 00년도였다. 7년이 지난 지금 XML의 중요성은 날이갈 수록 증대되고 있는데 웹의 발전과 더불어 XML은 의외로 많은 것들을 가능하게 해 줄 것이다.
이전에 리뷰했던 VXML또한 그것의 일부가 아닐까?

다음 링크를 클릭하고, 커피 한잔, 그리고 비스켓을 씹으면서 따라해 보자-
링크 : http://www.ibm.com/developerworks/kr/library/tutorial/x-xsltopenoff/index.html

논문 심사도 끝났겠다, 막바지 포스팅 그 첫번째-_ - 이거 완전 벼락치기 아닌가.. ㅠㅠ

IBM developerWorks에서 일전에 꽤나 흥미롭게 읽어 보았던 음성 실행 XML 에 관련된 기사가 Part4를 마지막으로 연재가 종료되었는데 Part1, 2, 3, 4의 근간이 되는 VXML에 대해서 간단히 알아보고, 이 중 하나에 대해서 좀 더 알아보기로 하자.

키워드는 VXML이다.
VXML은, VoiceXML 이라고 하는데, XML Output 표준에 주어진 이름이며 파일 포멧은 VXML이다.
VXML은 VoiceXML Content를 텍스트[Text-To-Speech (TTS)]로 변환하는 VoiceXML 브라우저와 결합하며, 음성 명령을 인식하는 것 또한 가능하다. (IBM dW)

VXML은 XML의 일종으로, 대화형 음성입출력 방식을 규정한 국제 표준 기술이며, 1999년 3월에 AT&T, IBM, 모토로라, 루슨트테크놀러지 등의 주도로 'VoiceXML 포럼'이 발족됐고 2000년 5월에 W3C에 의해 WWW의 대화형 Markup Language 표준으로 공인되었다.
VXML은 음성 서비스 시나리오 저작자를 갖가지 문제에서 해방시켜 서비스 내용 그 자체에만 집중할 수 있도록 해 준다. 지금까지 음성 서비스 구현과정과는 달리 VXML문서로 음성 서비스 시나리오를 작성한 사람은 음성 입출력의 기술적인 문제에 대해 거의 알 필요가 없기 때문이다.
또한, 시나리오를 통해 전달할 정보의 창출과정이나 수집한 정보의 처리과정은 웹서버에 연결된 CGI나 DB등을 통해 가능하므로 대화 시나리오 저작자는 서비스 로직으로부터 독립될 수 있다. 쉬운 저작이 가능하고 온갖 복잡한 상황을 표현하기에 별다른 어려움이 없는 VXML의 문법체계 또한 저작자에게 큰 도움이 된다.
나아가 VXML은 컨텐츠 구축에 소요되는 인력을 크게 줄여 음성 포털의 실현을 가능하게 해 줄 것으로 기대된다. 또한 VXML 문서형식은 XML에 내포된 태그 형식을 갖는 텍스트 파일로서 읽기 쉽고 의미가 명확하며, 프로그래밍을 경험해 본 사람이 조금만 노력을 기울이면 쉽게 작성할 수 있다.
게다가 많은 이들이 설치 운용하고 있는 웹서버를 문서 서버로 이용하기 때문에 음성 서비스 시나리오 저작의 저변 확대 및 대중화가 가능해, 개인 음성서비스의 구축 붐이 일어날 가능성이 대단히 높다. 이것은 결국 전문적인 음성 시나리오 작가의 등장과 음성 서비스 수준의 고급화로 이어지게 될 것이다.

이러한 맥락에서, 이번 IBM developerWorks의 이번 Article Part1, 2, 3, 4는 VXML을 이용하여 각종 예제를 접할 수 있다는 점에서 상당히 의미가 있다.(기술 설명만 아무리 많으면 뭐하나, 예제가 있어야 심화 문제를 풀지-_-)

  • Part 1 — 음성 실행 RSS 리더
  • Part 2 — 음성 실행 달력
  • Part 3 — 음성 실행 블로그 및 Twitter 애플리케이션
  • Part 4 — 음성 실행 Yahoo 검색 애플리케이션

    현재, VXML을 이용한 예제 중 업데이트 된 4개의 Article이다. 이 중, 개인적으로 가장 관심있는 부분은 Part4의 '음성 실행 Yahoo 검색 애플리케이션'이다.

    Part4는 VXML을 사용하여 검색하고, 리턴된 검색 결과를 듣는 것도 가능하다. Part4에서는 이러한 일을 수행하는 애플리케이션을 구현한다. 다음은 웹 검색 워크플로우이다. 그림에서 알 수 있듯이 2개의 메뉴를 제공하는데, 로컬 검색(List local search phrases)과 전통적인 웹 검색(List Web search phrases)이 그것이다. 전자는 두개의 인풋 값, 검색어, 위치를 필요로 하고, 후자는 검색어만 필요로 한다. 검색 결과는 VXML로 변환되어 반환된다.
    웹 검색 워크플로우

    이후로, 자유 형식 문법 인풋을 만들고, 기본적인 VXML 아웃풋 클래스를 만든다.
    그리고 기본 인터페이스를 사용하여 간단한 검색을 출력하고 VXML 아웃풋을 살펴보게 된다.
    그리하여 Yahoo 검색 인터페이스를 사용하여 웹 검색을 실행하게 되는데, 솔직히 따라하는데 애를 좀 먹었다.
    하지만, 어렵다는 이야기는 아니다. 조금 구체적인 설명이 있었으면 하는 부분도 없잖아 있었지만, 그럭저럭 프로그래밍에 대한 지식이 조금 있다면 어렵지 않게 가능할 것이다.
    그리고 Article에서도 있듯이, 아웃풋의 음성 버전이 완벽하지 않다.
    하지만 이것으로도 충분하다.

    이를 이용하면, 전화를 통해 음성으로 쇼핑, 검색, 개인일정관리 등의 서비스가 가능하게 되며,
    이는 말(Voice)로 인터넷 서비스를 이용하는 보이스 포털로도 연결될 수 있다.
    이같은 서비스를 가능하게 해 주는 기본 기술 중 하나가 음성인식(ASR: Automatic Speech Recognition)과 VXML이다. VXML을 접하고 가장 먼저 생각한 것은 개인일정관리이다.
    사실, 일정관리를 편리하게 하려는 시도는 도처에서 너무나 많이 시도되었었고 지금도 진행중이다.
    하지만 개인일정을 완벽하게 관리하기 위해서는 관리도구가 항상 근처에 있어야 하는데 연필로 종이에 기록하는 것은 불편하다 하여, 전자수첩이나 휴대폰, 웹 등의 도구를 사용하게 되었으나, 휴대폰과 전자수첩은 버튼을 눌러 기록/검색하는 것이 시간이 많이 걸리고, 웹은 휴대할 수가 없기 때문에 기록이 용이하지 않다.
    이를 해결할 수 있는 방법은 음성인식 뿐이다.
    일정의 입력이 필요할 경우, 음성으로 입력하고, 검색이 필요할 경우에도 음성으로 검색, 결과 또한 음성으로 알려줄 수 있다는 점에서 VXML을 이용한 이번 예제는 상당히 의미가 있다.
    한번 따라 해 보면 좋을 성 싶다. 그리고 재미있고 신기하다.

    몇몇 관심있는 녀석들로 팀을 구성해서 음성인식 개인일정관리에 한번 도전해 보는 것도 좋을 법 하다.
    물론 여유 시간이 좀 나야 가능하겠지만, 흐흐.ㅠㅠ

    ※ 관련 기사의 링크는 상단의 Part1, 2, 3, 4에 각각 링크되어 있습니다.

  • naver OpenAPI의 내PC 검색은 일반적인 검색과 리턴 값이 달랐다.
    일반적인 openAPI의 리턴값은 다음과 같다. 예를들어 검색 api는 다음과 같은 XML을 리턴한다.
    <?xml version="1.0" encoding="UTF-8" ?>
    - <rss version="2.0">
    - <channel>
      <title>Naver Open API - webkr ::'go'</title>
      <link>http://search.naver.com</link>
      <description>Naver Search Result</description>
      <lastBuildDate>Tue, 11 Apr 2006 14:36:33 +0900</lastBuildDate>
      <total>18992582</total>
      <start>1</start>
      <display>10</display>
    - <item>
      <title><b>GO</b>.com</title>
      <link>http://www.go.com/</link>
      <description>... Victims, Military Personnel Sell Rations Online Government Report Finds Ready-to-Eat Meals for Sale on eBay...... trailers and the latest buzz on... Harry Potter and the Goblet of Fire , X-Men 3 , Spider-Man 3 , more... Tonight...</description>
      </item>

    보면 알겠지만 <TAG>TEXT</TAG> 형식으로 구성되어 있으므로 파싱하기가 편리하다.
    직접 파싱을 해도 되지만, C#에서 파서를 제공해 주는데 굳이 할 필요는 없지 않은가.
    최초 XML을 접하고 파싱에 애를 먹어 각지의 도움을 얻었었다. 그리고 준일님께서 도와주셨다.

    웹서비스는 XML 을 이용한 HTTP 간의 통신 방법이다.
    이 기술이 현재 각광을 받는 이유는 방화벽간에 통신을 위한 포트가 아닌,
    HTTP 로 어떤 플랫폼에서도 인식이 가능한 규격화된 텍스트 형식, 즉 XML 이라는 것이다.

    DataSet 이란 클래스는 무수한 기능을 가진 컬렉션이다.
    이부분은 ADO.NET에 대해서 더 공부하면 알겠지만, 메모리 상의 작은 데이터베이스라고 칭할만큼 무수한 기능이 많다.
    DataSet 의 ReadXml 이란 메서드는 XML 형식의 데이터를 DataSet 으로 파싱할 수 있게 된다.
    (단, 모든 DataSet 에 변환가능한 형식 이어야 한다.)

    파싱의 예는 다음과 같다.
    string QueryURL = "쿼리문"
    XmlTextReader txtReader = new XmlTextReader(QueryURL);
    while(txtReader.Read())
    {
     if(txtReader.NodeType == XmlNodeType.Element)
     Response.Write(txtReader.Name + " : ");
     if(txtReader.NodeType == XmlNodeType.Text)
     Response.Write (txtReader.Value + "<br>");
    }

    쿼리문을 던져 해당 노드의 타입을 보고 Element와 Text를 구분하여 출력해 주는 예제이다.
    하지만, 문제가 있다.
    naver 내PC 검색의 리턴XML의 출력은 표준 형식인 RSS 2.0 형식 (http://blogs.law.harvard.edu/tech/rss)을 따른다.
    표준 RSS에 내PC검색 API용으로 추가된 태그는 nns XML namespace를 가진다.

    <?xml version="1.0" encoding="UTF-8" ?>
    - <rss version="2.0" xmlns:nns="http://mypc.naver.com/nnsrss">
    - <channel>
      <title>Naver OpenAPI - MyPC Search Result</title>
      <link>http://127.0.0.1:4311/openapi/search?key=mypc&query=%BF%E4%BF%F8</link>
      <description>Naver MyPC Search Result</description>
      <language>ko</language>
      <generator>Nano Search 2.0</generator>
      <nns:total>5</nns:total>
      <nns:start>1</nns:start>
      <nns:display>5</nns:display>
      <nns:errorcode>0</nns:errorcode>
    - <item>
    - <title>
    <![CDATA[alias.2x03.cipher.ws_dvdrip_xvid-fov.avi  ]]>
      </title>
    - <link>
    <![CDATA[G:\alias.s02\alias.2x03.cipher.ws_dvdrip_xvid-fov.avi  ]]>
      </link>
    - <description>
    - <![CDATA[ 

    와 같은 형식은 <TAG><![CDATA[TEXT]]</TAG> 형식이다. 위의 파싱 방법으로 파싱을 할 경우에는, 올바로 파싱이 되지 않는다. <![ 형식을 Element로 판단하지 못하고 무시해 버린다.
    위 파싱 방법의 소스 중, Value는 Xml Element 의 내용을 그대로 가져오게 된다.
    ReadElementString() 메서드를 사용하면 말끔히 해결된다.
    다음 예제는 이러한 문제도 말끔히 해결된다.

    XMLFile1.XML
    <?xml version="1.0" encoding="utf-8" ?>
    <title><![CDATA[타이틀]]></title>
    Program.CS
    using System;
    using System.Collections.Generic;
    using System.Text;
    using System.Xml;
    namespace ConsoleTest
    {
     class Program
     {
      static void Main(string[] args)
      {
       XmlTextReader reader = new XmlTextReader("../../XMLFile1.xml");
       while (reader.Read())
       {
        if (reader.NodeType == XmlNodeType.Element && reader.Name == "title")
         Console.WriteLine(reader.ReadElementString());
       }
       reader.Close();
      }
     }
    }

    이상. XML의 파싱은 여기까지.
    XML을 적절히 파싱한다면, 이를 이용하는 방법은 헤아릴 수도 없을 정도일 것이다.
    이것이 XML의 강점(?) 이며, openAPI의 매력일지도 모르겠다. *-_-*