XML 문서/보기 형식 웹 응용 프로그램을 위한 성능의 창조와 최적화에 대해

Microsoft Internet Developer의 1999년 8월 컬럼에서는 XML과 XSL을 사용하여 동일한 데이터를 서로 다른 보기 형식으로 제공하는 방법에 대해 설명했습니다. 당시 컬럼은 Visual Basic이 기본 제공되어 있는 데스크톱 응용 프로그램에 맞추어 작성된 것이었고, 그로 인해 일부 사용자들이 "그렇다면, 웹 응용 프로그램의 경우는 어떻습니까?"라는 질문을 많이 해 오셨습니다. 따라서, 이번에는 XML 문서/보기 형식 웹 응용 프로그램을 다루려고 합니다. 이러한 웹 응용 프로그램은 웹 기반의 응용 프로그램으로서 데이터와 표시를 명확히 구분하고, 동일한 데이터에 대해 여러 개의 서로 다른 보기 형식을 제공할 수 있는 프로그램을 가리킵니다.
사용자에게 직접 표 레이아웃을 수정하도록 하면, 사용자는 저마다 자신이 선호하는 방식으로 데이터를 파악하게 됩니다. 이는 제공하는 레코드의 양이 많거나 표 보고서의 길이가 길 때 특히 그러합니다. 어떤 사용자는 필드의 가로줄을 스크롤하려 하는 반면, 다른 사용자는 트리 보기 형식 또는 보다 일반적인 마스터/세부 스키마를 선호할 수 있습니다. 이 문제를 정확히 이해하기 위해 Windows 셸을 생각해 볼 수 있습니다. 특히 폴더에서 다섯 가지 표준 보기 형식을 찾아 보십시오. 다섯 가지 표준 보기 형식은 큰 아이콘, 작은 아이콘, 목록, 자세히, 축소판 ( 그림 1 참조)등입니다. 이러한 표준 보기 형식은 언제라도 상호간 전환할 수 있으며 그에 따른 변경 작업도 바로 수행됩니다. 어떠한 보기 형식을 선택하든, 표시되는 데이터는 항상 같습니다.

그림 1 Explorer에서 사용할 수 있는 보기 형식

또 다른 문서/보기 형식 디자인의 예는 Visual InterDev 사용자 인터페이스에서 찾아 볼 수 있습니다. Visual InterDev에서 사용할 수 있는 보기 형식의 목록은 그림 2에 나타나 있습니다. DevStudio 보기 형식을 선택한 경우에는, [프로젝트 창]이 화면의 왼쪽에 고정되면서 Visual C++에 있을 때의 경우와 같이 프로젝트가 구성되는 것을 볼 수 있습니다. 물론 이 경우에도 데이터 자체는 바뀌지 않은 것이며 다만 다른 페이지 레이아웃에 적합하도록 배열이 바뀌었을 뿐입니다. 사용자는 각각 자신이 원하는 보기 형식 모드를 선택할 수 있습니다.

그림 2 Visual InterDev 보기 형식

Visual InterDev 디자인과 1999년 8월 자료에서 예시한 프로그램은 모두 로컬로 작업하므로, 보기 형식을 바꾸기 위해 아무것도 다운로드하거나 캐시할 필요가 없습니다. 이러한 패러다임을 그대로 웹 세계에 적용하면 문제가 발생하게 됩니다. 즉, 필요한 정보를 어디서 어떻게 얻겠는가 하는 문제입니다. 이러한 정보는 웹으로부터 오는 것 같습니다. 결과적으로, 서버에 대해 주고 받도록 전송되는 데이터의 양을 최소화해야 합니다. 여기서는 1999년 8월의 코드를 다시 사용하되, 이번에는 동일한 데이터의 보기 형식을 여러 개로 제공하는 최적화 웹 페이지를 획득하는 방법에 대해 논의하려 합니다. 그림 3 은 이 자료에서 구축할 마지막 페이지를 나타냅니다.

그림 3 웹 페이지에 대한 보기 형식

