MSXML 3.0의 XPath 1.0, XSLT 1.0, XDR, SAX2 지원

핵심 DOM API
MSXML 3.0 이전에 있었던 대부분의 개발 노력은 XPath, XSLT, XDR, SAX 등의 기능에 중점을 맞추어 왔기 때문에, MSXML 2.0 이후 핵심 DOM API에 대해 눈에 띄는 향상은 별로 없었습니다. 그러나, MSXML 3.0은 별도의 DLL(msxml3.dll)로 제공되어 서로 다른 PROGID와 coclass 이름을 사용하여 MSXML 2.0의 단계적 설치를 완벽하게 지원합니다. 그림?1에서는 버전에 따른 PROGID 및 버전과 별개의 PROGID를 모두 볼 수 있으며, MSXML 3.0과 함께 제공된 coclass 이름도 볼 수 있습니다. MSXML 팀은 다음 릴리스를 설치할 경우 MSXML 3.0에 대해 구축 및 테스트된 기존의 서비스가 영향을 받지 않도록 버전 고유의 형식을 사용할 것을 강력히 권장합니다.
기존 코드는 계속해서 동일한 구성 요소의 MSXML 2.0 버전을 사용하도록 하면서 MSXML 3.0을 설치하여 3.0의 새 기능을 이용할 수 있습니다. 다음 코드는 DOMDocument30 coclass(MSXML 3.0 입력 라이브러리 참조)의 인스턴스를 만드는 방법입니다.

Dim doc as MSXML2.DOMDocument30 Set doc = New MSXML2.DOMDocument30

기술의 첨단을 걷고 싶어하는 개발자들은 MSXML 2.0 버전에 대한 레지스트리 입력을 바꾸어 MSXML 3.0을 기본 라이브러리로 설치하려고 할 것입니다. MSXML 3.0을 설치하면 xmlinst.exe라는 이름의 설치 유틸리티가 Windows 시스템 디렉터리에 따로 지정됩니다. 이 파일을 실행하면 MSXML 2.0 레지스트리 입력 사항을 MSXML 3.0에 대한 입력 사항으로 바꾸게 됩니다. 이 작업을 한 번 수행하면 MSXML 2.0에 대해 작성된 모든 응용 프로그램(Internet Explorer 5.0 포함)이 코드 변경 없이도 바로 MSXML 3.0에 대해 실행됩니다.
xmlinst.exe에 있어 가장 좋은 점은 사용자가 레지스트리 변경을 하지 않아도 된다는 점입니다. 그림?2는 MSXML 2.0 레지스트리 설정과 MSXML 3.0 레지스트리 설정 사이에 쉽게 전환할 수 있는 서로 다른 옵션입니다.
이러한 버전 문제와 함께 핵심 API에 대해 가장 분명하게 추가된 사항은 새로운 IXMLDOMDocument2 인터페이스(그림?3 참조)에서 확인할 수 있습니다. IXMLDOMDocument2 구성원은 모두 DOMDocument coclass와 FreeThreadedDOMDocument coclass라는 발송 인터페이스를 통해 사용할 수 있으므로, 스크립팅 언어에서 쉽게 사용될 수 있습니다. 이 구성원에 대해서는 다음에 더욱 자세히 설명하겠습니다.

