XPath, XSLT 및 기타 XML 규격

구문을 단순하게
XML의 단순성은 많은 사람들을 매혹시키는 요소입니다. 많은 분들이 알고 계신 바와 같이 XML은 SGML(Standard Generalized Markup Language)과 완벽히 호환되는 그 하위 체계로서, SGML을 보다 단순화한 것입니다. SGML은 워드 프로세싱 소프트웨어, 프린터 및 기타 디스플레이 장치에서 인식할 수 있습니다. SGML과 마찬가지로 XML은 문서의 구조와 내용을 분리하고 있지만, W3C의 XML 작업 그룹은 XML에서는 SGML의 보다 복잡한 측면과 수많은 옵션들을 제거했습니다. http://www.w3.org/TR/REC-xml 에 있는 W3C XML 1.0 권고안을 보시면 그 규격이 생각보다 길지 않다는 것을 알게 될 것입니다.
연락처 관리자 데이터베이스의 연락처를 기술하고 있는 XML의 예를 살펴보겠습니다.

<contact category="enemy of the state"> <fullname>Will Smith</fullname> <phonenumbers> <home>801-555-2323</home> <cell>801-555-3232</cell> </phonenumbers> <email address='will@jiggy.com'/> </contact>

이 XML 문서는 XML 구문에 관해 알아야 할 대부분의 사항을 알려주고 있습니다. 시작 태그가 있으면 반드시 종료 태그(적절한 중첩 관계)나 슬래시가 있어서 이것이 형식을 잘 지킨 공백 요소임을 알 수 있습니다. 그리고 모든 속성 값은 작은따옴표나 큰따옴표로 지정되어 있습니다. 어떤 XML 문서가 XML 1.0이 지정한 구문 규칙을 준수하고 있다면 적합한 문서로 간주할 수 있습니다. 사실, 정의상 모든 XML 문서는 적합한 문서입니다. 어떤 문서가 적합한 문서가 아니라면 그것은 XML 문서가 아니라 문자 덩어리에 불과하기 때문입니다.
다음은 적합한 XML 문서의 요건 가운데 잘 지켜지지 않는 네 가지 사항을 나타낸 것입니다.

1. 모든 속성값은 작은따옴표 또는 큰따옴표로 지정해야 합니다.
   
2. 모든 요소에는 시작 태그와 종료 태그가 있어야 합니다(공백인 경우 제외).
   
3. 모든 공백 요소는 해당 시작 태그의 끝에 공백 요소 식별자(/)가 있어야 합니다.
   
4. 요소들은 올바로 중첩되어야 합니다.
   

<IMG SRC="background.gif" ID=img1>

<IMG SRC="background.gif" ID="img1" />

<foo><bar><baz></bar></baz></foo>

그림 1 올바른 형식이 아닌 문서

문서가 제대로 구성된 것인지 확인하려면 자신이 주로 사용하는 XML 처리 프로그램에 로드해 보십시오. 문제가 있는지 알 수 있습니다. 파일 확장명이 .xml인 경우 Microsoft Internet Explorer 5.0은 잘못된 구문 위치를 알려줍니다. 이 컬럼에는 XML 구문을 입력하여 그 구문이 맞는지 틀린지를 바로 알 수 있는 학습용 샘플 툴이 제공되어 있습니다(그림 1 및 2 참조).

그림 2. 올바른 형식의 문서