문서/보기 형식 모델
문서/보기 형식 모델을 MFC와 연결하는 경우가 종종 있지만, 사실 이는 상당히 오래된 프로그래밍 패러다임으로서 원래 SmallTalk와 함께 소개된 내용입니다. 현재 문서/보기 형식 모델의 모체는 MVC(Model-View-Controller)였습니다. MFC에서 모델이라는 단어는 문서라는 단어로 대체되었으나, 컨트롤러 측면은 Windows용 전체 사용자 인터페이스 SDK로 병합되는 바람에 그 단어 자체가 빠진 바 있습니다.
모델(또는 문서)은 응용 프로그램을 통해 표시하려는 실제 데이터를 나타냅니다. 특히, 모델은 데이터의 구조 및 저장소와 더불어 데이터를 묘사합니다. MFC의 경우에는 모델이 CDocument에서 파생된 클래스로 매핑됩니다.
보기 형식은 해당 데이터에 대해 사용할 수 있는 하나의 표시 형식을 나타냅니다. 주로 사용자에게 데이터를 나타내는 그래픽 방법이라 할 수 있습니다. 각 문서마다 서로 다르면서 독립된 보기 형식을 여러 개 둘 수 있습니다. MFC의 경우에는 보기 형식이 CView 클래스를 기본으로 합니다. 예를 들어, 레코드 집합은 사용자 정의된 트리 보기 형식과 같은 마스터/세부 컨트롤과 표 형식의 모눈 컨트롤을 통해 렌더링할 수 있습니다.
원래 컨트롤러는 보기 형식이 렌더링되어야 할 방법을 제어하도록 되어 있었습니다. 달리 말하면, 컨트롤러는 운영 체제의 원본으로 사용되는 UI로 보기 형식의 구성 요소를 매핑하는 작업을 수행했습니다. 이는 일반적인 목적의 언어(예: SmallTalk)에서는 상당한 문제이지만, Windows에서 실행되는 프레임워크인 MFC에서는 별로 중요하지 않은 것으로 판명되었습니다. 컨트롤러라는 개념이 사라지고 Win32 SDK에서 제공한 표준 컨트롤러로 대체된 이유가 바로 이것입니다.
MFC 문서/보기 형식 응용 프로그램에서는 주로 CDocument에서 파생된 클래스를 보유하는데, 이 클래스는 데이터를 읽고 쓰는 방법을 다룹니다. 또한, 이 응용 프로그램에는 서로 다른 표시를 제공하기 위해 CView에서 파생된 클래스가 하나 이상 있습니다. MVC 스키마의 MFC 구현 시, 컨트롤러가 부족한데 이는 앞에서 언급한 바와 같이 Windows에서는 사용할 수 있는 UI가 오직 하나(Windows 공통 컨트롤을 통해 실현된 표준) 뿐이기 때문입니다.
특정 MFC 문서/보기 형식 모델을 좋아하든 않든 간에 이 모델이 제공하는 프로그래밍 패러다임은 상당히 흥미롭습니다. 이 모델을 사용하면 응용 프로그램에서 보유하는 데이터와 이를 렌더링할 수 있는 방법 사이에 명확한 구분을 둘 수 있습니다. 이러한 패러다임은 MFC이나 개체 지향 언어(예: SmallTalk)에 대해서만 이치에 닿는 것이 아닙니다. 데이터와 표시 간의 구분이라는 개념은 기능이 풍부하고 뛰어난 브라우저 포함된 웹 응용 프로그램 등 여러 가지 시나리오에 있어서 상당히 유용합니다.