XPath 1.0 API
MSXML 2.0은 XPath 1.0의 이전 버전인 XSL Pattern에 대한 지원 기능을 제공합니다. XML 지정 언어의 개념은 원래 W3C XSL Working Drafts(http://www.w3.org/TR/1998/WD-xsl-19981216.html)에서 소개되어 XSL Pattern이라고 했습니다. MSXML 2.0은 몇 가지만 빼고 원래 XSL 사양에 설명된 대로 XSL Pattern 언어를 구현합니다.
MSXML 3.0은 레거시 XSL Pattern 구문과 XPath 1.0을 함께 지원합니다. 사용자는 IXMLDOMNode 인터페이스에서 사용할 수 있는 selectNodes 메서드와 selectSingleNode 메서드를 통해 이 두 가지를 모두 이용할 수 있습니다. selectNodes 메서드는 문자열 표현식(XPath 1.0 또는 XSL Pattern)을 받아, 해당 표현식에 일치하는 노드 컬렉션을 나타내는 XMLDOMNodeList 인터페이스에 참조를 반환합니다. 다음 코드는 Visual Basic®에서의 selectNodes 사용을 나타냅니다.

Public sub applyExpression(node as IXMLDOMNode, e as String) dim nl as IXMLDOMNodeList, n as IXMLDOMNode set nl = node.selectNodes(e) for each n in nl processNode n next end sub

selectSingleNode 메서드는 단순히 해당 표현식에 일치하는 첫째 노드에 참조를 반환합니다.

dim n as IXMLDOMNode set n = node.selectSingleNode("/foo/bar/baz")

이는 다음과 같습니다.

dim n as IXMLDOMNode set n = node.selectNodes("/foo/bar/baz").item(0)

표현식에서는 XPath 1.0이나 XSL Patterns 구문 중 어느 것을 사용해도 상관 없기 때문에 이러한 API를 사용하기 전에 선택 언어를 지정하는 방법이 있어야 합니다. 기존 코드와의 호환성을 그대로 유지하려면 XSL Pattern을 기본 선택 언어로 사용합니다. 현재 선택 언어를 XPath로 바꾸려면 SelectionLanguage 속성과 XPath 값을 사용하여 새로운 setProperty 메서드(IXMLDOMDocument2 참조)를 호출합니다.

node.ownerDocument.setProperty "SelectionLanguage", "XPath" applyExpression node, "/child::foo/descendant::bar/baz"

선택 언어를 XSL Pattern으로 다시 설정하려면 XSLPattern 값을 사용하여 setProperty를 다시 호출하면 됩니다.
MSXML 3.0에는 새로운 selectNodes 구현도 소개되었습니다. 이 새 버전은 IXMLDOMNodeList 인터페이스와 새로운 IXMLDOMSelection 인터페이스를 모두 구현하는 개체를 반환합니다. 그리고, 이전 버전과의 호환성을 유지하기 위해 새 selectNodes 버전에서도 IXMLDOMNodeList 인터페이스에 참조를 반환합니다. 따라서 IXMLDOMSelection 인터페이스에 대한 참조를 받으려면 반환된 개체에 표준 QueryInterface가 있어야 합니다. Visual Basic에서는 Set 연산을 이용하면 됩니다.

Dim sel as IXMLDOMSelection Set sel = node.selectNodes("/child::foo/descendant::bar")

IXMLDOMSelection 인터페이스는 IXMLDOMNodeList를 확장하여 캐시된 컴파일 표현식(그림?4 참조)을 다시 사용할 수 있도록 합니다. expr 속성은 표현식의 값을 제어할 수 있도록 하고, context 속성은 해당 표현식을 평가할 때 사용된 컨텍스트 노드를 제어할 수 있게 합니다. 다음 Visual Basic 코드는 이 작업이 어떻게 이루어지는지를 보여 줍니다.

xml="<foo><bar><baz>hello</baz><baz>world</baz></bar></foo>" doc.loadXML xml doc.setProperty "SelectionLanguage", "XPath" dim sel as IXMLDOMSelection set sel = doc.documentElement.selectNodes("child::bar/*") MsgBox sel.expr ' displays "child::bar/*" MsgBox sel.length ' displays "2" set sel.context = doc MsgBox sel.length ' displays "0" set sel.context = doc.documentElement MsgBox sel.length ' displays "2"

다른 문서에서도 지정된 컨텍스트 노드를 받을 수 있습니다. 단, 이 노드가 다음과 같이 선택 개체를 만든 문서와 동일한 스레드 모델을 공유하는 경우에 한합니다.

Xml1="<foo><bar><baz>hello</baz></bar></foo>" Xml2="<foo><bar><baz>bye</baz></bar></foo>" doc1.loadXML xml1 doc2.loadXML xml2 doc1.setProperty "SelectionLanguage", "XPath" doc2.setProperty "SelectionLanguage", "XPath" dim sel as IXMLDOMSelection set sel = doc1.documentElement.selectNodes("child::bar/*") MsgBox sel.item(0).xml ' "<baz>hello</baz>"를 표시 set sel.context = doc2.documentElement MsgBox sel.item(0).xml ' "<baz>bye</baz>"를 표시

또한, 전달된 노드가 현재 선택에 포함되어 있는지 확인하는 다음과 같은 matches 메서드도 있습니다.

set n = doc.documentElement.childNodes(0).childNodes(0) set res = sel.matches(n) ' n이 선택 컬렉션에 있으면 res가 중요합니다.

IXMLDOMNodeList 메서드는 여전히 컬렉션을 통과(item과 nextNode)하는 데 사용되며, IXMLDOMSelection도 현재 노드에서 확인(peekNode)을 하고 컬렉션에서 노드를 제거(removeAll 및 removeNext)하며 전체 컬렉션을 복제(clone)할 수 있습니다.
조만간 기대할 수 있는 다른 XPath 기능 향상은 적절한 이름 공간 지원과 관계가 있습니다. XPath 사양에 따르면 표현식에 자격 없는 요소 이름(이름 공간 접두어 없음)이 있을 경우 기본 이름 공간 선언이 원본 문서에 있더라도 해당 요소는 이름 공간의 일부로 간주되지 않습니다. XPath 표현식에 자격 있는 이름(이름 공간 접두어를 통함)이 있을 때는 현재 XPath 컨텍스트를 구성하는 이름 공간 바인딩에 따라 평가됩니다. 그러나, MSXML 3.0에서 XPath 표현식을 평가하기 전에 이름 공간 바인딩을 구성하기 위한 위치에 메커니즘이 현재 없습니다. 즉, 이름 공간을 인식하는 XML 문서를 적합하게 쿼리할 수 없게 됩니다.
예를 들어, 다음 XML 문서를 생각해 봅시다.

<foo xmlns='urn:foo-bar:baz'> <bar><baz/></bar> </foo>

/foo/bar/baz 표현식은 무슨 내용을 반환합니까? XPath 사양에 따르면, 이 표현식은 이름 공간에 속하지 않는 foo, bar, baz 등의 요소를 찾고 있지만 원본 문서에서 foo, bar, baz 등의 요소는 모두 urn:foo-bar:baz 이름 공간에 속하므로 이 표현식은 아무 것도 반환하지 못합니다.
이러한 문제를 해결하기 위해 앞으로 출시될 MSXML 3.0 릴리스에서는 selectNodes를 호출하기 전에 SelectionNamespaces 속성을 통해 이름 공간 바인딩을 지정할 수 있게 됩니다.

doc.setProperty "SelectionNamespaces", _ "xmlns:f='urn:foo-bar:baz'" set sel = doc.selectNodes("/f:foo/f:bar/f:baz")

이름 공간 바인딩이 있으면 이 표현식은 이제 'urn:foo-bar:baz'에 속한 foo, bar, baz 등의 요소를 확인할 수 있으므로 적절히 실행됩니다. 이 이름 공간은 원본 문서의 기본 이름 공간 선언과 일치합니다. 릴리스 시기에 따라 구문은 바뀔 수도 있습니다.

XSL Pattern과 XPath 1.0 비교
XSL Pattern 표현식은 XPath 표현식의 단축된 형식과 매우 유사합니다. 두 언어의 기본적인 차이점은 XSL Pattern은 개별 축 개념을 지원하지 않으며, 사용할 수 있는 연산자와 함수 라이브러리가 실제로 다르다는 것입니다. 두 언어 모두 동일한 프로세싱 모델(대부분에 있어서)을 따르지만 XPath 1.0이 훨씬 더 유연하면서도 강력합니다.
두 구문의 차이점을 확인하는 데 도움이 되도록 샘플 DHTML 응용 프로그램을 제공하였습니다. 이 응용 프로그램을 사용하면 한 프레임에서 XML 문서를 로드하고 이 문서에 대해 Xpath 또는 XSL 패턴 표현식을 실행할 수 있습니다(그림?5 참조). http://staff.develop.com/aarons/bits/xpath-builder에서 이 응용 프로그램의 실행을 확인해 보십시오.

그림 5 대화형 표현식 작성기

사용자 요구에 따라 XSL Pattern의 언어 구조가 XPath 1.0(적용 가능)의 언어 구조에 어떻게 매핑되는지를 보여주는 매트릭스(그림?6 참조)를 제공하였습니다. MSXML 3.0의 최신 릴리스는 그림?6에 나타나 있는 모든 기능과 모든 XPath 축(이름 공간 제외), 공식 W3C 사양에 기록되어 있는 전체 XPath 1.0 함수 라이브러리를 구현합니다.
XPath 1.0에 대한 자세한 배경 정보는 웹 브라우저에서 http://www.w3.org/TR/xpath를 참조하거나, MSDN® Magazine의 2000년 7월호에서 The XML Files 를 참조하십시오.

XSLT 1.0
MSXML 2.0은 XSL 변환을 수행하기 위해 IXMLDOMNode 인터페이스에 transformNode 메서드와 transformNodeToObject 메서드를 제공했습니다. transformNode 메서드는 문자열로 변환 결과를 반환하는 반면, transformNodeToObject 메서드는 DOMDocument로서 변환 결과를 반환합니다. 두 메서드는 MSXML 3.0에도 존재하며 XSLT 1.0 변환을 수행하는 데 사용될 수 있습니다. 이 두 메서드로 인해 문서를 두 개 로드하고 하나의 메서드만 호출하는 정도로 변환 작업이 쉬워집니다.

Dim xmlDoc as New DOMDocument, xslDoc as New DOMDocument Dim strResult as String, xmlOutput as New DOMDocument xmlDoc.load "foo.xml" xslDoc.load "foo.xsl" ' 결과를 문자열로 반환 strResult = xmlDoc.transformNode(xslDoc.documentElement) ' 결과를 DOMDocument로 반환 xmlDoc.transformNode xslDoc.documentElement, xmlOutput

이 메서드의 약점은 성능이 떨어진다는 점입니다. 코드가 transformNode를 호출할 때마다 변환 엔진이 제공된 스타일시트를 컴파일해야 합니다. 이제 MSXML 3.0에서는 IXSL 템플릿 인터페이스를 구현하는 XSLTemplate30를 통해 나중에 사용할 수 있도록 컴파일된 스타일시트를 캐시할 수 있습니다(그림?7 참조). 해당 API가 조금 번거롭기는 하지만 성능면에서 보면 그럴 만한 가치가 있습니다.
다음 함수는 XSLT 스타일시트를 로드하고 나중에 사용할 수 있도록 XSLTemplate30 개체에 캐시하는 방법을 설명합니다.

Function createCachedStylesheet(xsluri As String) As IXSLTemplate ' 자유 스레드 문서를 만들고 스타일시트를 로드 Dim xslDoc As New FreeThreadedDOMDocument30 xslDoc.Load xsluri ' 템플릿 개체를 만들고 스타일시트를 캐시 Dim temp As New XSLTemplate30 Set temp.stylesheet = xslDoc Set createCachedStylesheet = temp End Function

문서 개체의 자유 스레드 버전(FreeThreadedDOMDocument30)을 새 API와 함께 사용해야 합니다. 캐시된 스타일시트가 있으면 createProcessor 메서드를 통해 프로세서 개체를 만들 수 있습니다. 프로세서 개체는 IXSLProcessor 인터페이스(그림?8 참조)를 구현하고 실행 변환을 나타냅니다. 제공된 스타일시트에 대해 여러 프로세서 개체를 만들 수 있습니다.
원본 XML 문서(변환될 문서)를 input 속성을 통해 프로세서에 연결할 수 있습니다. 그런 다음 변환을 실행하려면 간단히 transform을 호출하기만 하면 됩니다. 그림?9의 코드에는 완전한 예가 들어 있습니다.
XSLT 변환에 매개 변수를 사용하려면 transform을 호출하기 전에 해당 매개 변수를 프로세서의 컨텍스트에 추가할 수 있습니다. IXSLProcessor 인터페이스에는 이러한 목적을 위한 addParameter 메서드가 있습니다.

Dim processor As IXSLProcessor Set processor = cache.createProcessor() processor.addParameter "param1", "hello" processor.addParameter "param2", "world" processor.input = doc1 processor.Transform

이 코드에서는 다음과 같이 스타일시트가 매개 변수 param1과 param2를 선언한다고 가정합니다.

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:param name="param1"/> <xsl:param name="param2"/> ... </xsl:transform>

MSXML 3.0에서도 사용자 지정 스크립트 라이브러리와 COM 구성 요소를 통해 XSLT 언어의 기능을 확장할 수 있습니다. 사용자의 XSLT 변환에 스크립트 블록을 추가하려면 msxml:script 요소를 사용하십시오. 이는 그림?10에 설명되어 있습니다.
XSLT 변환은 addObject 메서드를 통해 프로세서의 컨텍스트에 추가되어 있는 사용자 지정 COM 구성 요소를 사용할 수 있습니다.

Set obj = CreateObject("mylib.myobject") processor.addObject obj, "urn:mylib" processor.Transform

mylib.myobject 구성 요소가 GetMessage 함수와 time 속성을 지원한다면 적합한 이름 공간 지정자를 사용하는 변환에서 이 함수와 속성을 사용할 수 있습니다.

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:mylib="urn:mylib"> <xsl:template match="/"> Message: <xsl:value-of select="mylib:GetMessage()"/> Time: <xsl:value-of select="mylib:get-time()"/> </xsl:template> </xsl:transform>

속성 이름은 "get-"으로 시작되어야 하고 메서드처럼 액세스해야 합니다(괄호에 주의).

XSL과 XSLT 1.0의 비교
MSXML 2.0에서의 XSL 구현은 초기 Working Draft 사양 중 하나를 기본으로 합니다. 따라서 최종 XSLT 1.0 사양에 있는 여러 개의 언어 구조를 지원하지 않습니다. MSXML 3.0은 실제로 XSLT 1.0 사양을 완벽하게 지원합니다. 릴리스 당시 구현되지 않은 기능은 xsl:strip-space, xsl:preserve-space, xsl:apply-imports, xsl:namespace-alias, xsl:number, xsl:message, xsl:fallback 등과 case-order 특성 및 lang 특성, named 특성 집합 등이었습니다. 이러한 구조는 앞으로 출시될 릴리스에서 구현될 계획입니다.
MSXML 팀은 레거시 XSL 파일을 XSLT 1.0 호환 파일로 변환하기 위한 메타 스타일시트를 제공했습니다. 그리고, XML 문서를 프레임으로 로드하고 XSL(T) 변환에 입력하며 매개 변수를 프로세서의 컨텍스트에 추가하고 해당 변환을 수행하며 결과를 표시하도록 해 주는 샘플 DHTML 응용 프로그램을 제공하였습니다(그림?11 참조). http://staff.develop.com/aarons/bits/dhtml-xslt에서 이 응용 프로그램을 온라인으로 실행할 수 있습니다.

그림 11 패턴 매칭 도구

XSLT 1.0에 대한 자세한 배경 정보는 웹 브라우저에서 http://www.w3.org/TR/xslt를 참조하십시오.

XDR
MSXML 2.0은 XDR(XML-Data Reduced)로 알려져 있는 스키마 언어를 지원하며, 이 언어는 Microsoft가 1998년 W3C에 제출한 제안서(http://www.w3.org/TR/1998/NOTE-XML-data-0105 참조)를 기본으로 합니다. API에 있어서 XDR 스키마에 대한 검증 작업은 DTD의 경우와 같습니다. 인스턴스 문서에서 적합한 x-스키마 이름 공간을 사용하여 해당 스키마에 연결하는 한 이 문서의 validateOnParse 속성은 참으로 설정되고 문서를 로드하는 동안 MSXML는 연관된 XDR 스키마에 대해 검증을 수행하게 됩니다. 다음 XML 문서를 가정해 봅시다.

<foo xmlns="x-schema:fooschema.xdr"> ??? </foo>

다음 코드는 문서를 확인하여 로딩하는 방법을 보여줍니다.

Dim doc as new DOMDocument doc.validateOnParse = true doc.load "foo.xml"

일단 DOM에 로드된 문서 스키마 정보는 datatype, nodeTypedValue, definition 등 여러 Microsoft DOM 확장을 통해 응용 프로그램에서 사용할 수 있습니다.

<foo xmlns:dt='urn:schemas-microsoft-com:datatypes' > <bar dt:dt='i4' >842</bar> <bar dt:dt='r8' >92.1</bar> </foo>

다음 코드는 유형 정보를 사용하기 위해 datatype 및 nodeTypedValue를 사용하는 방법을 표시합니다.

Dim n1 As IXMLDOMNode Dim n2 As IXMLDOMNode Set n1 = doc.selectSingleNode("/foo/bar[0]") Set n2 = doc.selectSingleNode("/foo/bar[1]") Dim v1, v2 As Variant v1 = n1.nodeTypedValue v2 = n2.nodeTypedValue MsgBox (TypeName(v1) = "Long") ' 참 표시 MsgBox (TypeName(v2) = "Double") ' 참 표시 MsgBox (n1.dataType = "i4") ' 참 표시 MsgBox (n2.dataType = "r8") ' 참 표시

로드된 문서에 연관된 완전한 XDR 스키마가 있다(ElementType 선언과 AttributeType 선언 포함)고 할 때, 이 정의 속성을 사용하여 특정 노드에 대한 실제 스키마 정의를 끌어 낼 수 있습니다.

Dim n as IXMLDOMNode Set n = doc.documentElement.childNodes(2) MsgBox n.definition ' <ElementType name='bar' dt:type='i4'/> 표시

XPath 및 XSLT 향상과 마찬가지로, XDR 관련 API 기능 향상도 효율성의 증대와 성능 발전에 대한 요구에 따라 이루어졌습니다. MSXML 3.0에서는 구문 분석된 XDR 스키마 정의를 캐시하고 인스턴스 문서에서 이들을 다시 사용할 수 있습니다. 이러한 작업을 수행하려면 XMLSchemaCache coclass 인스턴스를 만들어야 합니다. 이 클래스는 새로운 IXMLDOMSchemaCollection 인터페이스(그림?12 참조)를 구현하며 다음과 같이 사용됩니다.

Dim cache as IXMLDOMSchemaCollection Set cache = New XMLSchemaCache30 Dim xdrdom as New DOMDocument30 xdrdom.async = false xdrdom.load "bar.xdr" ' 구문 분석된 XDR를 캐시에 추가 cache.add "urn:bar", xdrdom ' 지정된 XDR를 구문 분석/로드하여 캐시에 추가 cache.add "urn:baz", "http://develop.com/baz.xdr" ' 전체 이름 공간 컬렉션을 추가 cache.addCollection doc.namespaces ' 이전 예제로부터

add 메서드나 addCollection 메서드를 통해 스키마를 캐시에 추가할 수 있습니다. add 메서드는 XDR 파일에 대한 URI나 로드된 XDR 파일에 대한 IXMLDOMDocument 참조를 받습니다. 그리고 addCollection 메서드는 IXMLDOMSchemaCollection 참조를 받습니다. IXMLDOMDocument2 인터페이스의 이름 공간 속성은 로드된 문서와 연관된 스키마를 나타내는 스키마 컬렉션에 참조를 반환합니다.
캐시가 만들어지면 IXMLDOMDocument2 스키마 속성을 통해 어떤 문서든지 여기에 붙게 됩니다

' doc1, doc2, doc3이 DOMDocument30으로 선언된 것으로 가정 ' async 플래그는 이미 거짓으로 설정 ' validateOnParse 플래그는 이미 참으로 설정 doc1.schemas = cache doc2.schemas = cache doc3.schemas = cache doc1.load "foo.xml" doc2.load "bar.xml" doc3.load "baz.xml"

개별 문서는 로드될 때마다 이미 캐시에 존재하는 관련 스키마에 대해 확인됩니다.
MSXML 3.0이 나오기 전에는 문서 로드를 통해서만 검증을 실행할 수 있었습니다. 하지만 새로운 validate 메서드가 IXMLDOMDocument2 인터페이스를 통해 소개됨에 따라 로드된 문서에 대해서도 재검증을 수행할 수 있게 되었습니다. validate를 사용하면 mutation 이벤트 이후에도 문서를 다시 검증할 수 있습니다.

On Error Goto errHandler doc1.schemas = cache doc1.load "foo.xml" MutateTheHeckOutOfDocument doc1 doc1.validate ' COM 예외에 대한 오류 확인

MSXML에서 공식 W3C XML Schema Definition Language(XSD)에 대한 지원을 발표하게 되면 분명 스키마 관련 API에 대한 기타 여러 가지 향상된 기능이 제공될 것입니다.

XDR 구문으로 업데이트
XDR 구문에 대해서는 인라인 스키마에 대한 지원 기능과 MinLength/MaxLength 특성에 대한 지원 기능이라는 두 가지 주요 기능만 향상되었습니다. 인라인 스키마를 사용하면 이전에는 반드시 별도의 파일에 두어야 했던 스키마 정의를 스키마 인스턴스 문서 내에 삽입할 수 있습니다. 이는 DTD가 내부 DTD 하위 집합과 관련하여 실행되는 방식과 유사합니다. 인라인 스키마는 일반 스키마 정의와 동일한 구문을 따르지만, 이름 속성에 따라 구별된다는 점과 이름에 따라 스키마를 참조하는 x-스키마 이름 공간 선언을 통해 인스턴스 문서에 연결된다는 점이 다릅니다.

<foo xmlns:data="x-schema:#myInlineSchema"> <Schema name="myInlineSchema" xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes"> <ElementType name="bar" dt:type="int"/> </Schema> <data:bar>28</data:bar> </foo>

string, number, bin.hex, bin.base64 등의 데이터 형식의 길이를 제한하기 위해 두 가지 새로운 특성인 minLength과 maxLength가 urn:schemas-microsoft-com:datatypes 이름 공간에 추가되었습니다. XDR 언어에 대한 몇 가지 추가 사항을 제외하면 MSXML 3.0 구현은 MSXML 2.0과 동등합니다. XDR의 자세한 내용은 http://msdn.microsoft.com/xml/ 에서 온라인 MSDN 설명서를 참조하십시오.

새로운 SAX2 지원 기능
최근 MSXML 3.0에 추가된 기능으로는 SAX2의 C++/COM 구현을 들 수 있습니다. 최초 릴리스에서도 C++/COM을 목표로 했지만 MSXML은 Visual Basic 매핑 계층도 제공할 예정이며, 본 자료가 게시될 즈음에는 사용할 수 있을 것으로 보입니다.
SAX2 API는 원본 XML 문서의 내부 메모리 트리 구현에 의존하지 않기 때문에 DOM보다 훨씬 성능에 민감한 프로세싱 모델을 제공합니다. SAX2는 인터페이스 기반 프로그래밍의 장점에 구축된 스트림 기반 API입니다. SAX2 소비자 응용 프로그램은 하나 이상의 SAX2 소비자 인터페이스를 구현하여 이를 SAX2 생산자 응용 프로그램에 등록합니다. 생산자는 SAX2 소비자 인터페이스에서 사용할 수 있는 메서드를 통해 XML 문서를 소비자에게 보낼 수 있습니다.
예를 들어, 다음 코드는 제공된 소비자에게 간단한 XML 문서를 보냅니다.

void function sendMeDocument(ISAXContentHandler* pConsumer) { pConsumer->startDocument(); // parameters omitted for clarity... pConsumer->startElement(..., L"foo", ...); pConsumer->characters(L"hello world", ...); pConsumer->endElement(..., L"foo", ...); pConsumer->endDocument(); }

소비자에게 발송된 XML 문서는 다음과 같이 나열할 수 있습니다.

<foo>hello world</foo>

SAX2 생산자의 매우 일반적인 형식은 XML 파서입니다. 이는 실제 XML 문서를 처리하는 파서로서 SAX 소비자에게 해당 메서드를 호출합니다.
SAX2에 대한 MSXML 3.0 지원 기능은 MSXML 3.0 SDK inc 디렉터리에 설치되어 있는 파일에서 찾을 수 있으며, 파서는 SAXXMLReader coclass 안에 들어 있습니다. 익숙하게 사용해야 할 주요 인터페이스는 ISAXXMLReader와 ISAXContentHandler라고 할 수 있습니다. 다음 MSXML 릴리스에서는 SAX 인터페이스가 DOM 인터페이스와 통합될 예정이며, 따라서 더 이상 별도의 xmlsax.h 파일과 xmlsax_l.c 파일이 존재하지 않게 됩니다.
SAX2는 앞으로 컬럼에서 폭넓게 다루게 될 주제입니다. 그 동안의 SAX2에 대한 내용은 MSDN의 SAX2 자료를 참조하십시오. SAX2 Jumpstart 자료(http://msdn.microsoft.com/workshop/xml/articles/sax2jumpstart.asp )를 통해 처음 SAX2 응용 프로그램을 구축하는 데 대한 기본 사항을 확인할 수 있고, Joy of SAX 자료(http://msdn.microsoft.com/workshop/xml/articles/joyofsax.asp )를 통해서는 임시 Visual Basic 매핑 레이어를 구축하는 방법을 볼 수 있습니다. SAX2의 배경 정보는 브라우저에서 David Megginson의 사이트(http://www.megginson.com/)를 참조하십시오.

유틸리티
앞서 언급한 XSL-XSLT 1.0 변환기 유틸리티 외에도 MSXML 팀은 MSXML 3.0과 함께 사용할 수 있도록 여러 가지 유틸리티를 선보였습니다. 또한 XML을 검증하고 Internet Explorer 5.0 내부에서 XSLT 프로그램의 결과를 확인할 수 있도록 일부 셸 확장을 제공했습니다(그림?13 참조).

그림 13 XML 검증

또한, 여러 가지 브라우저와 장치에 대해 XML 컨텐트의 서버 쪽 XSL 포맷을 가능하게 해 주는 ISAPI 필터도 포함되어 있습니다. 그리고 마지막으로, 제공된 스키마에 대해 자동으로 문서를 생성해 주는 XDR용 XSLT 변환(그림?14 참조)도 제공되어 있습니다. 이러한 유틸리티는 모두 http://msdn.microsoft.com/downloads/webtechnology/xml/msxml.asp 에서 다운로드할 수 있습니다.

그림 14 스키마 문서 생성기

어디까지 왔나?
MSXML 2.0 이후 MSXML 3.0은 먼 길을 왔습니다. 이제, W3C의 규약인 XPath 1.0과 XSLT 1.0 사양을 지원하며 XDR 지원 기능도 향상되었습니다. 여러 가지 성능 관련 기능도 향상되어 컴파일된 XPath 표현식과 컴파일된 XSLT 스타일시트, 로드된 XDR 스키마 등을 캐시할 수 있게 되었습니다. 이러한 새로운 기능은 IXMLDOMDocument2, IXMLDOMSelection, IXSLTemplate, IXSLProcessor, IXMLDOMSchemaCollection 등의 인터페이스를 통해 가능하게 되었습니다. 하지만, 아직도 충분치 않은 듯 MSXML 3.0은 최근 SAX2에 대한 지원 기능까지 추가했습니다.