Infoset: 정보 모델
XML 표준이 계속 발전하면서 W3C의 XML 작업 그룹에 속한 개발자들을 포함한 대부분의 개발자들이 XML의 내용을 추상화한 것(문서 또는 요소)들을 구체적인 구문과는 독립적인 것으로 간주한다는 사실이 점점 명백해졌습니다. 이에 따라 W3C는 XML Information Set 작업 그룹을 구성하여 Infoset(제대로 구성된 XML 문서의 추상적 정보 모델을 정의하는 추상적 개체 및 속성 집합)을 공식 지정하게 했습니다. Infoset은 XML 규격과 소프트웨어를 지지하는 집단간의 공통 어휘와 데이터 집합을 사용하도록 장려하기 위한 것입니다. Infoset은 현재http//www.w3.org/TR/xml-infoset 에 W3C의 작업 초안 형태로 마련되어 있습니다.
Infoset은 어떤 XML 처리 방식이나 인터페이스 집합을 지정하는 것이 아니라, XML 처리 프로그램이 이를 이용하는 응용 프로그램에 제공해야 하는 추상적 정보 모델을 정의하는 것입니다. XML 문서의 정보 항목을 형식화하면 모든 XML 처리 프로그램과 언어들이 각자의 구현 과정에서 서로 유사한 추상화를 사용하도록 하는 데 도움이 됩니다.
한 문서의 Infoset은 둘 이상의 정보 집합으로 구성되어 있습니다. 적합한 XML 문서는 최소한 이 문서 및 요소 정보 항목을 포함하고 있습니다. </x>만으로 구성된 가장 작은 문서에도 두 개의 추상화가 사용되고 있습니다. 즉, 문서 정보 항목과 요소 정보 항목으로, 요소 정보 항목은 트리의 루트 요소입니다.
문서 및 요소 정보 항목 외에 문서에 포함할 수 있는 정보 항목에는 속성, 처리 명령(processing instruction), 빠뜨린 엔티티(구문 분석된 외부 항목으로서, 배제된 것)에 대한 참조, 문자, 주석, 문서 유형 선언, 엔티티, 형식 표기, 엔티티 시작 표식, 엔티티 종료 표식, CDATA 시작 표식, CDATA 종료 표식, 이름 공간 선언 등이 있습니다.
Infoset은 정확한 구문의 영향을 받지 않는 XML 문서의 정보를 참조할 수 있게 하므로 최근 개발한 XML?DOM(Document Object Model), XPath, XPointer, XML Schema 등?은 해당 정보 모델을 참조합니다.