웹 문서/보기 형식 모델
조만간 대부분의 웹 응용 프로그램은 사용자에게 몇 가지 보고서를 표시하게 될 것입니다. 사용자마다 색상이나 글꼴은 물론, 페이지 크기나 레이아웃에 이르기까지 서로 다른 기본 설정을 보유할 수 있게 됩니다. 이미 스마트 웹 응용 프로그램은 사용자가 보고 데이터에 필터를 적용하고 정렬할 수 있도록 하고 있습니다. 대부분, 이러한 UI 기능은 서버에 대해 새로운 쿼리를 수행하고 그에 따라 새로운 HTML 페이지가 표시됨으로써 얻을 수 있습니다. 물론, 이 방법이 가장 효율적인 것은 아니지만, 브라우저 호환성에 심각한 문제가 있을 경우에는 유일한 방법이 되기도 합니다.
Microsoft Internet Explorer 4.0 이상의 고급 브라우저를 사용하면 클라이언트에게 임시 보고를 수행하고 직접 정보를 조작할 수 있습니다. 레코드의 정렬이나 필터링, 그룹화 등을 수행할 수 있고, 클라이언트에서 HTML 표시가 아닌 원시 데이터만 처리하면 됩니다. 원격 데이터 서비스(RDS)와 ActiveX 데이터 개체(ADO) 레코드 집합은 물론, 데이터 바인딩을 통해 이러한 작업을 수행할 수 있습니다. 레코드 집합의 기본 제공 기능을 이용하여 정렬과 필터링 작업을 수행할 수 있습니다. ADO 레코드 집합은 페이지와 정렬, 그룹, 필터 등을 기준으로 스크롤하기 쉽기 때문에 대화형의 데이터 보고서를 정렬하는 데 매우 효과적인 방법입니다.
그러나, 사용자에게 진행 중인 보고서의 레이아웃을 급진적으로 바꿀 수 있는 기능을 제공하려면 어떻게 해야 할까요? 바로 이러한 경우가 우리에게 익숙한 ASP를 유용하게 사용할 경우라 하겠습니다..

가장 간단한 방법, ASP
ASP를 사용하면 브라우저 뿐 아니라 사용자에 대해서도 임시 페이지의 형식을 지정할 수 있습니다. 먼저, 페이지 레이아웃을 몇 가지 정의하고 콤보 상자에 이 레이아웃을 나열한 다음, 해당 페이지 본문에 조건문을 입력하여 사용자가 선택한 레이아웃이 무엇인지 구별하도록 하려는 경우를 생각할 수 있습니다. 새로운 레이아웃을 요청할 때마다, 스크립트 코드에서 새 페이지에 대한 요청을 서버에 보냅니다. 동일한 데이터에 대해 서로 다른 보기 형식을 제공하는 페이지를 나타내는 데 사용할 수 있는 두 개의 URL은 http://expoware/mypage.asp?viewtype=normal과 http://expoware/mypage.asp?viewtype=dhtml입니다.
이제까지는 클라이언트에 대해 페이지를 준비하는 실제적인 방법에 대해서는 언급하지 않았습니다. if 명령문이나 select case 명령문을 사용하고 viewtype 매개 변수의 값을 사용함으로써, 서로 다른 ASP 페이지에 재연결하거나 데이터를 정확하게 검색하여 조직하는 내부 스크립트 프로시저에 재연결할 수 있습니다.
아울러, ASP 3.0과 Internet Information Services(IIS) 5.0 (Windows 2000에 기본 제공된 웹 서버)의 새로운 기능 중 일부를 사용하여 이러한 작업을 수행할 수도 있습니다. 특히, 새로운 Server.Execute 메서드는 더욱 단순하고 유려한 ASP 코드를 작성하는 데 상당한 도움이 됩니다.

<% select case viewtype case "normal" Server.Execute "normal.asp" case "dhtml" Server.Execute "dhtml.asp" end select %>

페이지 깜박임을 최소화하고 네트워크를 가로 지르는 바이트 수를 줄이기 위해, frame이나 iframe을 사용하여 데이터가 있는 페이지의 일부만 새로 구성되도록 할 수 있습니다. 예를 들어, 그림 3의 페이지에는 고정된 그래픽 하부 구조가 있고, 지원되는 모든 보기 형식의 목록이 있는 폼도 들어 있습니다. 다음과 같이 이러한 보기 형식에서 영향을 주는 모든 데이터는 <iframe> 태그에서 격리되어 있습니다.

<!-- Page content --> <iframe id="myView" frameborder="no" class="view" src="http://expoware/mind/xmldocview/content.asp"> </iframe>

Netscape Navigator나 Communicator 4.x 등으로 이러한 작업을 수행하려는 경우에는 <layer> 태그나 더욱 간단한 기본 프레임을 사용하도록 합니다.
전체적으로, 문서/보기 형식을 ASP를 통해 구현하는 것은 간단하면서도 꽤 쉽지만, 잠깐 살펴봐도 알 수 있듯이 그리 효과적이지는 않습니다. 결정적인 약점은 문서의 보기 형식을 바꿀 때마다 포함되어 있는 데이터를 다시 다운로드한다는 점입니다. 이는 웹이 본래부터 가지고 있는 페이지 기반의 속성에 기인합니다. 작업 시, 원격 스크립트나 데이터 바인딩, RDS 발행의 HTTP를 통한 직접 COM 호출 등의 특별 기술에 의존할 수 있습니다. 이 컬럼의 최근 연재물에서 HTTP를 통한 직접 데이터 교환의 몇 가지 측면을 언급한 바 있습니다.
웹 문서/보기 형식 응용 프로그램을 작성하는 데에 있어 두 가지 중요한 목표는 데이터를 한 번만 다운로드하는 것과, 포함된 모듈 간 연결을 너무 많이 수행하지 않으면서 서로 다른 보기 형식을 제공하는 것입니다.
기본 기술로서 ASP를 사용하는 것은 별로 이상적인 접근법이라 할 수 없는데, 이는 ASP가 단지 HTML 페이지만 만들 뿐이며 이 HTML은 데이터를 잘 관리하지 못하기 때문입니다. 새로운 페이지 레이아웃마다 서로 다른 방법으로 동일한 데이터가 배열되어 있는 새 페이지를 다운로드해야 합니다. 또한, 이 새 레이아웃을 만들기 위해 명확한 스크립트 코드를 추가해야 합니다. 이러한 작업은 Server.Execute를 지원하고 각 레이아웃에 대해 명확한 하위 ASP 페이지를 갖도록 하는 IIS 5.0에 의해 다소 단순화될 수 있습니다.
XML은 데이터를 설명하는 매우 효과적인 방법이고, XSL은 해당 XML 코드를 HTML 페이지로 컴파일하는 데 유용한 방법입니다. 그러나, ASP가 연관되는 한, 결국에는 HTML 태그 내에 하드 코드화된 동일 데이터를 가지고 브라우저에 완전히 새로운 페이지를 보내는 작업은 여전합니다. 이러한 시나리오에서 XML은 ADO 레코드 집합에 대해 유일한 대안이며, XSL은 레이아웃이 서로 다른 페이지를 작성하는 작업을 나누는 하위 ASP 페이지에 대한 유일한 대안입니다..
이 컬럼의 목표는 여러 가지 주요 기능을 갖춘 소프트웨어를 찾는 것입니다. 이 소프트웨어는 클라이언트에 데이터를 오직 한 번만 다운로드할 수 있어야 하고, HTML로 변환하기 쉽도록 일반 목적의 형식으로 데이터를 저장할 수 있어야 합니다. XSL을 갖춘 XML은 완벽한 솔루션처럼 보이지만, 페이지 작성과 다운로드 프로세스를 관리하려면 중간에 ASP가 없어야 합니다.

XML 데이터 아일랜드 사용
그림 4에서는 이상적인 솔루션의 모습을 나타내고 있습니다. 데이터를 설명하는 데는 여전히 XML을 사용하되, XML 데이터 아일랜드를 통해 HTML 페이지에 XML 태그가 포함되어 있는 것을 볼 수 있습니다. 즉, XML은 페이지의 일부지만, 데이터는 <XML> 태그가 있는 페이지의 나머지 부분으로부터 분리되어 있는 컨텍스트에 들어 있으며 그대로 읽고 수정할 수 있다는 것입니다. 데이터와 그래픽 표시는 서로 독립되어 있습니다.