이름 공간
XML의 X는 상당한 의미를 내포하고 있습니다. XML은 개발자들이 자신의 시스템에서 사용할 어휘를 만들 수 있는 확장 가능한 언어입니다. 개발자들은 요소 및 속성 이름을 자유롭게 사용해서 특정 처리 응용 프로그램에 의미를 전달할 수 있습니다. 어휘란 특정 유형의 응용 프로그램이 이해할 수 있는 요소 및 속성의 그룹이라 할 수 있습니다. 주어진 표시 어휘를 이해할 수 있는 소프트웨어 모듈이 작성되었다면 다른 개발자들도 새로운 것을 만들 필요 없이 이 어휘를 다시 사용할 수 있습니다. 이로 인해 개발자들은 이미 마련된 소프트웨어 모듈을 사용할 수 있게 되는 것입니다.
일반적으로 외부에서 정의한 어휘를 자신의 XML 문서에 다시 사용할 수 있습니다. 따라서 문서 공유가 쉬워지는 것입니다. 그러나 한 문서에 여러 개의 어휘가 들어 있을 경우에는 충돌 및 인식 오류가 발생할 수 있습니다. 보편적으로 사용할 수 있는 고유 요소 및 속성 이름의 필요성이 생기면서 W3C는 XML Namespaces 권장 사항(http://www.w3.org/TR/REC-xml-names )을 개발했습니다.
Namespaces로 인해 개발자는 자신이 일반적으로 제어해야 하는 고유 URI로 요소 및 속성 이름을 식별할 수 있습니다. 예를 들면 다음과 같은 XML 단락에서,

<awl:book awl:ID="1-2323-23424" xmlns:awl="http://www.awl.com/cseng" xmlns:dm="http://www.develop.com/courses"> <awl:title>Essential Legos</awl:title> <dm:related-course dm:ID="EMIND"/> <dm:title>Essential Mindstorm</dm:title> </dm:related-course> </awl:book>

교재 및 관련 강좌 요소는 모두 ID 속성을 갖고 있어서 이를 이용하는 응용 프로그램이 혼동할 가능성이 있습니다. 또한 서로 다른 것을 의미하는 제목 요소가 두 개 있습니다. 이 예는 고유 이름 공간(자원) 식별자(URI)로 요소 및 속성 이름을 식별하는 것이 어휘의 올바른 사용을 보장해 주는지를 보여주고 있습니다.
xmlns 속성(앞의 예 참조)을 이름 공간 선언이라고 합니다. 이 이름 공간 선언은 URI에 문서에 고유한 접두사를 지정합니다. 요소 또는 속성 이름에 이름 공간 접두사(예: awl:book)를 추가하면 연결된 이름 공간 URI로 이 요소나 속성 이름을 식별할 수 있으며, 그 고유성을 보장할 수 있습니다. 그러나 이름 공간 선언에 이름 공간 접두사가 없다면 모든 요소 이름에 대한 기본 이름 공간으로 간주되며, 이는 속성에 적용되지 않습니다.

XML API
대부분의 XML 개발자들은 XML 처리 프로그램을 구현하는 것이 지루하고, 시간 소모적이며, 옳은 결과를 얻기 힘들기 때문에 직접 구현하려 하지 않습니다. 게다가, Microsoft XML 구문 분석기 MSXML 2.x(http://msdn.microsoft.com/downloads/tools/xmlparser/xmldl.asp )처럼 무료로 얻을 수 있는 향상된 도구가 있는데 누가 그런 고통스런 작업을 하겠습니까?
그러나 XML 개발자들에게 진정으로 필요한 것은 Infoset과 표준 XML API 규격을 준수한 처리 프로그램으로 작업하는 것입니다. 이를 통해 개발자들은 이식 및 업그레이드가 간편한 표준 인터페이스에 맞춰 구현 독립적인 코드를 작성할 수 있습니다.
오늘날 주로 사용되고 있는 XML API의 유형은 이벤트를 기반으로 한 유형과 트리를 기반으로 한 유형이 있습니다. 이벤트 기반 API는 구문 분석될 때 처리 프로그램이 문서의 정보 항목을 응용 프로그램에 보내는 데 사용할 수 있는 이벤트 인터페이스를 정의하여 XML 구문 분석 과정을 형식화합니다. 반면, 트리 기반 API는 문서가 구문 분석되고 로드된 후에 응용 프로그램이 사용할 수 있는, XML 문서의 논리 구조를 표현하는 메모리 내부의 개체 모델을 정의합니다.
SAX(Simple API for XML)는 문서의 구문 분석 과정에 바로 들어갈 수 있기 때문에 개발자들에게 급속하게 인기를 얻고 있는 이벤트 기반 API 규격입니다. SAX는 어떠한 산업 표준 기구의 개입도 없이 XML-DEV 메일링 리스트의 회원들이 공동으로 개발했다는 점에서 여기 논의되는 나머지 다른 기술들과 다릅니다. SAX는 업계의 인정을 받았으며 Apache.org의 Xerces, IBM의 XML4J, Sun의 ProjectX 등과 같은 현재의 여러 XML 처리 프로그램에 영향을 주었습니다.
최초의 SAX 주창자들로는 Peter-Murray Rust, Tim Bray, David Megginson 및 이외 XML-DEV 메일링 리스트의 수많은 인물들이 있습니다. David Megginson은 이 메일링 리스트에서 이루어진 개발 회의를 중재했으며 SAX 1.0의 초안을 작성하고 이후 SAX의 발전을 책임지고 있습니다. 2000년 1월, Megginson은 파서 확장성 및 이름 공간 확장성을 지원하는 SAX 2.0을 발표했습니다. Megginson은 Java 언어 버전의 MSXML을 위한 SAX 드라이버 샘플을 http://www.megginson.com/ 을 통해 제공하고 있습니다.
XML의 문서 개체 모델(DOM)은 표준 트리 기반의 API 규격으로서 업계 전반에서 최대의 인정을 얻고 있습니다. DOM은 단순한 노드의 계층 구조인 XML 문서의 논리 구조와, 응용 프로그램에 제공되어야 하는 인터페이스를 정의하고 있습니다. DOM는 문서의 요소를 제공하여 스크립트나 기타 코드를 통해 개별적으로 조작이 가능하도록 하고 있습니다. DOM은 해당 문서가 임의 액세스 또는 순회를 위해 메모리에 로딩될 것이라는 점을 함축하고 있습니다.
DOM은 그 동안 많은 사람들이 체험할 수 있었습니다. DOM Level 1(http://www.w3.org/TR/REC-DOM-Level-1 참조)은 HTML 응용 프로그램에 고유한 기능뿐 아니라 코어 XML 기능도 정의한 W3C의 권장 사항입니다. DOM Level 2는 현재 W3C의 권장 후보 사항(http://www.w3.org/TR/DOM-Level-2 참조)으로서 순회, 스타일시트, 이벤트 등과 같은 몇 가지 필수 기능뿐 아니라 완전한 이름 공간 지원 기능을 추가한 것입니다.
MSXML 2.x는 DOM Level 1을 따르고 있으며 DOM Level 2가 아직 W3C의 정식 권장 사항이 아니지만, DOM Level 2에 추가된 이름 공간 형식을 따르기 위한 작업이 이루어졌습니다.

XPath, XPointer, XLink
제대로 구성된 XML 문서는 구조 메타데이터와 정보 항목으로 구성됩니다. 구조 메타데이터는 개별 정보 항목들 사이에 존재하는 내포 관계를 정의합니다. 이 내포 관계는 XML 문서의 주소 지정 부분에 사용될 수 있습니다. 문서 부분을 식별하기 위해 추상적 관계 기술을 사용하는 것은 명백한 순회 기법과는 반대로, 문서 처리 작업을 크게 단순화할 수 있습니다. XPath가 이를 가능하게 합니다.
XPath는 문서 주소 지정을 위한 포괄적인 언어로서, 최근 W3C의 권장 사항이 되었습니다(http://www.w3.org/TR/xpath ). XPath는 XML 문서의 계층을 탐색하는 데 URL 및 디렉터리와 같이 경로(path) 표기법을 사용한 점에서 그 이름을 따왔습니다. XPath의 선임자는 XSL Patterns로서 MSXML 2.0에서 지원되었습니다. XPath는 Infoset에 매핑되는 노드(DOM과 유사)의 트리 형태로 XML 문서를 구성합니다. 다음과 같은 XML 단락을 예로 들어 보겠습니다.

<contact category="enemy of the state"> <fullname>Smith</fullname> <numbers> <home>801-555-2323</home> <cell>801-555-3232</cell> </numbers> </contact>

이 문서에 포함된 Smith의 전화번호를 찾아야 한다고 가정합시다. 이 작업을 SAX나 DOM의 수동 처리를 통해 수행할 수도 있지만 이 같은 유형의 질의는 다음과 같은 간단한 XPath 식으로도 기술할 수 있습니다.

/descendant::contact[fullname="Smith"]/child::numbers/child::*

MSXML 2.6 기술 미리 보기에는 최신 XPath 규격을 적용한 예가 포함되어 있습니다. 이 기술 미리 보기와 관련 문서 자료는 MSDN 온라인(http://msdn.microsoft.com/downloads/webtechnology/xml/msxml.asp )에서 다운로드할 수 있습니다. MSXML 2.0는 XSL Patterns를 지원하고 MSXML 2.6은 XSL Patterns와 XPath를 모두 지원하고 하향 호환성을 위해 XSL Patterns를 기본으로 하고 있습니다.
MSXML 2.6은 XSLT뿐 아니라 IXMLDOMNode selectNodes 및 selectSingleNode를 통해 XPath 질의를 지원하고 있습니다. XPath에 대한 테스트를 시작하려면 setProperty 호출을 통해 선택 언어를 지정하면 됩니다.

doc.setProperty "SelectionLanguage", "XPath" sel = doc.selectNodes("descendant::numbers")

XPath의 맨 위에 지정되어 문서 간의 명확한 관계를 정의할 수 있게 하는 언어는 XPointer와 XLink입니다. XPointer는 XPath를 확장해서 URI 단락 식별자에서 사용할 수 있게 합니다. 이 식별자들은 문서 간, 또는 같은 문서 내의 서로 다른 요소 사이의 링크를 정의하는 데 유용합니다.

contacts.xml#xpointer(/descendant::numbers/child::*)

XPointer는 또한 XML 문서에서 지점(point)과 범위(range)의 개념을 도입하여 XPath를 확장하고 있습니다. XPointer가 현재 W3C 작업 초안(http://www.w3.org/TR/xptr )입니다.
XLink는 XPointer 식을 사용하여 문서 인스턴스 또는 문서 요소 사이에 링크(또는 명확한 관계)를 생성하는 표준 메커니즘을 정의하고 있습니다. XLink도 W3C 작업 초안(http://www.w3.org/TR/xlink )입니다. MSXML 2.x는 현재 XPointer 및 XLink를 지원하지 않습니다.

유효성과 메타데이터
형식적으로 제대로 구성된 XML 문서가 반드시 유효한 XML 문서는 아닙니다. 앞서 기술한 제대로 구성된 XML 문서는 XML 1.0에서 정의한 모든 구문 조건을 준수합니다. 반면 유효한 문서는 종종 문서의 DTD(Document Type Definition)에서 정의하는 어휘 수준 제약 조건도 준수해야 합니다. 따라서 유효한 XML 문서는 형식적으로도 잘 구성된 것이지만, 형식적으로 적합한 문서라고 해서 모두 유효한 것은 아닙니다.
대부분의 XML 1.0 규격은 문서 메타데이터를 제공하는 DTD와 관련되어 있습니다. DTD는 엔티티와 형식 표기법뿐 아니라 해당 문서 유형에서 허용될 자식/부모 관계, 속성, 속성 유형 등 주어진 어휘에 대한 제약 조건을 정의합니다. 이들 제약 조건을 종종 문서의 어휘 또는 스키마라고 합니다.
DTD의 개념은 SGML에서 보다 단순화된 형태로 가져 온 것입니다. 그렇지만 이것들은 여전히 XML 언어의 가장 복잡한 부분입니다. W3C가 이들을 대체하기 위한 작업을 진행하고 있는 것은 이러한 이유 때문입니다. 가장 먼저, DTD 구문 자체는 XML과 호환되지 않습니다. 따라서 어휘 제약 조건을 가진 문서를 작성하려면 새로운 구문을 학습해야 합니다. 또한 XML과 DTD 구문을 모두 지원해야 하는 XML 처리 프로그램 개발자들은 더욱 커다란 부담을 안게 됩니다.
DTD는 또한 이름 공간을 잘 인식하지 못합니다. 이름 공간 인식 문서를 DTD와 함께 사용하려면 이름 공간 접두사를 모든 DTD 표시(markup) 선언으로 하드 코딩하는 작업이 필요합니다. 이름 공간 접두사를 DTD로 하드 코딩하는 것은 이름 공간이 의미하는 모든 것에 반대되는 것입니다. 개발자들은 매개 변수 엔티티를 사용해서 이 문제에 창의적인 해결 방법을 도입하려 노력했지만 이러한 노력에도 불구하고 이름 공간과 DTD는 서로 전혀 어울리지 않았습니다.
DTD는 또한 요소 및 속성 유형 기술에 대한 지원에도 대단히 취약합니다. XML 1.0에서는 요소의 유형이 요소 이름으로부터 간단히 도출됩니다.
W3C가 현재 개발하고 있는 DTD 대체안을 XML 스키마 정의 언어(Schema Definition Language) 또는 짧게 XML 스키마라고 합니다. XML 스키마는 두 가지 규격으로 나뉩니다. 하나는 XML 문서의 내용을 제약하고 구조를 기술하기 위한 것(http://www.w3.org/TR/xmlschema-1 )이고 다른 하나는 XML 스키마에서 사용될 데이터 유형을 정의하기 위한 것(http://www.w3.org/TR/xmlschema-2 )입니다. 두 규격 모두 현재는 작업 초안 단계에 있습니다.
XML 스키마는 DTD를 메타데이터 언어로 개선한 것입니다. 첫째, XML 스키마 구문은 XML 규격을 준수하고 있어서 많은 문제를 덜고 있습니다. 둘째, XML 스키마는 XML 언어 전체에서 이름 공간의 장점을 완벽하게 지원 및 활용하고 있습니다. 마지막으로 XML 스키마는 인스턴스로부터 유형을 구분하는 보다 개선된 컨텐트 모델을 제공합니다. 즉, XML 스키마는 머지 않아 XML 문서 메타데이터를 정의하는 표준 메커니즘이 될 것입니다.
MSXML 2.x는 DTD를 지원하며 아울러 XDR(XML-Data Reduced)이라고 하는, 보다 축소된 XML 스키마 집합을 지원합니다. 이 집합은 W3C 메모[http://www.w3.org/TR/1998/NOTE-XML-data-0105, 보다 최신 문서는 http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm (또한 MSDN Online XML DevCenter http://msdn.microsoft.com/xml/ )에 기술되어 있습니다.
DTD 또는 XML 스키마에 대한 유효화를 지원하는 XML 처리 프로그램을 유효 처리 프로그램이라고 하며, 유효화를 지원하지 않는 처리 프로그램을 비유효화 처리 프로그램이라고 합니다. 일부 XML 처리 프로그램을 이 두 가지 모드에서 처리할 수 있습니다. MSXML 2.x는 이러한 동작 방식을 제어하기 위해 IXMLDOMDocument 인터페이스에 validateOnParse 등록 정보를 제공하고 있습니다.

변환
기업과 개발자들이 단일한 XML 어휘 또는 스키마에 합의할 수 있다면 데이터 및 문서 공유는 훨씬 쉬워질 것입니다. 그러나 XML 어휘의 공유를 장려하기 위한 실행 계획들은 BizTalk.org, OASIS 등 여러 가지가 있습니다. 기업들은 바로 쓸 수 있는 도메인 고유 어휘를 사용하는 것이 유리합니다. 그러나 대부분의 개발자들은 이해 관계가 있는 모든 기업들의 필요를 만족시킬 수 있는 단일한 어휘를 마련할 가능성이 매우 희박하다는 점을 깨닫고 있습니다. 대부분의 기업들은 공개된 어휘를 다소 변형한 것들을 사용하게 될 가능성이 큽니다.
이 같은 상황에서는 개별 XML 어휘간의 상호 운용성을 촉진할 변환 작업이 요구됩니다. W3C는 이 같은 변환 작업을 기술하기 위한 XSL 변환(XSLT) 언어를 개발했습니다. XSLT는 XML 문서를 다른 텍스트 기반 문서(XML, HTML, 쉼표 구분 문서, C++ 머리글/소스 파일 외)로 변환하는 것을 가능하게 했습니다.
XSLT 언어는 이 변환 과정의 구체화를 위한 선언적인 규칙 기반 언어를 정의하고 있는 또 하나의 XML 어휘일 뿐입니다. XSLT는 XPath를 기반으로 하며, 원본 XML 문서의 어떤 부분을 대상 문서로 변환해야 하는지를 정의하고 있습니다. 아래의 XML 코드는 간단한 XSLT 스타일시트의 구조입니다.

<?xml version="1.0" encoding="UTF-8" > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="<XPATH EXPRESSION>"> <!? transformation defined here ?> </xsl:template> </xsl:stylesheet>

XSLT는 최근 W3C 권장 사항(http://www.w3.org/TR/xslt )으로 채택되었으며, MSXML 2.6 기술 미리 보기에서는 최신 XSLT 규격의 구현 사례를 보여주고 있습니다.

문자 인코딩
ISO/IEC 10646은 범용 문자 집합(UCS)을 정의하고 있는 국제 표준입니다. UCS는 대규모의 문자 레퍼터리와 그에 해당하는 문자 코드를 정의하고 있습니다. UCS는 상업적으로 중요한 주요 언어를 모두 포괄하고 있으며 앞으로 더욱 확대될 수 있는 여지가 있습니다. 유니코드 표준도 이와 유사한 목적을 갖고 있지만 그것은 미국 컴퓨터 제조업체들의 단체인 Unicode Consortium에서 개발한 것입니다. Unicode는 공식적으로는 별개의 표준이지만 UCS와 동일하게 유지되어 왔습니다. 오늘날, UCS와 유니코드는 일반적으로 동일한 문자 레퍼터리를 지칭하고 있습니다. 앞으로 상황이 바뀔 가능성은 있습니다.
XML에서 문자는 단순히 숫자입니다. UCS 표준은 이 숫자의 의미를 정의하고 있는 것입니다. 이 숫자들은 다양한 문자 인코딩 알고리즘을 사용해서 디지털 방식으로 저장될 수 있습니다. 256 이상의 문자를 담을 수 없는 문자 레퍼터리의 경우에는 각 문자 코드를 8진수(ASCII처럼)에 매핑할 수 있습니다.
UCS에는 몇 개의 문자 인코딩 알고리즘을 사용할 수 있습니다. 가장 일반적인 것은 UTF-16과 UTF-8입니다. UTF-16은 단순히 모든 문자를 두 개의 8진수(16비트)로 매핑하고 필요한 경우 큰 숫자에는 대체물을 사용합니다. 한편 UTF-8은 7비트 ASCII 문자는 8진수로 저장(ASCII처럼)하지만 다른 모든 문자에는 두 개 ~ 다섯 개의 8진수를 아무것이나 사용할 수 있습니다. 대부분 ASCII로 이루어진 문서라면 UTF-8 방식이 공간을 절약하겠지만 다른 경우에는 공간을 낭비하게 됩니다.
XML 1.0 권장 사항에 따르면 모든 XML 처리 프로그램은 UTF-8와 UTF-16 알고리즘을 이해할 수 있어야 합니다. 따라서 ASCII 문서의 UTF-8 인코딩은 해당 ASCII 인코딩과 동등한 것이므로 XML 처리 프로그램은 ASCII 문서를 자동으로 처리할 수 있는 것입니다. XML이 다른 문자 인코딩을 배제하는 것은 아니지만 처리 프로그램이 이들을 공식적으로 지원할 필요는 없습니다.
XML 처리 프로그램이 XML을 읽으려면 해당 문서에 어떤 문서 인코딩이 사용되었는지를 파악할 수 있어야 합니다. 이를 위한 한 가지 방식은 MIME Content-Type 머리글에서처럼 전송 계층이 공급하는 정보를 이용하는 것입니다.

Content-Type: text/xml; charset=ks_c_5601-1987

아마도 이것이 XML 리소스에서 사용된 문자 인코딩을 식별하는 가장 안전한 메커니즘일 수 있지만, 불행히도 이러한 정보가 항상 존재하는 것은 아닙니다. XML 문서는 또한 XML 선언에서 그 문자 인코딩을 명백히 선언할 수도 있습니다.

<?xml version="1.0" encoding="UTF-8"?>

그러나 이러한 인코딩 선언 앞에 있는 텍스트의 경우에는 XML 처리 프로그램이 어떻게 처리할 수 있을까요? 만일 어떤 문서가 UTF-8과 UTF-16 이외의 문자 인코딩을 사용하고 있다면 여기 제시된 대로 인코딩 속성과 함께 XML 선언이 있어야 합니다. 이러한 XML 문서들은 모두 "<?xml"로 시작해야 하므로 문자 인코딩 패밀리를 자동 감지하는 것이 가능하며, 이는 인코딩 정의를 읽고 사용된 특정 문자 인코딩을 확인하는 데 충분합니다. 같은 메모에서 XML 규격은 인코딩 선언이 없는 경우 UTF-8이나 UTF-16의 사용 여부를 자동 감지할 수 있는 메커니즘을 정의하고 있습니다. 이는 UTF-16 BOM(Byte Order Mark)을 통해 가능합니다.
어떤 XML 처리 프로그램이 문서 또는 전송 계층에서 식별한 특정한 문자 인코딩을 지원하지 않는다면 이는 치명적인 오류로 간주됩니다. MSXML 2.x는 UTF-8와 UTF-16을 포함한 상당한 범위의 표준 문자 인코딩을 지원합니다. IXMLDOMDocument::load는 앞서 기술한 메커니즘을 통해 문자 인코딩을 식별합니다. 한편, IXMLDOMDocument::loadXML는 XML이 BSTR로 받아들여지므로 UTF-16으로 가정합니다. 이 경우 loadXML로 넘겨진 XML에 UTF-16 이외의 인코딩 선언이 있으면 MSXML 오류가 발생합니다.
비록 오늘날 여러분이 볼 수 있는 XML의 예는 대부분 ASCII 기반이지만, XML은 UCS와 유니코드에 들어 있는 모든 언어를 지원할 수 있습니다. 이러한 표준 문자 처리 메커니즘은 상호 운용성에 관해 XML이 갖는 장점이 적용됩니다. 다행히 문자 인코딩 문제를 처리하는 까다로운 작업의 대부분은 XML 처리 프로그램의 몫이므로 개발자들은 이러한 대부분의 문제로부터 자유로울 수 있습니다.

XML 확산
XML 규격이 더욱 개발되고 강화됨에 따라 XML은 수많은 응용 프로그램 도메인을 지원할 수 있는 강력하고 유연한 기술로 성숙해 가고 있습니다. XML이 소프트웨어 산업의 모든 측면으로 확산되고 있다는 것은 명백합니다. XML은 데이터베이스 기술(DBMS 및 ADO 등), SOAP와 같은 원격 프로시저 호출 메커니즘, BizTalk™와 같은 B2B 통합 및 메시징 소프트웨어 등에서 필수적인 요소가 되어가고 있습니다. XML은 Internet Explorer 5.0, Internet Information Services 5.0, 기타 수많은 도메인 고유 응용 프로그램 등, 웹 브라우저와 서버에서도 모습을 드러내고 있습니다.
XML 기술과 규격의 영역에서는 변화 없이 제자리를 유지하기는 어렵습니다. 이 문서에서 다룬 기술들은 모든 XML 개발자들이 반드시 숙지해야 할 중요한 사항들입니다(그림 3 참조). 다음 호부터는 다른 새로운 주제를 포함하여 이 기술들에 관해 깊이 논의할 예정입니다. 본 컬럼에서 다루기를 희망하는 주제가 있으면 xmlfiles@microsoft.com 으로 보내주시기 바랍니다.