그림 4 XSL로 데이터 형식 지정

XML 아일랜드는 XSL을 통해 HTML로 렌더링할 수 있습니다. 여러 가지 다른 XSL 파일을 사용할 경우에는 동일한 데이터의 보기 형식을 달리 만들 수 있습니다. XSL 파일만 다운로드하여 XML 데이터로 적용되는데, 여기서 XML 데이터는 현재 보고 있는 페이지의 일부로서 클라이언트에 캐시되어 있습니다. XML과 데이터 아일랜드를 사용하면 데이터를 한 번만 다운로드하게 됩니다. 서버에 대한 한 번의 왕복 작업으로 적합한 XSL을 확인(아직 Internet Explorer에 나타나지 않은 경우)하며, 해당 보기 형식을 바꿀 때마다 이 XSL이 다운로드됩니다. 이러한 패턴은 하나의 데이터 블록에 여러 가지 보기 형식을 둘 수 있도록 합니다. 보기 형식을 바꾸는 것은 클라이언트에서 대화형으로 이루어지는 프로세스로서, Microsoft Internet Explorer 4.0 이상의 스마트 브라우저를 대상으로 하는 경우가 더욱 그러합니다.
데이터 아일랜드는 HTML 페이지에 포함되어 잇는 XML 코드의 독립 실행형 일부입니다. Internet Explorer 4.0은 이러한 데이터 아일랜드를 포함하여 일부 기본 제공된 XML 지원 수준을 제공하는 최초의 브라우저였습니다. HTML 브라우저에서, XML 코드의 일부는 알 수 없는 태그로 만들어져 잘못된 HTML 코드처럼 보입니다. 대부분의 웹 브라우저는 HTML 컨텐트를 분석하는 경우, 비교적 느리고 관대한 편이어서 알 수 없는 태그도 그저 무시하곤 하는데, 이는 태그가 잘못되었어도 텍스트는 어떻게라도 표시되기 때문입니다. 예를 들어, 다음 HTML 페이지에는 <msdnmag> 태그에 포함되어 있는 일부 XML 코드가 들어 있습니다.

<HTML> <BODY> <msdnmag> <msj>www.microsoft.com/msj</msj> <mind>www.microsoft.com/mind</mind> </msdnmag> <HR> </BODY> </HTML>

Internet Explorer와 Netscape Communicator는 모두 동일한 방식으로 이를 다룹니다. 즉, 두 브라우저 모두 태그 사이의 텍스트를 그대로 인쇄합니다 (그림 5 참조).

그림 5 브라우저에서 알 수 없는 태그 무시

표시되지 않는 XML 코드를 포함하기 위해 선택할 수 있는 방법이 두 가지 있습니다. <!-- -->를 사용하여 주석을 붙이는 것입니다. 그러나, Internet Explorer의 경우, 주석을 붙인 태그는 DOM을 통해 액세스할 수 없습니다. 그 대신, 다음을 사용할 수 있습니다.

<div id="xml" style="display:none"> <msdnmag> <msj>www.microsoft.com/msj</msj> <mind>www.microsoft.com/mind</mind> </msdnmag> </div>

Netscape의 브라우저 중 하나를 사용하여 표시될 페이지에 XML 코드를 포함하면, 나중에 검색하려는 경우, 동적 HTML(DHTML) 지원 기능이 다르기 때문에 문제가 발생할 수 있습니다.
Internet Explorer 5.0에서는 <xml> 태그는 물론, DHTML을 통해 데이터 관리를 더욱 쉽게 만드는 강력한 XML Document Object Model(XMLDOM)도 제공합니다. <xml> 태그에 포함되어 있는 모든 텍스트는 사용자에게는 보이지 않습니다. 아울러, 다음과 같은 인라인 코드를 사용할 수 있습니다.

<xml id="myXML"> <msdnmag> <msj>www.microsoft.com/msj</msj> <mind>www.microsoft.com/mind</mind> </msdnmag> </xml>

또한 외부 파일을 참조할 수 있습니다.

<xml src="http://expoware/myfile.xml">

DOM을 사용하여 나중에 XML 코드를 검색하고 처리하도록, <xml> 태그를 하나의 ID에 할당할 수 있습니다. <xml>이 페이지에 저장하려는 모든 XML을 둘러 싸야 할 태그가 되도록 하십시오. XML 문서의 근본을 나타내는 데 사용되지는 않습니다.
데이터 아일랜드의 장점을 이용하면, DHTML 페이지를 생성하여 처리할 데이터를 제공할 수 있고, 서버에 대한 단 한번의 왕복 작업만으로 레이아웃을 바꾸는 데 필요한 XSL 스타일시트를 얻을 수 있습니다.
그림 6 에는 그림 3 에 나타난 페이지를 만들어 내는 원본 코드가 있습니다. 이 페이지에서는 ADO를 통해 데이터베이스에 액세스하면서, 서버에 만들어지는 XML 코드에서 사원에 대한 모든 정보를 관리합니다. XML 코드는 표시를 위해 XSL 스타일시트를 참조합니다. 예제 응용 프로그램에서는 표 모양의 보기 형식을 제공하는 table.xsl과 계층적 보기 형식을 제공하는 tree.xsl의 두 가지 스타일시트를 지원합니다.
페이지가 로드되면, XML 코드가 검색되고 XMLDOM(Microsoft.XMLDON 구성 요소에 의해 개체로 표시됨)을 통해 HTML으로 변환됩니다.

xmlData = embeddedXML.innerHTML strURL = "http://expoware/myfile.xml" set xml = CreateObject("Microsoft.XMLDOM") xml.async = False xml.loadXML xmlData set xsl = CreateObject("Microsoft.XMLDOM") xsl.async = False xsl.load strURL view.innerHTML = xml.transformNode(xsl.documentElement)

이 코드를 통해 얻은 문자열은 DHTML을 통해 표시되기 위해 <div> 태그로 할당됩니다. 파일 이름이나 문자열을 사용하여 XMLDOM을 초기화할 수 있습니다. 파일 이름에 대해서는 load 메서드를 불러야 하고, 문자열에 대한 작업은 loadXML이 수행합니다.
T이제는 해결해야 할 문제가 하나만 남게 됩니다. 즉, XML을 HTML로 변환하는 규칙을 바꾸기 위해 사용 중인 스타일시트를 어떻게 바꾸느냐는 것입니다.

XSL 스타일시트 적용
페이지의 컨텐트를 표시하는 XML 코드는 HTML 자체에 포함되어 있으며 XSL 파일에 대한 참조를 갖습니다. 이러한 참조는 필수적인 것으로서, 없을 경우에는 XML 데이터를 HTML로 변환할 수 없게 됩니다. 다음 코드는 XSL 파일을 XML 문서로 연결합니다.

<?xml-stylesheet type="text/xsl" href="http://expoware/mystyle.xsl" ?>

런타임 때 이 코드를 편집해야 페이지 레이아웃을 바꿀 수 있습니다.
XMLDOM을 사용하면 로드된 XML 문서 중 하나의 컨텐트를 편집할 수 있습니다. 안타깝게도, 스타일시트를 지정하는 라인은 XML 핵심 데이터의 기술적인 부분이 아닙니다. 그저 XML 파서에서 XSL 프로세서를 호출하여 지정된 XSL 파일에서 작업하도록 지시하는 처리 지시어일 뿐입니다. XML 문서의 스타일시트를 동적으로 변경하려면, 처리 지시 사항을 통해 XMLDOM이 사용할 수 있는 특수한 메서드에 근거해야 합니다.
XML 데이터를 로드하고 XMLDOM이 초기화된 이후에는 createProcessingInstruction이라는 메서드를 통해 처리 지시 사항을 만들 수 있습니다. 처리 지시 사항은 일반적인 태그처럼 보이지만, 닫는 태그는 없어도 되고 반드시 물음표로 끝나야 합니다. 처리 지시 사항은 xml-stylesheet라는 태그로 렌더링됩니다.

strPI="type=’text/xsl’ href=" & strURL & "‘" Set pi=xml.createProcessingInstruction("xml-stylesheet",strPI)

이러한 지시 사항을 더 많이 지정하려는 경우에는 첫째 지시 사항만 고려됩니다.
처리 지시 사항을 만드는 것은 첫째 단계일 뿐입니다. 다음으로, 페이지의 맨 위에 있는 첫째 XML 노드 앞에 이를 삽입하도록 합니다.

xml.insertBefore pi, xml.childNodes.item(1)

페이지 레이아웃에 대한 변경 사항을 마감하려면, XML 파서에서 XSL 프로세서를 다시 불러 XML을 HTML로 변형하도록 해야 합니다.

view.innerHTML = xml.transformNode(xsl.documentElement)

이렇게 하면 전체 페이지가 새로 고쳐집니다.
클라이언트 쪽 데이터 아일랜드에 대해 XSL 스타일시트를 동적으로 대체하기 위한 코드는 그림 6에 나타나 있습니다.
해당 페이지에는 웹 서버에서 사용할 수 있는 각 XSL 파일에 대해 하나씩 사용될 레이아웃 모두가 콤보 상자 안에 들어 있습니다. 사용자가 선택을 바꿀 때, 다음 코드가 실행됩니다.

<SCRIPT language="VBScript" for="viewtypes" event="onchange"> set cOptions = viewtypes.tags("option") xslFile = cOptions.item(viewtypes.selectedIndex).xsl strURL = "http://expoware/docview/" & xslFile & ".xsl" DoInit(strURL) </SCRIPT>

DoInit는 도우미 루틴으로서, 스타일시트를 대체하고 페이지를 새로 고칩니다. 스타일시트가 지정되지 않은 경우, 이 예제에서는 기본 레이아웃으로서 table.xsl을 사용합니다.
이 모든 것을 가능케 하는 Internet Explorer 브라우징 엔진은 다시 사용할 수 있는 WebBrowser라는 이름의 ActiveX 컨트롤입니다. Visual Basic을 사용하는 프로그래머는 이미 이 구성 요소에 익숙하며, 이 구성 요소는 CHtmlView라는 MFC 클래스를 통해 사용될 수도 있습니다. 이 클래스는 컨트롤의 주요 기능에 대한 C++ 래퍼로서, 탐색과 XML 지원 기능을 포함합니다.
XML 문서/보기 형식 모델을 좋아하고 MFC를 사용하여 CHtmlView 클래스(CView로부터 상속)를 사용하는 경우에는 새로운 CXmlView 클래스를 만들어 볼 수 있습니다. 이러한 사용자 정의 클래스는 메서드를 노출함으로써, 사용하기 쉬운 메서드와 속성 뒤에 XSL 스타일시트의 동적 대체를 숨길 수 있습니다.

결론
XML과 XSL로 형성된 협력 방식은 문서/보기 형식 웹 응용 프로그램을 구축하는 가장 뛰어난 솔루션입니다. 데이터 아일랜드(특히 Internet Explorer 5.0 이상과 함께 사용하는 경우)는 페이지 레이아웃을 새로 고치는 데 필요한 대역폭을 최적화할 수 있도록 합니다. 또한, 데이터 아일랜드는 Internet Explorer 4.0과 DHTML을 사용하여 쉽게 시뮬레이트될 수 있습니다.
이러한 접근법은 매우 성공적인 방법으로서, 여러분의 사용자가 Internet Explorer의 최신 버전을 사용하도록 할 인터넷 프로젝트나 인트라넷 솔루션에 대해 특히 그러합니다. ASP와 IIS를 사용함으로써, Internet Explorer에서는 XML 문서/보기 형식 모델의 장점을 이용하되 다른 브라우저를 통해 볼 때는 보통의 효과만 나타내는 페이지를 만들 수 있습니다.