번역에 관련한 주석는 이 색상으로 표시하여 원문 번역 내용과 구분하였다. CSS 적용은 원본에 준하여 하되 한글 표현이 어색한 부분은 약간 조정하였다. W3C에서 프레임을 허용하지 않아 프레임을 선택 할 수 있게 하였다. 번역문 제공자 : 트리오 웹 프랜드 다른 규격 번역문들 [HTML 4] [CSS 2] [CSS 1] [XHTML 1.0] [ 프레임없게 보기 ] [ 프레임있게 보기 ] [ 바닥 ] 영문 XML 1.0 원문 번역문 시작

REC-xml-19980210

Extensible Markup Language (XML) 1.0

1998년 2월 10일 W3C 추천안

이 버전:

영문 http://www.w3.org/TR/1998/REC-xml-19980210

영문 http://www.w3.org/TR/1998/REC-xml-19980210.xml

영문 http://www.w3.org/TR/1998/REC-xml-19980210.html

영문 http://www.w3.org/TR/1998/REC-xml-19980210.pdf

영문 http://www.w3.org/TR/1998/REC-xml-19980210.ps

최종 버전:

영문 http://www.w3.org/TR/REC-xml

이전 버전:

영문 http://www.w3.org/TR/PR-xml-971208

작성자들:

Tim Bray (Textuality and Netscape) mailto:tbray@textuality.com

Jean Paoli (Microsoft) 영문 mailto:jeanpa@microsoft.com

C. M. Sperberg-McQueen (University of Illinois at Chicago) 영문 mailto:cmsmcq@uic.edu

요약

확장성 작성 언어 (XML: Extensible Markup Language)는 이 문서에서 완전히 설명된 SGML의 하부세트(subset)이다. 그 목표는 특유의 SGML이 웹상에서 유지되고, 개정되고, 처리되어 현재 HTML에서 사용 가능한 방식으로 만드는 것이다. XML은 SGML 과 HTML에 다 적용하고 서로 통용 될 수 있도록 쉽게 설계되었다.

이 문서의 상태

이 문서는 W3C의 멤버와 관련자들의 검토를 거처, 임원회의 승인을 받은 상태이므로 인용하고 사용하는데 안전하다.
W3C의 추천안 형성 기능은 웹의 통용성을 돕도록 주의를 모으고, 그 결과를 널리 보급하는 것이다. 이렇게 함으로서 그 기능성과 상호 통용성을 강화한다.

이 문서는. 기존의 널리 사용되는 월드와이드웹(World Wide Web)에 사용하기 위한 국제 텍스트 처리 표준(Standard Generalized Markup Language, ISO 8879:1986(E)의 수정 보정)의 하부 설정에 의하여. 문법을 지정한다. 이는 W3C XML 활동에 의하여 생성되었으며, 상세한 내용은 영문 http://www.w3.org/XML에서 볼 수 있다. 현재의 W3C 추천안들과 다른 기술 문서들의 목록은 영문 http://www.w3.org/TR에서 볼 수 있다.

이규격은 용어 URI을 사용하는데, 이는 [Berners-Lee et al.]에 의하여 정의된 것이며, 진행되는 작업은 [IETF RFC1738]와 [IETF RFC1808]에 갱신된다.

이규격의 알려진 오류들의 목록은 영문 http://www.w3.org/XML/xml-19980210-errata에서 볼 수 있다.

이 문서에서 오류들가 발견되면 영문 xml-editor@w3.org에 보고해주기 바란다.

확장성 작성 언어(XML: Extensible Markup Language) 1.0

목차

Appendices

1. 소개

확장성 작성 언어 (XML: Extensible Markup Language)는 XML 문서라 불리우는 데이터 오브젝트(object)의 분류와 부분적으로 이를 처리하는 컴퓨터 프로그램의 활동을 기술한다. XML은 적용(application) 프로화일(profile) 혹은 제한된 SGML(Standard Generalized Markup Language [ISO 8879]) 양식이다. 구성상 XML 문서들은 SGML 문서들에 부합한다.

XML 문서들은 엔티티(entity)로 불리우는 저장된 단위들로 만들어 지며, 이는 해석(parse)된 또는 해석 안된 데이터를 가진다. 해석(parse)된 데이터는 글자들로 구성되며, 이들 일부는 글자 데이터를 형성하며, 일부는 코드(마크업: markup)을 형성한다. 코드(마크업)은 문서의 저장 배치와 논리적 구조를 기술(기재사항)을 엔코드(encode)한다. XML은 저장 배치와 논리적 구조에 제한요소를 주는 기능(mechanism)을 제공한다.

XML 처리자(processor)로 불리우는 소프트웨어 모듈(module)을 사용하여 XML 문서들을 읽고, 그 내용(content)과 구조에 접속을 제공한다. XML 처리자(processor)는 적용(application)이라 불리우는 다른 모듈(module)을 위하여 일(작업)하는 것으로 간주된다. 이 규격은, 어떻게 XML 데이터를 읽고 그 정보를 적용(application)에 제공하여야 하는가 하는, XML 처리자의 필요한 행동(behavior)을 기술한다.

1.1 기원과 목표

XML은 1996 W3C가 주관하는 XML 작업구룹(당초에는 SGML 점검회: Editorial Review Board)에 의하여 개발되었다. Sun Microsystems의 Jon Bosak가 회장이었고, 역시 W3C에 의하여 조직된, XML에 특히 관심이 있는 구룹(Special Interest Group: 과거 SGML 작업구룹으로 알려짐)이 참여하였다. 작업구룹의 구성원은 부록에 기재되어있다. Dan Connolly가 W3C의 접촉 담당으로 있었다.

XML에 대한 토론 목표는 다음과 같다:

1. XML은 인터넷에서 막바로 사용 할 수 있어야 한다..
2. XML은 넓은 종류의 적용(application)을 지원하여야 한다.
3. XML은 SGML과 상호 통해야(사용가능) 한다.
4. 이는 XML 문서들을 처리하는 프로그램을 쉽게 쓸 수 있어야 한다.
5. XML의 선택적 성능(feature)들이 완전히 최소되던가 가능하면 없어야 한다.
6. XML 문서들은 인간이 이해하기에 상당히 쉬워야 한다.
7. XML 디자인을 빨리 할 수 있어야 한다.
8. XML 디자인을은 양식에 따르고 함축적이야 한다.
9. XML 문서들은 생성하기 쉬워야 한다.
10. XML 작성(markup)에서의 간결성(terseness)은 별로 중요하지 않다.

이 규격과 관련된 표준들(Unicode, 글자들을 위한 ISO/IEC 10646, 언어의 인식 태그들을 위한 RFC 1766, 언어 이름 코들을 위 한 ISO 639, 국가 이름 코드를 위한 ISO 3166)은, 비표준인 XML 버전 1.0과 이를 처리하는 구성 컴퓨터 프로그램등에 필요한, 모든 정보를 제공한다.

XML 규격의 원문 버전은, 모든 텍스트와 법률적 경고에 합당하면, 배포를 자유롭게 할 수 있다.

1.2 용어

용어들은 이 규격 본체에서 XML 문서들을 기술하는데 사용되었다. 다음 목록에 정의된 용어들은 이 규격을 구성하는 정의들과 XML 처리자(processor)의 활동을 설명하는데 사용된다:

할 수 있다(may)

규격에 부합하는 문서들과 XML 처리자들은 허용되나, 설명된 바와 일치하지 않아도 된다.

하여야 한다(must)

규격에 부합하는 문서들과 XML 처리자들은 반드시 설명된 바와 일치 할 필요가 있으며, 그렇지 않으면 오류가 된다.

오류

이 규격의 규칙을 위반하는 것으로 그 결과는 정의되어 있지 않다. 규격에 부합하는 소프트웨어는 오류를 감지하고, 알리며, 회복하게 할 수 있다.

치명적 오류

규격에 부합하는 XML 처리자(processor)는 오류를 감지하고, 그 적용(application)에 알려야 한다. 치명적인 오류를 만난 다음, 처리자는 추가적인 오류들을 감지하기 위하여 계속 데이터를 처리 할 수 있고, 그와 같은 오류들을 적용에 알릴 수 있다. 오류들의 보정을 지원하기 위하여 처리자는 문서로 부터 처리되지 않은 데이터를, (글자 데이터와 코드마크업을 혼합하여) 적용이 사용 할 수 있는 것으로, 만들 수 있다. 그러나, 일단 치명적 오류가 감지되면, 처리자(processor)는 정상 처리를 계속하여서는 않된다. (말하자면, 정상적인 방법으로 글자 데이터와 문서의 논리적 구조에 대한 정보의 적용에게 전달을 중단하여야 한다.)

사용자의 선택으로

규격에 부합하는 소프트웨어는 문장 속의 내용에 따라 설명된 바와 같이, 할수 있거나, 하여야 한다. 만일 선택사항이 있으면, 이는 사용자가 설명된 작용을 가능하게 하거나, 중지 시킬 수 있는 수단을 제공한다.

유효성 검정 기준(제한사항)

모든 유효(valid) XML 문서들에 적용되는 규칙이다. 유효성 제한요소의 위배하는 것은 오류들이다; 사용자 선택으로 유효성 검정 XML 처리자(processor)에 의하여 알려 줘야한다.

잘 형성됨을 위한 필수사항

모든 잘 형성된 XML 문서들에 적용되는 규칙이다. 잘 형성됨을 위한 필수사항들을 위배하는 것은 치명적 오류들이다.

일치

(스트링이나 이름의 일치): 비교되는 두개의 스트링이나 이름들이 꼭 같아야 한다. ISO/IEC 10646 에서 여러 가능한 표현(예를 들어 사전 조합된 것과 베이스+구분적 양식의 글자들)의 글자들이 양쪽 스트링에서 같은 표현을 가질 때만 일치한다. 사용자 선택으로, 처리자(processor)는 이와 같은 글자들을 정규의 양식으로 정상화(일반화) 시킬 수 있다. 대소문자의 전환은 사전에 형성되지 않는다.

(문법에서 스트링과 코드(rule)의 일치): 그 작업으로 생성된 언어에 속하면, 스트링은 문법적 생성과 일치한다.

(내용(content)과 내용 모델(model)의 일치): "엘레멘트 유효성" 제한요소에 설명된 형태와 맞으면, 엘레멘트(element)는 그 선언과 일치한다.

규격부합성(compatibility)을 위하여

순전히 XML이 SGML과의 규격부합성을 유지함을 확실히 하기 위한, XML에 포함된 성능(feature)이다.

공통사용성(interoperability)을 위하여

기존 설치된 SGML 처리자(processor)들의 기초(ISO 8879로 폐기 된 WebSGML 적용 색인)에서, XML 문서들이 처리 될 가능성을 향상하기 위하여, 비 구속적으로, 포함한 추천사항이다.

2. 문서들

이규격에 정의된 바에 따라 잘 형성된 것이면, 데이터 오브젝트(object)는 하나의 XML 문서이다. 잘 형성된 XML 문서는 또한, 추가적인 제한요소들에 맞으면, 유효(valid) 할 수 있다.

각 XML 문서는 논리적 구조와 물리적 구조를 갖는다. 물리적으로, 문서는 엔티티(entity)라 불리우는 단위들로 이루어 진다. 한 엔티티(entity)는 다른 엔티티를 참조(refer) 할 수 있으며, 그 문서 안에 포함되게 된다. 한 문서는 최상위("root") 또는 문서 엔티티(entity)로 시작된다. 논리적으로, 문서는 선언, 엘레멘트(element), 코멘트(comment), 글자 참조와 처리지시(processing instruction)들로 이루어 지며, 이들 모두 그 문서의 명시적 코드(markup)로 지정된다. 논리적 구조와 물리적 구조는, "4.3.2 잘 형성되고 해석(parse)된 엔티티(entity)"에 설명된 바와 같이, 적정하게 네스트(nest)되어야 한다.

2.1 잘 형성된 XML 문서들

텍스트적 오브젝트(object)는 다음을 만족시키면 잘 형성된 XML 문서이다:

1. 전체적으로, 라벨된(labeled) 문서 산물과 일치한다.
2. 이규격에서 주어진 잘 형성됨을 위한 필수사항들에 부합한다.
3. 문서에서 직접 혹은 간접적으로 참조된 각 해석(parse)된 엔티티가 잘 형성된 것이다.

일치하는 문서(document) 산물(production)은 다음 사항을 내포(의미)한다:

1. 하나 이상의 엘레멘트(element)를 포함한다.
2. 최상위(root)라 불리우는 엘레멘트 또는 문서 엘레멘트 단 하나 만을 가지며, 이들 부분이 어떤 다른 엘레멘트의 내용(content) 안에 나타나지 않는다. 모든 다른 엘레멘트들에서, 또 다른 엘레멘트의 내용 속에 시작태그가 있으면, 종료태그도 같은 엘레멘트의 내용 속에 있다. 좀 더 간단히 말하면, 시작과 종료태그들로 구분되는 엘레멘트들은 서로 적정하게 네스트(nest) 되어있다.

이 결과로서, 문서에서 최상위가 아닌(non-root) 각 엘레멘트 'C'에게는, 'C'는 'P'의 내용 안에 있으나, 'P'의 내용에 있는 어떤 다른 엘레멘트의 내용이 않되록, 문서에서 다른 엘레멘트 'P'가 있다, 여기서 'P'는 C의 모체(parent)로 참조되고, 'C'는 'P'의 자식(child)으로 참조된다.

2.2 글자

해석(parse)된 엔티티(entity)는 텍스트를 갖는데, 이는 글자들의 연속으로, 코드(markup)나 글자 데이터가 될 수 있다. 한 글자는, ISO/IEC 10646 [ISO/IEC 10646]에 지정 된 바와 같이, 텍스트의 기초 단위이다. 올바른(legal) 글자들은 탭(tab), 리턴(enter), 줄공급(새줄 널기), 올바른 Unicode와 ISO/IEC 10646의 그래픽 글자들이다. [Unicode] 항목 6.8에서 정의된 "규격부합성(compatibility) 글자들"의 사용은 하지 않는 것이 좋다.

이진수(bit) 패턴으로 코드 포인트(code point) 글자 엔코딩하는 기구(mechanism)는 엔티티(entity)에 따라 서로 다르다. 모든 XML 처리자(processor)는 10646 의 UTF-8 와 UTF-16 엔코딩(encoding)을 수용하여야 한다. 이 두가지 중 어느 것이 사용되는가 신호 보내는 기구, 또는 다른 엔코딩을 가져다 쓰는 기구는 뒤 4.3.3 "엔티티의 글자 엔코딩"에서 다룬다.

2.3 공통(common) 문법적 구성

여기서는 문법에서 널리 사용되는 일부 기호(symbol)들을 정의한다.

S (공백: space)은 한개 이상의 공백글자(space: #x20), 리턴(enter), 줄공급(새줄 넣기), 탭(tab)들로 구성된다.

글자들은 편이상 글자, 숫자(digit)와 다른 글자들로 분류된다. 글자(letter)는 알파베트(alphabetic), 음절 기초글자(syllabic base)와 하나 이상의 조합된 글자, 표식글자(ideographic)들로 구성된다. 각 분류 내 특정 글자들의 완전한 정의는 B. "글자 분류"에 설명되었다.

이름(Name)은, 글자 또는 한개의 구둣점 글자(몇가지 중)로 시작되고, 글자나 숫자, 하이픈(-), 밑줄(_), 콜론(:) 또는 점(.)를 로 알려진 글자들을 계속적으로 갖는, 하나의 토큰(token)이다. 스트링 "xml" 혹은 (('X'|'x') ('M'|'m') ('L'|'l'))와 일치하는 다른 스트링으로 시작하는 이름은 이 규격과 향후 버전들에 표준화를 위하여 예약된 것이다.

주석: XML 이름 안의 콜론(:) 글자는 이름 자리를 실험하기 위해 예약된 것이다. 이는 향후 어느 싯점에서 표준화 될 것으로 기대되며, 그 싯점에서 문서에 실험 목적으로 사용하는 콜론을 갱신 될 수 있슴을 의미한다. (XML에서 이름자리(name-space) 기구(mechanism)에 이름자리 구분자(delimiter)로 콜론을 실제로 채택 할 것인가에 대한 보증은 없다.) 실제로 이는 제작자가 콜론을 이름자리 실험 이외에는 XML 이름에 사용하지 말아야 하고, XML 처리자(processor)는 콜론을 이름 글자로 받아들여야 한다는 것을 의미한다.

Nmtoken (이름 토큰)은 어떤 이름글자들의 혼합체이다.

리터랄(literal) 데이터는, 그 스트링의 구분자로 사용된 따옴표를 제외하고, 따옴표 속의 스트링이다. 리터랄 데이터는 내부적 엔티티(entity)의 내용(EntityValue), 애트리뷰트(attribute)의 값(AttValue)과 외부적 인식자(identifier: SystemLiteral)들을 지정하는데 사용된다. SystemLiteral은 코드(markup)의 처리(scanning) 없이 해석(parse) 될 수 있다는 점에 주의하라.

2.4 글자 데이터와 코드(markup)

텍스트는 글자 데이터와 코드(markup)의 혼합으로 구성되어 있다. 코드(markup)는 시작태그(tag), 종료태그, 빈 엘레멘트 태그, 엔티티(entity) 참조, 글자 참조, 코멘트, CDATA 항목 구분자(delimiter), 문서 타입 선언(document type declaration), 처리지시(processing instruction)들의 양식을 갖는다.

코드를 구성하니 않는 모든 텍스트는 문서의 글자 데이터이다.

코드(markup) 구분자로 사용거나, 또는 코멘트(comment), 처리지시(processing instruction) 또는 CDATA 항목 안에서 만 앰퍼샌드 글자(&)와 왼쪽 꺽쇄(<)가 그 리터랄(literal) 양식에 나타날 수 있다. 그들은 또한 내부적 엔티티(entity) 선언(declaration)의 리터랄 엔티티 값 안에서도 올바른(legal) 것이다. 항목 4.3.2 "잘 형성되고 해석(parse)된 엔티티"를 참조하라. 만일 다른 곳에서 필요하면 각각, 숫치(numeric) 글자 참조나 "&" 스트링과 "<"를 사용하여 에스케입(escaped) 되어야 한다. 오른쪽 꺽쇄(>)는 스트링 ">"를 사용하여 표현 할 수 있으며, 내용 속의 스트링 "]]>" 안에 나타나고 CDATA 항목의 종료을 만들지 않으때는, 규격부합성을 위하여, 반드시 ">"을 사용하여 에스케입(escaped) 되거나 글자 참조이어야 한다.

엘레멘트의 내용에서, 글자 데이터는, 어떤 코드(markup)의 시작구분자를 포함하지 않는, 글자들의 스트링이다. CDATA 항목에서, 글자 데이터는, CDATA 항목을 닫는 구분자(delimiter)인 "]]>"를 포함하지 않는, 글자들의 스트링이다.

애트리뷰트 값에 단일, 이중 따옴표들의 포함을 허용하려면, 단일 따옴 글자(')는 "'"로, 이중 따옴 글자(")는 """로 표현 할 수 있다.

2.5 코멘트(comment)

문서에서 코멘트는 다른 코드(markup) 밖 어디에나 나타 날 수 있고, 또한, 문서 타입 선언(document type declaration) 안, 문법에 의하여 허용 된 장소에 나타 날 수 있다. 이들은 문서의 글자 데이터 부분이 아니다. XML 처리자(processor)는, 필요한 것은 아니지만, 적용(application)이 코멘트 텍스트를 읽게 할 수 있다. 규격부합성을 위하여, 스트링 "--"는 코멘트 속에 나타나지 말아야 한다.

코멘트의 예제:

2.6 처리지시

처리지시(processing instruction: PI)는 문서들이 적용(application)을 위해 지시를 포함 할 수 있게 한다.

PI는 문서의 글자 데이터 부분이 아니고, 적용(application)에 전달하여야 한다. PI는 지시가 어느 적용으로 향할 것인가를 지정하는데 사용하는 목표(PITarget)로 시작한다. 목표(target) 이름 "XML", "xml" 등은 표준화나 이규격의 향후 버전 위해 예약되었다. XML 주석(notation) 기구(mechanism)가 공식적인 PI 목표 선언에 사용 될 수 있다.

2.7 CDATA 항목

CDATA 항목은 글자 데이터가 나타 날 수 있는 어디에나 나타날 수 있고, 이들은, 그렇지 않으면 코드(markup)로 인식되는, 글자들을 포함하는 텍스트 블럭을 에스케입(escape) 하는데 사용된다. CDATA 항목은 스트링 "<![CDATA["로 시작되고 스트링 "]]>"로 끝난다.

CDATA 항목 안에서는, CDEnd 스트링 만이 코드(markup)로 인식된다. 그래서 외쪽 꺽쇄(<)와 앰퍼샌드(&)들이 그 리터랄(literal) 양식 안에 나타날 수 있다; 이들은 "<"와 "&"를 사용하여 에스케입(escape) 될 필요가 없으며 될 수도 없다. CDATA 항목들은 네스트(nest) 될 수 없다.

CDATA 항목의 예제, 여기서 "<greeting>"와 "</greeting>" 사이는 코드(markup)로 인식되지 않고 글자 데이터로 인식된다:

2.8 서문(prolog)과 문서 타입 선언(document type declaration)

XML 문서들은 사용된 XML의 버전을 지정하는 XML 선언으로 시작 할 수 있으며, 시작하여야 한다. 예를 들어, 아래는 완전한 XML 문서이고, 잘 형성된 것이지만 유효(valid)하지는 않다:

이것도 같다:

버전 번호 "1.0"이 이규격의 이 버전의 규격부합성을 나타내기 위하여 사용되어야 한다; 이규격의 이 버전에 부합하지 않는 경우, 값 "1.0"을 사용한 문서는 오류이다. 향후 이규격의 버전들은 "1.0"과 다른 수치를 부여하고저 하는 것이 XML 작업구룹의 의도이지만, 향후 XML의 버전을 만들 것인가, 만들면 어떤 번호 붙이는 방식을 사용 할 것인가를 확인하고 있지는 않다. 향후 버전들에 대한 결정이 없으므로, 이 구성은 자동 버전 인식의 가능성을 허용하는 수단을 제공하며, 필요 할 것이다. 처리자(processor)는, 지원되지 않는 버전들로 라벨된 문서들을 받았을 때, 오류 신호를 보낼 수 있다.

XML 문서에서 코드(markup)의 기능(function)은, 그 저장과 논리적 구조, 연관된 애트리뷰트 값과 짝이되는 그 논리적 구조를 기술하기 위한 것이다. XML은 문서 타입 선언(document type declaration), 논리적 구조의 제한요소 정의와 사전에 정의된 저장 단위들의 사용을 지원하는 기구(mechanism)를 제공한다. 만일 연관된 문서 타입 선언를 갖고 있고, 문서가 그 안에 나타난 제한요소에 맞는다면, XML 문서는 유효(valid)하다.

문서 타입 선언은 문서 안에서 최초의 엘레멘트(element)보다 먼저 나와야 한다.

XML 문서 타입 선언(document type declaration)는 문서의 분류를 위하여 문법을 제공하는 코드 선언들을 포함하거나 지명한다. 이 문법은 문서 타입 정의(DTD: document type definition)로 알려져 있다. 문서 타입 선언은 외부적 하부세트(외부적 엔티티의 특별한 종류)나 포함하는 코드(markup) 선언들를 지명 할 수 있고, 또는, 내부적 하부세트(subset) 안에 직접적으로 코드 선언들을 포함 할 수 있고, 둘 다 할 수도 있다. 문서의 DTD는 두가지 하부세트들이 같이 구성된다.

코드 선언은 is 엘레멘트 타입 선언, 애트리뷰트 목록 선언, 엔티티 선언, 또는 주석(notation) 선언이다. 이 선언들은,아래 설명된 바와 같은 잘 형성되고 유효성 제한요소에 따라 , 전부 혹은 일부를 파라메터(parameter) 엔티티 안에 포함 할 수 있다. 상세한 정보는 4. "물리적 구조"를 참조하라.

코드(markup) 선언들은 파라메터(parameter) 엔티티의 교체 텍스트 전부나 일부분으로 만들어 질 수 있다. 이규격의 나중 부분에 개별 비 터미널(nonterminal)들을 위한(elementdecl, AttlistDecl 등) 모든 파라메터 엔티티(entity)들이 포함 된 다음에 선언들의 설명이 되었다.

유효성 제한요소: 최상위(root) 엘레멘트(element) 타입
문서 타입 선언의 이름(Name)이 최상위 엘레멘트의 엘레멘트 타입과 일치하여야 한다.

유효성 제한요소: 적정 선언/PE 네스팅
파라메터(parameter) 엔티티(entity) 교체 텍스트는 코드(markup) 선언들과 적정하게 네스팅(nest)되어야 한다. 말하자면, 코드(markup) 선언(위 markupdecl)의 첫 글자나 마지막 글자가 파라메터 엔티티 참조의 교체 텍스트 안에 포함되어 있으면, 둘 다 같은 교체 텍스트 안에 포함되어야 한다.

잘 형성됨을 위한 필수사항: 내부적 하부세트(subset) 안의 PE
내부적 DTD 하부세트에서, 파라메터 엔티티 참조는, 코드(markup) 선언들 안에는 나올 수 없고, 코드 선언들이 나올 수 있는 곳에 만 나올 수 있다. (이는 외부적 파라메터(parameter) 엔티티(entity) 안에서 또는 외부적 하부세트에 나오는 참조에 대해서는 적용되지 않는다.)

내부적 하부세트와 마찬가지로, DTD 안에서 참조하는 외부적 하부세트와 외부적 파라메터 엔티티는, 비 터미널 기호(symbol) markupdecl에 의하여 허용되는 타입의, 공백으로 분린된 또는 파라메터 엔티티 참조의, 일련의 완전한 코드선언들로 구성되어야 한다. 그러나 외부적 하부세트나 외부적 파라메터 엔티티의 내용(content) 부분들이, 조건적 항목 구성을 사용하여, 조건에 따라 무시 될 수 있다; 이는 내부적 하부세트에서는 허용되지 않는다.

외부적 하부세트(subset)와 외부적 파라메터(parameter) 엔티티(entity)는 또한 그 안의 내부적 하부세트에서와 다른데, 파라메터 엔티티 참조는 코드(markup) 선언들 사이에서 뿐 아니라, 속에서도 허용된다.

문서 타입 선언(document type declaration)을 갖는 XML 문서 예제:

시스템 인식자(identifier) "hello.dtd"는 문서를 위한 DTD의 URI를 제공한다.

그 선언들은 예제와 같이 지역적으로 주어 질 수 있다:

외부적과 내부적 하부세트(subset)들이 다 사용되면, 내부적 하부세트가 외부적 하부세트보다 먼저 나온 것으로 간주된다. 내부적 하부세트에 있는 엔티티(entity)와 애트리뷰트 목록 선언들이 외부적 하부세트에 있는 것에 우선하여 작용하는 효과를 갖는다.

2.9 독립 문서 선언(Standalone Document Declaration)

코드(markup) 선언들은 XML 처리자(processor)로부터 적용(application)에 전달함에 따라 문서에 내용에 영향을 줄 수 있다; 예를 들면 애트리뷰트(attribute) 디폴트들과 엔티티(entity) 선언들이다. 독립 문서 선언은 XML 선언의 부분으로 나타날 수 있으며, 문서 엔티티에 외부적으로 이와 같은 선언들이 있는가 없는가의 신호를 준다.

독립 문서 선언(Standalone Document Declaration)에서, 값 "yes"는, XML 처리자(processor)로부터 적용(application)에 전달되는 정보에 영향을 주는, 문서 엔티티(DTD에 외부적 하부세트이나, 내부적 하부세트들로 부터 참조되는 외부적 파라메터 엔티티)에 외부적인 코드(markup) 선언이 없슴을 나타낸다. 값 "no"는 이와 같은 외부적 코드 선언들이 있거나, 있을 수 있슴을 나타낸다. 독립 문서 선언은 단지 외부적 선언들의 존재를, 이들 엔티티들이 내부적으로 선언되었으면 문서에서 외부적 엔티티로 참조함의 존재를 나타내고, 그 독립성의 상태는 변하지 않음에 주의하라.

만일 외부적 코드 선언들이 없으면, 독립 문서 선언은 아무 의미를 갖지 않는다. 외부적 코드 선언들이 있으나 독립 문서 선언이 없으면, 그 값은 "no"로 간주된다.

standalone="no"을 같고 있는 XML 문서는 변환 기능(algorithmically)으로 독립 문서로 변환 될 수 있으며, 이는 일부 네트워크 배달(전달) 적용에 바람직 할 수 있다

유효성 제한요소: 독립 문서 선언(Standalone Document Declaration)
독립 문서 선언이 값 "no"를 가지면 외부적 코드(markup) 선언들은 다음의 선언들을 포함한다:

• 이 애트리뷰트들이 적용되는 엘레멘트가 문서 안에 나타나는데, 이 애트리뷰트의 값들이 지정되지 않았으면, 디폴트 값들을 갖는 애트리뷰트들, 또는
• 문서 안에서 이들 엔티티(entity)들을 참조하면, amp, lt, gt, apos, quot 이외의 엔티티, 또는
• 정상화(normalization) 될 값들을 갖는 애트리뷰트들, 여기서, 정상화(normalization)의 결과 바뀔 값을 갖는 애트리뷰트(attribute)가 문서에 나타난다, 또는
• 이들 타입들의 인스탄스(instance) 안에 공백이 직접적으로 나타나면, 엘레멘트 내용을 갖는 엘레멘트 타입들.

독립 문서 선언(Standalone Document Declaration)을 갖는 XML 선언의 예제:

2.10 공백의 처리

XML 문서들을 작성하는데, 자주 "공백"(이규격에서 비터미널 S로 표기한 공간, 탭, 빈줄)을 사용하기 위하여 변환하여, 코드를 훨신 읽기 쉽게한다. 이와 같은 공백은 전형적으로 이 문서의 버전에 포함하기 위하여 의도된 것은 아니다. 이와는 달리 "상당한" 공백이 유지되어야 하는 경우가 많이 있는데 시 문구나 소스코드가 그 예이다.

XML 처리자는 항상 문서 안의 비 코드(markup)의 모든 글자들을 적용(application)에 전달하여야 한다. 유효성 검정 XML 처리자는 또한 적용에게, 엘레멘트 내용 안에 나타나는 공백을 구성하는 이 글자들에 대한, 정보를 제공하여야 한다.

공백이 적용에서 그대로 유지되도록, 엘레멘트에 의도하는 신호를 보내기 위하여, 'xml:space'로 이름 지워진 특별한 애트리뷰트가 엘레멘트(element)에 첨부 될 수 있다. 유효한(valid) 문서들에서, 이 애트리뷰트는 다른 것과 마찬가지로, 이것이 사용되면, 선언되어야 한다. 선언되면, 값들은 디폴트("default")와 유지("preserve") 만이 가능한 숫자주기(enumerated) 타입이 되어야 한다. 예를 들어:

값 "default"는 적용(application)의 이 엘레멘트 디폴트 공백처리 과정이면 만족스럽다는 신호를 보내고; 값 "preserve"는 모든 공백을 그대로 유지하겠다는 의도를 적용에 알려준다. 이 선언된 의도는 내용 안 지정된 그 엘레멘트의 모든 엘레멘트들에, 다른 'xml:space' 애트리뷰트의 인스탄스로 덮어 씌우기 되지 않는 한, 적용 할 것으로 간주된다.

문서의 최상위(root) 엘레멘트는, 이 애트리뷰트의 값이 제공되거나, 애트리뷰트가 디폴트 값으로 선언되지 않는 한, 적용의 공백 처리에 의도가 없다는 신호를 받은 것으로 간주한다.

2.11 줄 끝의 처리(End-of-Line Handling)

XML로 해석(parse)된 엔티티는 자주 컴퓨터 화일들로 저장된며, 편집의 편이성을 위하여, 줄(line)들로 만들어 진다. 이 줄들은 전형적으로 리턴(carriage-return: '#xD')과 줄공급(line-feed: '#xA') 글자들의 조합으로 분리된다.

적용(applications)의 임무를 단순화 하기 위하여, 내부적으로 해석(parse)된 엔티티의 외부적으로 해석된 엔티티나 리터랄(literal) 엔티티 값이 리터랄 연속 두 글자 "#xD#xA" 또는 단일 글자 "#xD"이면 언제나, XML 처리자(processor)는 적용(application)에게 단일 글자 "#xA"를 전달하여야 한다. (이 활동은, 해석 전에 정상화에 의하여 모든 줄바꿈을 입력(input)에서 "#xA"로 편리하게 생성 할 수 있다.)

2.12 언어의 인식

문서 처리에서, 그 문서가 작성된 내용의 자연 혹은 공식 언어를 지정하는 것이 자주 유용하다. 'xml:lang'로 이름지워 진 특별 애트리뷰트가 문서에 삽입되어 내용에 사용된 언어를 지정 할 수 있고, XML 문서의 어떤 엘레멘트 애트리뷰트 값을 지정 할 수 있다. 유효한(valid) 문서들에서, 이 애트리뷰트(attribute)는 다른 것과 마찬가지로, 사용되면 선언되어야 한다. 애트리뷰트의 값들은 [IETF RFC 1766], "언어를 인식하기 위한 태그들"에 정의 된 바와 같은 언어 인식자(identifier)들이다:

Langcode는 아래 것 중의 하나가 될 수 있다:

• [ISO 639]의 "언어들의 이름을 나타내는 코드"에 정의된 두글자 언어 코드
• '인터넷 할당 번호 당국'[IANA](Internet Assigned Numbers Authority)에 등옥된 언어 인식자(identifier); 이는 "i-"(또는 "I-")의 접두어로 시작된다.
• 사용자에 의하여, 혹은 개인적 사용에서 당사자끼리 합의하여 지정된 언어 인식자(identifier); 이는 IANA에 향후 표준화되거나 등록될 이름과 마찰하지 않도록 확실히 하기 위하여 접두어 "x-" 또는 "X-" 로 시작되어야 한다.

어떤수의 하부코드(Subcode) 부분(segment)들이 있을 수 있다; 만일 하부코드가 있고 두개의 글자로 구성되어 있으면, 이는 [ISO 3166]의 "국가들의 이름을 표현하는 코드들"에서 왔을 것이며, 만일 처음 하부코드가 두개보다 많은 글자로 구성되어 있으면, Langcode가 접두어 "x-" 혹은 "X-"로 시작하지 않는 한, 이는 IANA에 등록된 언어 하부코드 일 것이다.

습관적으로 언어코드는 소문자로, 국가코드는 (있으면) 대문자로 주어진다. 이 값들은 XML 문서에서 다른 이름들과는 다르게 대소문자를 구별하지 않는다는 점에 주의하라.

예를 들어:

의도적으로 'xml:lang'로 선언된 것은, 그 내용 안에서 다른 엘레멘트에 'xml:lang' 인스탄스(instance)를 사용하여 덮어씌움을 하지 않는 한, 그 정의 된 엘레멘트(element)의 모든 애트리뷰트(attribute)들과 내용(content)에 적용하는 것으로 간주된다.

'xml:lang'의 간단한 선언은 아래 양식을 갖는다;

그러나, 적정하다면, 특정 디폴트 값들이 주어 질 수도 있다. 영국 학생들에게 불어 시들의 모음에서, 설명과 주석은 영어로 할 때, 'xml:lang' 애트리뷰트는 다음과 같이 선언 될 수 있다:

3. 논리적 구조

각 XML 문서는 하나 이상의 엘레멘트(element)들 갖고, 그 범위는 시작태그와 종료태그, 또는 빈(empty) 엘레멘트에서는 빈 엘레멘트 태그(tag)로 구분된다. 각 엘레멘트는 타입(type)을 갖고, 때로는 "특유 인식자"(GI: Generic Identifier)로 불리우는 이름으로 인식되고, 일련의 애트리뷰트 규격들을 가질 수 있다. 각 애트리뷰트(attribute)의 규격은 이름(name)과 값을 갖는다.

이규격은, 그 이름이 이규격의 표준화나 향후 버전들을 위한 예약어와 일치하는 (('X'|'x')('M'|'m')('L'|'l'))로 시작하는 것을 제외하고는, 엘레멘트 타입들과 애트리뷰트들의 문법(semantic), 사용, 또는 (문법 이외의) 이름을 제한하지 않는다.

잘 형성됨을 위한 필수사항: 엘레멘트 타입일치(Element Type Match)
엘레멘트(element)의 종료태그 안의 Name(이름)은 시작태그 안의 엘레멘트 타입과 일치하여야 한다.

유효성 제한요소: 엘레멘트 유효(Element Valid)
이름(Name)이 그 엘레멘트 타입에 일치하는 elementdecl와 일치하는 선언이 있으면, 엘레멘트가 유효(valid)하며, 다음 중 하나에 해당한다:

1. 선언이 'EMPTY'(빈것)와 일치하고, 엘레멘트가 내용(content)을 갖고 있지 않다.
2. 선언이 자식(child)들과 일치하고, 자식 엘레멘트들의 연속이, 내용 모델(model) 안의 일반적 지정(expression)으로 생성된 언어에 소속되어 있고, 자식 엘레멘트들의 각 짝 사이에 선택적 공백(글자가 비 터미널 S와 일치하는)을 가지고 있다.
3. 선언이 Mixed(혼합)와 일치하고, 그 내용이 글자 데이터와 그 타입이 내용 모델(model)의 이름과 일치하는 자식 엘레멘트들로 구성되었다.
4. 선언이 ANY와 일치하고, 어떤 자식(child) 엘레멘트의 타입이 선언되었다.

3.1 시작태그, 종료태그, 빈 엘레멘트 태그

빈것이 아닌 각 XML 엘레멘트(element)의 시작은 시작태그로 표시되어 있다.

시작태그와 종료태그 안에 이름(Name)이 엘레멘트(element)의 타입(type)을 지정한다. Name - AttValue의 짝들은 그 엘레멘트의 애트리뷰트 규격으로, 각 짝의 Name은 애트리뷰트 이름과 애트리뷰트 값으로 AttValue(' 또는 " 구분자들 사이의 텍스트)의 내용으로 참조된다.

잘 형성됨을 위한 필수사항: 유일 애트리뷰트 규격(Unique Att Spec)
같은 시작태그 또는 빈 엘레멘트 태그 안에서 같은 애트리뷰트(attribute) 이름이 나와서는 않된다.

유효성 제한요소: 애트리뷰트 값 타입(Attribute Value Type)
애트리뷰트는 선언되어 있어야 한다; 그 값은 이를 위한 선언된 타입이어야 한다. (애트리뷰트 타입은 3.3 "애트리뷰트 목록 선언"을 참조하라.)

잘 형성됨을 위한 필수사항: 외부적 엔티티 참조가 없어야 함(No External Entity References)
애트리뷰트 값들은 외부적 엔티티에 대한 직접적 혹은 간접적 엔티티 참조를 포함 할 수 없다.

잘 형성됨을 위한 필수사항: 애트리뷰트 값에 '<'가 없어야 함
애트리뷰트 값에서 직접적 혹은 간접적으로 참조된 엔티티(entity)의 교체 텍스트("<" 이외의)는 '<'를 포함 할 수 없다.

시작태그의 예제:

시작태그로 시작된 각 엘레멘트(element)는, 시작태그에서 주어진 엘레멘트 타입을 복사한 이름을 포함하는, 종료태그로 표시하여야 한다:

종료태그의 예제:

시작태그와 종료태그 사이의 텍스트를 엘레멘트의 내용이라 한다:

만일 엘레멘트가 비어(empty) 있으면, 이는 시작태그가 열리자 마자 종료태그가 온 것이 거나 빈 엘레멘트 태그이다. 빈 엘레멘트 태그는 특수한 양식을 갖는다:

빈 엘레멘트 태그는 내용(content)이 없는 어느 엘레멘트에도 사용 될 수 있으며, 'EMPTY' 키워드(keyword)로 선언된다. 공통사용성(interoperability)을 위하여, 빈 엘레멘트 태그가 사용되어야 하며, 'EMPTY'로 선언된 엘레멘트들에서 만 사용 될 수 있다.

빈(empty) 엘레멘트의 예제:

3.2 엘레멘트 타입 선언

XML 문서의 엘레멘트(element) 구조는, 유효성 검정(validation) 목적으로, 엘레멘트 타입과 애트리뷰트 목록 선언들을 사용하여 제한을 줄 수 있다. 엘레멘트 타입 선언은 엘레멘트(element)의 내용(content)에 제한을 준다.

엘레멘트 타입 선언은 자주 어떤 엘레멘트 타입들이 엘레멘트의 자식(child)들에 나타날 수 있는가의 제한을 준다. 사용자의 선택으로, 선언이 되지 않은 엘레멘트 타입의 선언이 나타나면, XML 처리자(processor)는 경고를 발생 시킬 수 있는데, 이것은 오류가 아니다.

엘레멘트 타입 선언은 다음과 같은 양식을 갖는다:

여기서 이름(Name)은 선언되는 엘레멘트의 타입을 준다.

유효성 제한요소: 유일한 엘레멘트 타입 선언
같은 엘레멘트(element) 타입이 다시 선언 될 수 없다.

엘레멘트 타입 선언의 예제:

3.2.1 엘레멘트 내용

엘레멘트(element) 타입(type)은, 그 타입의 엘레멘트가 자식(child) 엘레멘트들(글자 데이터는 안되고) 만을 포함하여야 하며, 선택적으로 공백(글자가 비 터미날 S와 일치)으로 분리되면, 엘레멘트 내용(content)을 갖는다. 이 경우, 내용 모델(model), 그 자식 엘레멘트들의 허용된 타입들을 관할하는 단순 문법과, 그들이 나타 날 수 있는 순서의 제한사항을 포함한다. 문법은 내용 조각(cp: content particle)에 만들며, 이는 이름, 내용 조각의 선택 목록, 또는 내용 조각(particle)들의 순서 목록들로 구성된다:

여기서 각 이름(Name)은 자식(child)에 나타날 수 있는 엘레멘트(element)의 타입이다. 선택 목록의 어떤 내용(content) 조각(particle)도 엘레멘트 내용 안의 문법에서 선택 목록이 나타나는 위치에 나타날 수 있다; 일련의 목록 안에서 나오는 내용 조각들은 그 목록 안에서 주어진 순서로 그 엘레멘트 내용에 각각 나타나야 한다. 이름이나 목록 뒤의 선택적 글자가 목록 안에서 엘레멘트나 내용 조각들이 한번 이상(+), 한번도 없거나 여러번(*), 한번 나오던가 안 나오던가(?)하는 것을 결정한다. 이와 같은 오퍼레이터(operator)가 없으면, 엘레멘트나 내용 조각이 꼭 한번 나와야 한다는 것을 의미한다. 이 문법과 의미는 이규격의 제작에 사용된 것과 동일하다.

내용(content) 모델(model)을 통하여 경로(path)를 추적 할 수 있고, 순서에 따르고, 선택하였고, 반복적 오퍼레이터(operator)이고, 내용의 각 엘레멘트가 내용(content) 모델(model)의 엘레멘트 타입에 대하여 일치 할 때에 한해서, 엘레멘트의 내용은 내용 모델과 일치한다 규격부합성(compatibility)을 위하여, 문서의 엘레멘트가 내용 모델의 엘레멘트(element) 타입과 한번 이상 일치하면 오류이다. 자세한 정보는 E. "판정적 내용 모델"을 참조하라.

유효성 제한요소: 적정 구룹/PE 네스팅(Proper Group/PE Nesting)
파라메터(parameter) 엔티티(entity) 교체 텍스트는 괄호 속에 들어간 구룹들로 적정하게 네스팅(nest)되어야 한다. 다시 말하면, 'choice', 'seq' 또는 'Mixed' 구성 안의 열림이나 닫힘 괄호들이 파라메터(parameter) 엔티티 교체 텍스트 안에 포함되면, 둘 다 같은 교체 텍스트 안에 포함되어야 한다. 공통사용성(interoperability)을 위하여, 만일 파라메터(parameter) 엔티티(entity) 참조가 'choice', 'seq' 또는 'Mixed' 안에 나타나면, 그 교체 텍스트는 빈것이 아니어야 하고, 교체 텍스트의 처음이나 마지막 공백글자가 아닌 글자가 ('|' 혹은 ',')의 연결자(connector)가 아니어야 한다.

엘레멘트 내용 모델의 예제:

3.2.2 혼합 내용(mixed content)

그 타입의 엘레멘트가 어떤 글자 데이터를 가질 수 있고, 선택적으로 자식(child) 엘레멘트(element)들에 분산되었으면, 그 엘레멘트 타입(type)은 혼합 내용을 갖는다. 이 경우, 자식 엘레멘트들의 타입은 제한 될 수 있으나, 그들의 순서나 나타나는 갯수는 제한 될 수 없다:

여기서 이름(Name)들이 자식(child)들로 나타날 수 있는 엘레멘트 타입을 제공한다.

유효성 제한요소: 타입 중복없슴(No Duplicate Types)
같은 이름이 단일 혼합 내용 선언 안에서 나타나지 말아야 한다.

혼합 내용 선언 예제:

3.3 애트리뷰트 목록 선언

엘레멘트(element)의 이름과 값의 짝들을 연관시키기 위하여 애트리뷰트(attribute)들이 사용된다. 애트리뷰트 규격들은 시작태그와 빈 엘레멘트 태그들 안에 만 나타날 수 있다; 그래서, 이들을 알기 위 한 것은 3.1 "시작태그, 종료태그, 빈 엘레멘트 태그"에 기술되었다. 애트리뷰트 목록 선언들은 다음의 경우에 사용 될 수 있다:

• 주어진 엘레멘트(element) 타입의 애트리뷰트들의 설정을 지정하기 위하여
• 애트리뷰트(attribute)에 타입 제한요소를 설정하기 위하여
• 애트리뷰트에 디폴트 값들을 제공하기 위하여

애트리뷰트 목록 선언들은 주어진 엘레멘트(element) 타입에서 관련된 각 애트리뷰트(attribute)의 이름, 데이터 타입과 디폴트 값(있으면)들을 지정한다:

AttlistDecl 코드(rule) 안의 이름(Name)은 엘레멘트(element)의 타입(type)이다. 사용자의 선택으로, 선언이 되지 않은 엘레멘트 타입의 선언이 나타나면, XML 처리자(processor)는 경고를 발생 시킬 수 있는데, 이것은 오류가 아니다. AttDef 코드(rule) 안의 이름(Name)은 애트리뷰트(attribute)의 이름이다.

주어진 엘레멘트(element) 타입에 하나 이상의 AttlistDecl이 있으면, 제공된 모든 내용들은 통합된다(merge). 주어진 엘레멘트 타입의 같은 애트리뷰트가 하나 이상 정의되었으면, 먼저 선언이 작용되고 나중 선언들은 무시된다. 공통사용성을 위하여, DTD 작성자는 주어진 엘레멘트 타입에 많아도 한개의 애트리뷰트 목록 선언을, 주어진 애트리뷰트 이름에 많아도 한개의 애트리뷰트 정의를, 그리고 각 애트리뷰트 목록 선언 안에 적어도 한개의 애트리뷰트 정의를 선택 할 수 있다. 공통사용성(interoperability)을 위하여, 주어진 엘레멘트 타입에 하나 이상의 애트리뷰트 목록 선언되었거나, 주어진 애트리뷰트에 하나 이상의 애트리뷰트 정의가 되었으면, XML 처리자(processor)는 사용자 선택으로 경고를 발생시킬 수 있고 이것은 오류가 아니다.

3.3.1 애트리뷰트 타입

XML 애트리뷰트 타입들에는 세가지가 있는다: 스트링 타입, 토큰화된(tokenized) 타입들의 세트, 그리고 번호붙인(enumerated) 타입들. 스트링 타입은 그 값으로 어떠한 리터랄(literal) 스트링도 가질수 있고; 토큰화된(tokenized) 타입들은 위에서 다룬 바와 같이 여러 내용과 문법적 제한요소를 가질 수 있다:

유효성 제한요소: ID
타입 ID의 값은 이름(Name)과 일치하여야 한다. 이름은 XML 문서에서 이 타입의 값으로 한번 이상 나타나지 말하야 한다; 말하자면, ID 값들은 그것을 갖는 엘레멘트(element)들을 인식(지정) 할 수 있도록 유일하여야 한다.

유효성 제한요소: 엘레멘트 타입당 한 ID(One ID per Element Type)
지정된 한 ID 애트리뷰트가 엘레멘트 타입에서 한번 이상 나올 수 없다.

유효성 제한요소: ID 애트리뷰트 디폴트(ID Attribute Default)
ID 애트리뷰트(attribute)는 #IMPLIED 혹은 #REQUIRED의 디폴트 선언이 있어야 한다.

유효성 제한요소: ID 참조(IDREF)
타입 IDREF의 값들이 생성된 이름(Name)과 일치하여야 하며, 타입 IDREFS의 값들이 이름과 일치하여야 한다; 각 Name은 그 XML 문서 안의 일부 엘레멘트의 ID 애트리뷰트에 일치하여야 하는데 이는 다시 말해 IDREF 값들이 일부 ID 애트리뷰트 값과 일치하여야 한다.

유효성 제한요소: 엔티티 이름(Entity Name)
타입 ENTITY의 값들은 생성된 Name과 일치하여야 하며, 타입 ENTITIES의 값들은 Names과 일치하여야 하며; 각 Name은 DTD 안의 선언된 한 해석(parse) 안된 엔티티의 이름과 일치하여야 한다.

유효성 제한요소: 이름 토큰(Name Token)
타입 NMTOKEN의 값들은 일치 the 생성된 Nmtoken과 일치하여야 하고; 타입 NMTOKENS의 값들은 Nmtokens과 일치하여야 한다.

번호붙여진 애트리뷰트들은 선언이 제공하는 값들의 목록 중 하나를 가질 수 있어야 한다. 두가지 종류의 번호붙여진(Enumerated) 타입들이 있다:

NOTATION 애트리뷰트는 시스템 과/또는 공통(public) 인식자(identifier)들과 관련하여 DTD에 선언되고, 그 애트리뷰트가 첨부된 엘레멘트를 해석(interpreting)하는데 사용되는, 주석(notation)을 인식(identify)한다.

유효성 제한요소: 주석 애트리뷰트(Notation Attributes)
이 타입의 값들은 선언에 포함된 하나의 주석(notation) 이름과 일치하여야 한다; 선언의 모든 주석(notation) 이름은 선언된 것이어야 한다.

유효성 제한요소: Enumeration
이 타입의 값들은 선언에 포함된 하나의 Nmtoken 토큰(token)과 일치하여야 한다.

공통사용성(interoperability)을 위하여, 단일 엘레멘트의 번호붙인(enumerated) 애트리뷰트 타입에서 같은 Nmtoken은 나타나지 말아야 한다.

3.3.2 애트리뷰트 디폴트

애트리뷰트 선언은 애트리뷰트(attribute)가 있을 필요성이 있는가, 아니면, 문서에 선언된 애트리뷰트가 없으면 어떻게 XML 처리자(processor)가 반응하여야 하는가의 정보를 제공한다.

애트리뷰트(attribute) 선언에서, #REQUIRED는 애트리뷰트가 항상 제공되어야 하고, #IMPLIED는 디폴트 값이 없는 것을 의미한다. 만일 선언이 #REQUIRED나 #IMPLIED가 아니면, AttValue 값은 선언된 디폴트 값을 갖는다; #FIXED 키워드(keyword)는 애트리뷰트가 항상 디폴트 값을 가져야 한다는 것을 기술한다. 디폴트 값이 선언되었으면, XML 처리자(processor)가 생략된 애트리뷰트를 만났을 때, 디폴트 값이 선언된 애트리뷰트가 있는 것 처럼 행동한다.

유효성 제한요소: 필요한 애트리뷰트(Required Attribute)
디폴트 선언이 키워드 #REQUIRED이면, 애트리뷰트는 애트리뷰트 목록 선언 안 그 타입의 모든 엘레멘트에 지정되어야 한다.

유효성 제한요소: 유효한 애트리뷰트 디폴트(Attribute Default Legal)
선언된 디폴트 값은 선언된 애트리뷰트 타입의 제한요소을 만족시켜야 한다.

유효성 제한요소: 고정된 애트리뷰트 디폴트(Fixed Attribute Default)
만일 애트리뷰트가 #FIXED 키워드로 선언된 디폴트 값을 가지고 있으면, 애트리뷰트의 인스탄스(instance)는 그 디폴트 값과 일치하여야 한다.

애트리뷰트 목록 선언 예제:

3.3.3 애트리뷰트 값의 정상화(normalization)

애트리뷰트(attribute) 값이 적용(application)에 전달되거나 유효성이 점검되기 전에, XML 처리자(processor)는 아래와 같이 정상화 하여야 한다:

• 참조된 글자를 애트리뷰트 값에 첨부 함으로서 글자 참조가 처리된다.
• 반복적으로 엔티티(entity)의 교체 텍스트를 가공 함으로서 엔티티 참조가 처리된다.
• 외부적으로 해석(parse)된 엔티티의 부분, 또는 내부적으로 해석된 엔티티의 리터랄(literal) 엔티티 값인 "#xD#xA" 연속에 단일 '#x20' 만이 추가된다는 것 제외하고는, 공백 글자(#x20, #xD, #xA, #x9)는 정상화 된(normalized) 값에 '#x20'를 추가 함으로서 처리된다.
• 다른 글자들은 그것에 정상화된 값이 첨부 됨으로서 처리된다

만일 그 선언된 값이 CDATA 가 아니면, XML 처리자(processor)는, 맨 앞과 뒤의 공백(#x20) 글자들을 제거하고, 연속 공백(#x20) 글자들을 단일 공백(#x20) 글자로 교체하는, 추가적인 애트리뷰트 값의 정상화 과정을 거쳐야 한다.

선언이 없는 모든 애트리뷰트들은 유효성을 검정 않는 해석자(parser)에 의하여 CDATA가 선언된 것 처럼 취급 되어야 한다.

3.4 조건부 항목

조건부 항목(conditional section)은, 그들을 다루는 키워드(keyword)에 기초한 DTD의 논리적 구조에 포함되거나 제외된, 문서 타입 선언 외부적 하부세트의 부분들이다.

내부적과 외부적 DTD 하부세트(subset)들과 마찬가지로, 조건부 항목(conditional section)은 한개 혹은 그 이상의 완전한 선언, 코멘트, 처리지시(processing instruction) 또는 네스트(nest) 된 조건부 항목들, 공백과 혼합들을 포함 할 수 있다.

만일 조건부 항목의 키워드(keyword)가 INCLUDE이면, 조건부 항목의 내용(content)은 DTD의 부분이다. 조건부 항목의 키워드가 IGNORE이면, 조건부 항목의 내용은 논리적으로 DTD의 부분이 아니다. 올바른 해석(parsing)을 위하여, 조건부 항목들의 네스트를 알아내고, (무시된) 조건부 항목의 감지된 가장 밖의 끝을 확인하기 위하여, 무시된 조건부 항목의 내용들 까지도 읽어야 한다는 점에 주의하라. 만일 조건부 항목이 키워드 INCLUDE가, 키워드 IGNORE를 갖는 더 큰 조건부 항목 안에 나타나면, 외부와 내부 조건부 항목들이 둘 다 무시된다.

만일 조건부 항목의 키워드가 파라메터(parameter) 엔티티를 참조이면, 처리자(processor)가 그 조건부 항목(conditional section)을 포함 할 것인가 무시 할 것인가를 결정하기 전에, 파라메터 엔티티는 그 내용(content)으로 대체되어야 한다.

예제:

4. 물리적 구조

XML 문서는 하나 혹은 그 이상의 저장(storage) 단위들로 구성 될 수 있으며, 이것들을 엔티티(entity)라 부른다; 이들은 모두 내용(content)을 가지며, 모두(문서 엔티티(아래 참조)와 외부적 DTD 하부세트를 제외) 이름(name)으로 인식된다. 각 XML 문서는 문서 엔티티라 불리우는 하나의 엔티티를 가지며, 이는 XML 처리자(processor)의 시작점으로 작용하고, 전체 문서를 포함 할 수 있다.

엔티티는 해석(parse)된 것이거나 해석 안된 것이 될 수 있다. 해석(parse)된 엔티티의 내용(content)들은 그 교체 텍스트로 참조된다; 이 텍스트는 그 문서의 일부로 간주된다.

해석(parse) 안된 엔티티는, 그 내용이 텍스트가 될 수 있거나 될 수 없는 자원(resource)이며, 만일 텍스트이면, XML이 될 수 없다. 각 해석 안된 엔티티는 하나의 관련된 주석(notation)을 가지며, 이름으로 인식된다. XML 처리자(processor)가 적용(application)이 사용 할 수 있는 엔티티와 주석(notation)의 인식자(identifier)들을 만드는 필요성 말고는, XML은 해석 안된 엔티티의 내용에 제한요소를 주지 않는다.

해석된 엔티티들은 엔티티 참조를 사용하여 이름으로 불러지고(invoked); 해석 안된 엔티티는 이름, 주어진 값 ENTITY 혹은 ENTITIES 애트리뷰트들로 불러진다.

일반(general) 엔티티는 문서 내용(content) 안에서 사용되는 엔티티이다. 이규격에서, 일반 엔티티는 때때로, 모호성이 없을 때, 단순히 엔티티(entity)로 참조된다. 파라메터 엔티티들은 DTD 안에서 사용되는 해석(parse)된 엔티티이다. 이들 엔티티의 두 타입들은 다른 참조 양식들을 사용하며, 다른 문맥들로 인식된다. 더더욱, 이들은 다른 이름자리(namespace)들을 차지한다; 같은 이름의 파라메터 엔티티와 일반 엔티티는 서로 다른 엔티티들이다.

4.1 글자와 엔티티 참조

글자 참조는 ISO/IEC 10646 글자 세트의 특정 글자를 참조한다. 예를 들면 입력장치들에서 직접적으로 사용 할 수 없는 글자를 참조하는 것이다.

잘 형성됨을 위한 필수사항: 올바른(legal) 글자
글자 참조를 사용하여 참조된 글자들은 Char 생성물과 일치하여야 한다.

만일 글자 참조가 "&#x"으로 시작하고, 숫자(digit)나 글자(letter)들, 그리고 ;로 종료되면, ISO/IEC 10646의 글자들 코드 포인트의 16진수 표현이 된다. 만일 "&#" 만으로 시작되고, 숫자, 그리고 ;로 종료되면, 글자들 코드 포인트의 10진수 표현이 된다.

엔티티(entity) 참조는 이름 붙여진(named) 엔티티의 내용을 참조한다. 해석(parse)된 일반 엔티티의 참조는 앰퍼샌드(&)와 쎄미콜론 (;)을 구분자(delimiter)로 사용한다. 파라메터(parameter) 엔티티 참조는 백분율 기호 (%)와 쎄미콜론 (;)을 구분자(delimiter)로 사용한다.

잘 형성됨을 위한 필수사항: 선언된 엔티티(Entity Declared)
DTD가 없는 문서에서, 파라메터(parameter) 엔티티 참조가 없는 내부적 DTD 하부세트(subset) 하나 만을 갖는 문서, 또는 "standalone='yes'" 이고, Name이 엔티티 참조에 주어진 문서는, 엔티티(entity) 선언의 것과 일치하여야 하나, 잘 형성된 문서들에서 다음 엔티티들은 선언 할 필요가 없는 예외 사항이다: amp, lt, gt, apos, quot. 파라메터 엔티티 선언은 그의 어떤 참조보다 먼저되어야 한다. 유사하게, 일반 엔티티(entity) 선언은, 애트리뷰트 목록 선언의 디폴트 값을 참조보다 먼저되어야 한다. 만일 엔티티들이 외부적 하부세트(subset) 또는 외부적 파라메터 엔티티에 선언되었으면, 유효성 검정을 하지 않는 처리자(processor)는 그의 선언들을 읽고 처리하지 않는다는 점에 유의하라; 이런 문서들에서, 엔티티가 선언되어야 한다는 규칙은 standalone='yes'인 경우에 만 해당하는 잘 형성되기 위한 필수사항이다

유효성 제한요소: 선언된 엔티티(Entity Declared)
외부적 하부세트 또는 외부적 파라메터 엔티티에 "standalone='no'"를 갖는 문서에서, 엔티티 참조에 주어진 Name은 엔티티 선언의 것과 일치하여야 한다. 공통사용성(interoperability)을 위하여, 유효한(valid) 문서들은, 4.6 "사전에 정의된 엔티티"에 지정된 양식으로, 엔티티 amp, lt, gt, apos, quot가 선언하여야 한다. 파라메터(parameter) 엔티티의 선언은 그의 어떤 참조보다 먼저되어야 한다. 유사하게, 일반 엔티티 선언은, 애트리뷰트 목록 선언의 디폴트 값을 참조보다 먼저되어야 한다.

잘 형성됨을 위한 필수사항: 해석된 엔티티(Parsed Entity)
해석된 엔티티 참조는 해석 안된 엔티티(entity) 이름을 포함해서는 않된다. 해석(parse) 안된 엔티티는, 선언된 애트리뷰트 값이 타입 ENTITY 또는 ENTITIES 일 경우에 만, 참조 될 수 있다

잘 형성됨을 위한 필수사항: 반복 없슴(No Recursion)
해석(parse)된 엔티티는 직접적이건 간접적이건 반복된 자체의 참조를 포함하지 말아야 한다.

잘 형성됨을 위한 필수사항: DTD 안에(In DTD)
파라메터(parameter) 엔티티(entity) 참조는 DTD 안에 만 나타날 수 있다.

글자와 엔티티 참조 예제:

파라메터(parameter) 엔티티(entity) 참조 예제:

4.2 엔티티 선언

엔티티(entity)들은 다음과 같이 선언된다:

Name은 엔티티 참조에 있는 엔티티, 또는, 해석(parse) 안된 엔티티(entity)의 경우, ENTITY 혹은 ENTITIES 애트리뷰트 값을 인식(identify)한다. 만일 같은 엔티티가 한번 이상 선언되었으면, 먼저 만난 선언이 적용된다; 사용자 선택으로, XML 처리자(processor)는 만일 엔티티(entity) 여러번 선언되었으면 경고를 발생시킬 수 있다.

4.2.1 내부적 엔티티

만일 엔티티 정의가 EntityValue이면, 그 정의된 엔티티(entity)를 내부적 엔티티라 부른다. 별도의 물리적 저장 오브젝트(object)가 있지 않고, 엔티티 내용(content)은 선언에 주어진다. 일부 리터랄(literal) 엔티티 값의 엔티티와 글자 참조 처리는 올바른 교체 텍스트를 만드는데 필요 할 수 있다는 점에 유의하라: 4.5 "내부적 엔티티 교체 텍스트의 구성"을 참고하라.

하나의 내부적 엔티티는 해석(parse)된 엔티티(entity)이다.

내부적 엔티티 선언 예제:

4.2.2 외부적 엔티티

만일 엔티티(entity)가 내부적이 아니면, 아래와 같이 선언된 외부적 엔티티이다:

만일 NDataDecl가 있으면, 이는 일반 해석 안된 엔티티이며; 아니면 해석(parse)된 엔티티이다.

유효성 제한요소: 선언된 주석(Notation Declared)
Name은 주석(notation)의 선언된 이름과 일치하여야 한다.

SystemLiteral은 그 엔티티(entity)의 시스템 인식자(identifier)라 불리운다. 이는 하나의 URI이며, 엔티티(entity)를 불러오는데 사용 될 수 있다. URI 함께 자주 사용되는 #와 부위(fragment) 인식자(identifier)는 공식적으로는 URI 자체의 일부가 아니라는 점에 유의하라; XML 처리자(processor)는, 시스템 인식자의 일부로 부위(fragment) 인식자가 있으면, 오류의 신호를 발생시킬 수 있다. 이규격 범위 밖의(예를 들어 특정 DTD에 의해 정의된 특별 XML 엘레멘트 타입, 혹은, 특정 적용 규격에 의하여 정의된 처리지시) 정보가 따로 제공되지 않는 한, 상대적 URI들은 엔티티 선언에 나타난 자원 위치에 상대적이다. 그래서 한 URI는 문서 엔티티에, 외부적 DTD 하부세트(subset)에 포함된 엔티티에, 또는 다른 외부적 파라메터 엔티티에 상대적이 될 수 있다.

XML 처리자(processor)는 URI에 있는 비ASCII 글자를, 하나 혹은 그이상의 바이트(byte)로 UTF-8 글자로 표현함으로서, 그리고는 이들 URI 에스케입하는 기구(mechanism: 말하자면, 각 바이트를 16진수 주석인 %HH로 변환하여)로 바이트 에스케입(escape)하여, 취급하여야 한다.

시스템 인식자(identifier)에 추가적으로, 외부적 인식자에 공통(public) 인식자를 포함 할 수 있다. 엔티티의 내용 읽음을 시도하는 XML 처리자(processor)는 대체 URI의 생성을 시도하기 위하여 공통(public) 인식자를 사용 할 수 있다. 만일 그 처리자가 그렇게 할 수 없으면, 시스템 리터랄(system literal)에서 지정한 URI를 사용하여야 한다. 일치를 시도하기 전에, 모든 공통 인식자의 공백 스트링은, 단일 공백 글자(#x20)로, 그리고 맨 앞과 맨 뒤의 공백은 제거하여, 정상화(normalized)되어야 한다.

외부적 엔티티 선언 예제:

4.3 해석(parse)된 엔티티(entity)

4.3.1 텍스트 선언

외부적 해석(parse)된 엔티티(entity)는 각각 텍스트 선언으로 시작 될 수 있다.

텍스트 선언은 해석된 엔티티를 참조하는 것이 아니라 리터랄(literal)로 제공되어야 한다. 텍스트 선언은 외부적 해석(parse)된 엔티티의 시작 부분 이외의 위치에는 나올 수 없다.

4.3.2 잘 형성된 해석(parse)된 엔티티(entity)

문서 엔티티는, 이것이 라벨된(labeled) document의 생성물과 일치하면, 잘 형성된 것이다. 외부적 일반적(general) 해석(parse)된 엔티티는, 이것이 라벨된 extParsedEnt의 생성물과 일치하면, 잘 형성된 것이 된다. 외부적 파라메터(parameter) 엔티티는, 이것이 라벨된 extPE의 생성물과 일치하면, 잘 형성된 것이 된다.

내부적 일반적(general) 해석(parse)된 엔티티(entity)는, 그의 교체 텍스트가 라벨된 내용(content)의 생성물과 일치하면, 잘 형성된 것이 된다. 모든 내부적 파라메터(parameter) 엔티티는 정의에 의해 잘 형성된 것이 된다.

엔티티가 잘 형성되었다는 것은 XML 문서의 논리적, 물리적 구조가 적정하게 네스트(nest)되었다는 것이다; 시작태그, 종료태그, 빈 엘레멘트 태그, 엘레멘트(element), 코멘트(comment), 처리지시(processing instruction), 글자 참조, 또는 엔티티 참조가 한 엔티티에서 시작되고 다른 것에서 종료 될 수 없다는 것이다.

4.3.3 엔티티 안의 글자 엔코딩

XML 문서의 각 외부적 해석(parse)된 엔티티는 그 글자들을 위하여 다른 엔코딩(encoding) 사용 할 수 있다. 모든 XML 처리자(processor)들은 UTF-8 나 UTF-16의 엔티티(entity)를 읽을 수 있어야 한다.

UTF-16으로 엔코드(encode)된 엔티티는, ISO/IEC 10646 부록 E 와 Unicode 부록 B 너비없고-줄바꿈없는-공백(ZERO WIDTH NO-BREAK SPACE 글자, #xFEFF)에 설명된 바이트 순서 표시(Byte Order Mark)로 시작하여야 한다. 이는 XML 문서의 코드(markup)나 글자 데이터의 부분이 아니라 하나의 엔코딩 서명(signature: 표시)이다, XML 처리자(processor)는 이 글자을 UTF-8 와 UTF-16로 엔코드된 문서들을 서로 다르게 사용 할 수 있어야 한다.

XML 처리자는 UTF-8과 UTF-16로 엔코딩된 엔티티를 읽을 수 있는 것이 요구되지만, 전 세계를 통해 다른 엔코딩들이 알려져 있고, XML 처리자(processor)들이 그 엔티티들을 읽는 것은 바람직 할 수 있다. UTF-8 이나 UTF-16 이외의 엔코딩으로 저장된 해석(parse)된 엔티티(entity)는 엔코딩 선언을 포함하는 텍스트 선언으로 시작되어야 한다:

문서 엔티티에서, 엔코딩(encoding) 선언은 XML 선언의 한 부분이다. EncName는 사용된 엔코딩 이름이다.

엔코딩 선언에서, 값들 "UTF-8", "UTF-16", "ISO-10646-UCS-2", "ISO-10646-UCS-4"는 Unicode / ISO/IEC 10646의 여러 엔코딩들과 변형들에 사용되어야 하고, 값들 "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-9"는 ISO 8859의 부분에 사용되어야 하며, 값들 "ISO-2022-JP", "Shift_JIS", "EUC-JP"는 JIS X-0208-1997의 양식으로 엔코드된 것들에 사용되어야 한다. XML 처리자(processor)들은 다른 엔코딩(encoding)들을 인식 할 수 있다; [IANA](Internet Assigned Numbers Authority: 인터넷 할당 번호 당국)의 등록된(charset로) 글자 엔코딩들과 목록으로 된 다른 엔코딩들을, 그들의 등록된 이름을 사용하는데 참조 할 것을 권한다. 이들 등록된 이름은 대소문자 구별하지 않고 정의되고, 그래서 처리자(processor)들은 그에 일치하기 원하면 대소문자 구별하지 않는 방식으로 해야 한다 점에 유의하라.

외부적 전달 프로토골(protocol: 예 HTTP 또는 MIME)에 의하여 정보가 제공되지 않은 상태에서, (1) 선언 안의 이름 이외의 엔코딩으로 XML 처리자에게 제시되는 엔코딩 선언을 포함하는 엔티티, (2) 외부적 엔티티의 시작부분이 아니 곳에 엔코딩 선언이 나타나는 것, 또는 (3) UTF-8 이외의 엔코딩을 사용하기 위하여 Byte Order Mark 도 아니고 엔코딩(encoding) 선언도 아닌 것으로 시작되는 엔티티는 오류이다.
ASCII는 UTF-8의 하부세트(subset)이므로 보통의 ASCII 엔티티는 엄격하게 엔코딩(encoding) 선언을 필요로 하지 않음을 명심하라.

XML 처리자가 처리 할 수 없는 엔코딩이 있는 엔티티를 만나면 이것은 치명적 오류이다.

엔코딩 선언 예제:

4.4 XML 처리자의 엔티티와 참조의 처리

아래 테이블은 글자 참조, 엔티티 참조, 해석 안된 엔티티가 나타나면 조치와 각 경우 XML 처리자가 취해야 할 행위등의 문맥들을 요약한 것이다. 가장 왼쪽 컬럼의 라벨은 알려진 문맥을 기술하였다:

내용(content) 참조

엘레멘트의 시작태그 후 종료태그 전 어디에서나 참조; 비 터미날 content에 해당.

애트리뷰트 값의 참조

시작태그 안의 애트리뷰트(attribute) 값, 또는 애트리뷰트 선언의 디폴트 값을 참조; 비 터미날 AttValue에 해당.

애트리뷰트 값으로 나타남

참조가 아니라, Name으로 타입이 ENTITY로 선언된 애트리뷰트(attribute)의 값으로 또는 타입이 ENTITIES로 선언된 애트리뷰트(attribute)의 값으로 하나의 공간으로 분리된 토큰(token)들로 나타나는 것.

엔티티(entity) 값 참조

파라메터(parameter) 또는 엔티티(entity)의 선언에서 내부적 엔티티의 리터랄(literal) 엔티티 값으로 참조; 비 터미날(nonterminal) EntityValue에 해당.

DTD 참조

내부적 또는 DTD의 외부적 하부세트(subset)들에서 참조, 그러나 EntityValue 또는 AttValue의 외부.

4.4.1 인식 못함

DTD 외부에서, % 글자는 특별한 의미를 갖지 못한다; 그래서, DTD에서 참조하는 파라메터(parameter) 엔티티(entity)를 content 안에 코드(markup)로 인식하지 못한다. 이와 유사하게, 적정하게 선언된 애트리뷰트(attribute)의 값으로 나타나지 않는 한, 해석(parse) 안된 엔티티 이름들이 인식되지 못한다.

4.4.2 포함

엔티티(entity)가, 참조가 인식된 장소에서 그 문서의 일부분인 것 처럼 참조 그 자리에서, 그 교체 텍스트가 읽혀지고 처리되면, 포함된다. 교체 텍스트는 글자 데이터와 (파라메터 엔티티 제외) 코드(markup)를 포함 할 수 있다. 여기서 코드는, 사용된 엔티티(entity)들의 교체 텍스트가 코드 구분자들(엔티티 amp, lt, gt, apos, quot)로 에스케입(escape)하는 경우를 제외하고는 항상 데이터로 처리된다는 것 이외에는, 보통 방식으로 인식되어야 한다. (스트링 "AT&T;"는 "AT&T;"로 확장되고, 나머지 앰퍼샌드는 엔티티-참조 구분자로 인식하지 못한다.) 한 글자 참조는 지정된 글자가 그 참조 자체의 자리에서 처리되면 포함된 것이다.

4.4.3 포함된 If 유효성 검정

XML 처리자(processor)가 해석(parse)된 엔티티(entity) 참조를 인식하면, 그 문서의 유효성 검정(validate)을 위하여, 처리자는 그 교체 텍스트를 포함(include)하여야 한다. 만일 엔티티가 외부적이고, 처리자가 XML 문서 유효성 검정을 시도하지 않으면, 그 처리자(processor)는, 필요사항은 아니지만, 엔티티(entity)의 교체 텍스트를 포함 할 수 있다. 만일 유효성 검정하지 않는 해석자(parser)가 교체 텍스트를 포함하지 않으면, 적용(application)에게 인식된 엔티티를 알려 주어야 하지만, 읽지는 않는다.

이 규칙은, 자동 포함이 SGML에 의하여 제공되고, XML 엔티티 기구(mechanism)가 원천적으로 편집의 모듈성을 지원하기 위하여 설계되고, 다른 적용들(구체적인 예로 문서 브라우징)에 적당하지 않을 수 있다는, 인식을 기초로 한 것이다. 예를 들어, 외부적 해석(parse)된 엔티티 참조를 만나면, 브라우저들은, 엔티티의 존재를 보이고, 읽어, 요구에 의해서 만 디스플레이하는, 선택을 할 수 있다.

4.4.4 금지된

아래는 금지된 사항들이고 치명적(fatal) 오류들을 구성한다:

• 해석(parse) 안된 엔티티를 참조하는 것.
• EntityValue 나 AttValue 이외의 곳에서 DTD에서 글자 또는 일반(general) 엔티티(entity) 참조하는 것.
• 애트리뷰트 값에서 외부적 엔티티(entity)를 참조하는 것.

4.4.5 리터랄(literal)에 포함된

애트리뷰트 값에 엔티티 참조가 나타나거나, 리터랄(literal) 엔티티 값에 파라메터(parameter) 엔티티 참조가 나타나면, 교체 텍스트 안의 단일 또는 이중 따옴표 글자는 항상 정상 데이터 글자로 처리되고, 리터랄을 종료시키지 않는다는 것을 제외하고는, 그 교체 텍스트가 그 문서의 부분인 것 처럼 인식된 참조의 위치에서 처리된다:

잘 형성된 예제:

그렇지 않은 예제:

4.4.6 알림(notify)

해석(parse) 안된 엔티티(entity)의 이름이 선언된 타입 ENTITY 또는 ENTITIES의 애트리뷰트(attribute) 값에 토큰(token)으로 나타나면, 유효성 검정 처리자(processor)는 시스템(system) 적용(application)과 공통(public: 있으면) 인식자(identifier)들에게, 엔티티와 그 관련된 주석(notation)을 알려 주어야 한다.

4.4.7 통과(bypassed)

엔티티 선언에서 EntityValue에 일반 엔티티 참조가 나타나면, 그대로 놔두고 통과한다.

4.4.8 PE로 포함된

외부적 해석(parse)된 엔티티에서와 마찬가지로, 파라메터(parameter) 엔티티(entity)는 포함된 if 유효성 검정을 할 때 만 필요하다. DTD에서 파라메터 엔티티 참조가 인식되고, 포함되면, 그 교체 텍스트는 앞과 뒤에 각 한개의 공백(#x20) 글자를 첨부하여 확장된다; 그 의도는 파라메터(parameter) 엔티티(entity)의 교체 텍스트에 DTD 문법적 정수 수치 토큰을 방지하기 위한 것이다.

4.5 내부적 엔티티 교체(replacement) 텍스트의 형성

내부적 엔티티의 처리를 다루는데, 두가지 양식의 엔티티 값들을 구별하는 것이 유용하다. 리터랄(literal) 엔티티 값은 엔티티(entity) 선언에서 실제적으로 따옴표 안의 스트링으로 비 터미날 EntityValue에 해당한다. 교체 텍스트는, 글자 참조와 파라메터 엔티티 참조 교체(replacement) 이후에는, 엔티티의 내용이다.

내부적 엔티티 선언에서(EntityValue) 주어진 리터랄(literal) 엔티티 값은 글자, 파라메터(parameter) 엔티티와 일반 엔티티 참조들을 포함 할 수 있다. 이와같은 참조는 완전히 리터랄 엔티티(entity) 값 안에 포함되어야 한다. 위에 설명된 바와 같은 포함된 실제적인 교체 텍스트는 참조된 파라메터(parameter) 엔티티의 교체 텍스트를 포함하여야 하며, 참조된 글자 리터랄 엔티티 값 안에 참조하는 글자 참조를 포함하여야 한다; 그러나, 일반 엔티티 참조는 확장 안된 상태로 그대로 있어야 한다. 예를 들어, 아래 선언을 보자:

엔티티 교체 텍스트 "book"은:

일반 엔티티(entity) 참조 "&rights;"는, 문서의 내용(content) 또는 애트리뷰트 값에 나타나는 "&book;"의 참조로, 확장 될 것이다.

이들 단순한 규칙들은 복합 작용들을 할 수 있다; 어려운 예제의 자세한 사항은 D. "엔티티와 글자 참조의 확장(expansion)"을 보라.

4.6 사전에 정의된(predefined) 엔티티

엔티티와 글자 참조는 둘 다 왼쪽 꺽쇄(<), 앰퍼샌드(&)와 다른 구분자(delimiter)들을 에스케입(escape)하여 사용 될 수 있다. 일련의 일반(general) 엔티티(amp, lt, gt, apos, quot)는 이와같은 목적으로 지정되었다. 숫치(numeric) 글자 참조도 사용 될 수 있다; 이들은 인식되는 즉시 확장되고, 글자 데이터로 취급되어야 한다. 그리서 숫치 글자 참조 "<"와 "&"는 글자 데이터에 나타나면 '<'와 '&'를 에스테입(escape)하여 사용 될 수 있다.

모든 XML 처리자(processor)들은 이들 엔티티(entity)들이 선언된 것인가 아닌가를 인식하여야 한다. 공통사용성(interoperability)을 위하여, 유효한(valid) XML 문서들은 이들 엔티티(entity)들이, 다른 것들과 마찬가지로 사용 전에, 선언되어야 한다 문제의 엔티티가 선언되면, 아래 설명과 같이, 그것들은, 그의 교체 텍스트가 에스게입 된 단일 글자이거나 그 글자의 글자 참조인, 내부적 엔티티로 선언되어야 한다.

"lt"와 "amp"의 선언에서 "<"와 "&" 글자들은, 그 엔티티 대체(replacement)가 잘 형성된 것이 되게 하는데 필요 한, 이중(double)으로 에스케입(escaped) 되었슴에 주의하라.

4.7 주석(notation) 선언

주석들은, 주석(notation) 애트리뷰트, 또는 처리지시(processing instruction)가 보내지는 적용(application)을 갖는, 엘레멘트들의 해석(parse) 안된 엔티티 양식 이름으로 인식(identify)한다.

주석 선언들은, 엔티티(entity)와 애트리뷰트 목록 선언들과 애트리뷰트 규격들의 사용을 위하여, 주석에 이름을 제공한다. 그리고, XML 처리자(processor)에게 허용하는 주석 또는 주어진 주석에서 데이터 처리를 가능하게 하는 도움 적용을 위치시키는 크라이언트(client: 고객) 적용(application)을 위하여, 외부적 인식자(identifier)를 제공한다.

XML 처리자(processor)는 적용(application)에 이름과, 애트리뷰트 값, 애트리뷰트(attribute) 정의, 또는 엔티티(entity) 선언에서, 선언되고 참조되는 어떤 주석(notation)의 외부적 인식자(identifier)를 제공하여야 한다. 이들은 추가적으로 외부적 인식자를 시스템 인식자로, 화일 이름으로, 또는 설명된 주석 안의 데이터 처리자를 호출하는 적용을 허용하는데 필요한 다른 정보들을 해결(산출) 할 수 있다. (그러나, XML 문서에서 선언하고, 주석에서 조회하는 XML 처리자(processor) 또는 적용이 작동하고 있는 시스템에 주석 특정 적용(notation-specific application)들이 없다며, 이것은 오류는 아니다.)

4.8 문서(document) 엔티티

문서 엔티티는 엔티티 계통도(tree)에서 최상위(root)로 작용하고, XML 처리자(processor)의 시작점이다. 이규격은 XML 처리자에 의하여 어떻게 문서 엔티티 위치되는가를 정의하고 있지 않다; 다른 엔티티들과는 달리, 문서(document) 엔티티는 이름을 갖고 있지 않고, 지정(인식)이 전혀 없어도 처리자 입력(input) 흐름이 잘 나타날 수 있다.

5. 규격부합성

5.1 유효성 검정하는 처리자와 유효성 검정 않는 처리자

규격에 부합하는 XML 처리자(processor)들은 유효성 검정하는 처리자와 유효성 검정 않는 처리자 두가지 종류 중에 하나이다.

유효성 검정하는 처리자와 유효성 검정 않는 처리자들은 둘 다, 문서 엔티티의 내용과 그가 읽는 다른 해석(parse)된 엔티티들에서, 이규격의 잘 형성됨을 위한 필수사항 위반을 알려주어야 한다.

유효성 검정 처리자들은 DTD에 선언들로 나타낸 제한요소의 위반과, 이규격의 주어진 유효성 검정(validity) 제한요소를 만족시키지 못하는 겻을 알려 주어야 한다. 이를 달성하기 위하여, 유효성 검정 XML 처리자(processor)들은, 전체 DTD와 문서의 모든 참조된 외부적 해석(parse)된 엔티티를 읽고 처리하여야 한다.

유효성 검정 않는 처리자들은 전체 내부적 DTD 하부세트(subset)를 포함하여 문서 엔티티 만 그의 잘 형성됨을 검사하는 것이 필요하다. 그들은 문서의 유효성(validity) 검사가 필요하지 않지만, 내부적 DTD 하부세트와 파라메터(parameter) 엔티티에서 읽은 모든 선언을, 읽지 않은 처음 파라메터 엔티티(entity)를 참조하는데 까지, 처리(process)하는 것은 필요하다; 다시말해, 이것들은, 애트리뷰트 값들을 정상화(normalize)하고, 내부적 엔티티의 교체 텍스트를 포함(include)하고, 디폴트 애트리뷰트 값들을 제공하기 위하여, 선언들에 있는 정보를 사용하여야 한다. 이것들은 엔티티 선언들이나 읽지 않은 파라메터(parameter) 엔티티(entity) 참조 다음에 만나는 애트리뷰트 목록 선언들을 처리(process)하지 말아야 한다. 이는 그 엔티티에는 덮어씌우는 선언들을 포함 할 수 있기 때문이다.

5.2 XML 처리자(processor)의 사용

유효성 검정 XML 처리자의 활동은 상당히 예측 할 수 있다; 이는 문서의 각 부분을 읽고 모든 잘 형성됨과 유효성(validity) 위반을 알려주어야 한다. 유효성 검정 않는 처리자에서는 이보다 적은 필요사항이 있다; 문서 엔티티(entity) 이외의 다른 문서 부분은 읽을 필요가 없다. 이는 XML 처리자(processor)의 사용자들에게 중요한 두가지 효과(영향)이 있다:

• 어떤 잘 형성됨 오류들, 특히 외부적 엔티티(entity)의 읽음을 필요로하는 것들은 유효성 검정 않는 처리자에 의하여 감지되지 않을 수 있다. 예제들은 선언된 엔티티, 해석(parse)된 엔티티, 반복 없슴로 제목 붙은 제한요소들을 포함한다. 또한 4.4 "XML 처리자의 엔티티와 참조의 처리"의 금지된으로 설명된 일부 경우도 있다.
• 처리자(processor)로 부터 적용(application)에 전달되는 정보는 처리자가 파라메터와 외부적 엔티티를 읽는가에 따라 달라 질 수 있다. 예를 들어, 유효성 검정 않는 처리자는 애트리뷰트 값의 정상화(normalize), 내부적 엔티티의 교체 텍스트(replacement)의 포함(include) 또는 디폴트 애트리뷰트 값의 제공을 하지 않을 수 있다. 여기서는 외부적 또는 파라메터(parameter) 엔티티(entity)의 읽은 선언들 그다지 의존하지 않는다.

서로 다른 XML 처리자들 사이의 통용성에서 최대의 신뢰성을 위하여, 유효성 검정 않는 처리자들을 사용하는 적용들은 그와 같은 처리자(processor)들에 필요하지 않은 활동(behavior)에 의존하지 말아야 한다. 디폴트(default) 애트리뷰트(attribute)들 또는 외부적 엔티티에 선언된 내부적 엔티티(entity)에 사용하는 것 같은 도구(facilities)들을 필요로 하는 적용들은 유효성 검정 XML 처리자들을 사용하지 말아야 한다.

6. 주석(notation)

이규격에서 간단한 양식(EBNF: Extended Backus-Naur Form)의 주석(notation)을 사용하여 XML의 공식적인 문법이 주어진다. 문법의 각 규칙은 아래와 같은 양식의 부호로 정의되었다.

부호(Symbol)들은, 그들이 보통의 표현(공식)으로 정의 되었으면, 첫글자를 대문자로 하였고, 그렇지 않으면 소문자로 시작하였다. 리터랄(literal) 스트링들은 따옴표 안에 넣었다.

공식(코드) 속에 오른쪽 부분에 아래 공식(표현)들로, 짝 맞추어 한개 또는 여러개의 글자들의 스트링을 사용하였다:

#xN

여기서 N은 16진수 정수, 이 공식은 ISO/IEC 10646 canonical (UCS-4) 코드 값 글자와 맞고, 부호 없는 이진수로 해석 할 때는 그 값이 제시되었다. #xN 양식에서 맨 앞의 "0"들은 별 의미가 없다; 맨 앞의 "0"들을 갖는 수치에 해당하는 코드 값은 사용하고 있는 글자 엔코딩(encoding)에 의하여 결정되고, XML에서는 별 의미가 없다.

[a-zA-Z], [#xN-#xN]

값(들)이 지정하는 범위의 아무 글자에나 일치한다(포함).

[^a-z], [^#xN-#xN]

값이 지정하는 범위 밖의 아무 글자에나 일치한다.

[^abc], [^#xN#xN#xN]

주어진 값에 없는 글자들 중 아무 글자에나 일치한다.

"string"

이중 따옴표들 안에 주어진 리터랄(literal) 스트링에 일치하는.

'string'

단일 따옴표들 안에 주어진 리터랄(literal) 스트링에 일치하는.

(expression)

공식(expression: 표현)은 하나의 단위 취급되고, 이 목록에서 설명하는 바와 같이 결합 될 수 있다.

A?

선택적 A; A 또는 없는것과 일치한다.

A B

A 다음에 바로 B가 오는 것과 일치한다.

A | B

A 또는 B이나 둘 다는 아니다와 일치하다.

A - B

A는 같고 B는 갖지 않은 아무 스트링에서나 일치한다.

A+

A가 한번 혹은 그이상 나타나면 일치한다.

A*

A가 한번도 없던가 그이상 있으면 일치한다.

/* ... */

코멘트(comment).

[ wfc: ... ]

잘 형성됨을 위한 필수사항(well-formed constraint); 이는 이름으로, 관련된 생성 문서들의 잘 형성됨의 제한요소를 가리킨다.

[ vc: ... ]

유효성 제한요소(valid constraint); 이는 이름으로, 관련된 생성 문서들의 유효성(valid)의 제한요소를 가리킨다.

부록

A. 참조

A.1 지명적 참조

IANA

(인터넷 할당 번호 당국: Internet Assigned Numbers Authority)
글자 세트의 공식 이름(Official Names for Character Sets),
저자: Keld Simonsen 등.
영문 ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 참조.

IETF RFC 1766

IETF (인터넷 엔지니어링 태스크 포스: Internet Engineering Task Force).
RFC 1766: 언어의 인식을 위한 태그들(Tags for the Identification of Languages),
저자: H. Alvestrand. 1995.

ISO 639

(표준화를 위한 국제 기구: International Organization for Standardization).
ISO 639:1988 (E). 언어 이름 표현을 위한 코드(Codes for the representation of names of countries and their subdivisions).
[Geneva]: International Organization for Standardization, 1988.

ISO 3166

(표준화를 위한 국제 기구: International Organization for Standardization).
ISO 3166-1:1997 (E).
언어 이름 표현을 위한 코드(Codes for the representation of names of countries and their ) -- Part 1: 국가코드(Country codes)
[Geneva]: International Organization for Standardization, 1997.

ISO/IEC 10646

(표준화를 위한 국제 기구: International Organization for Standardization).
ISO/IEC 10646-1993 (E).
정보 기술 -- 국제 복수-8진수 코드 글자 세트(UCS)
Information technology -- Universal Multiple-Octet Coded Character Set
-- Part 1: Architecture and Basic Multilingual Plane.
[Geneva]: International Organization for Standardization, 1993(AM 1-AM 7개정 추가).

Unicode

The Unicode Consortium.
유니코드 표준, 버전 2.0(The Unicode Standard, Version 2.0).
Reading, Mass.: Addison-Wesley Developers Press, 1996.

A.2 다른 참조

Aho/Ullman

Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman.
Compilers: Principles, Techniques, and Tools.
Reading: Addison-Wesley, 1986, rpt. corr. 1988.

Berners-Lee 등.

Berners-Lee, T., R. Fielding, and L. Masinter.
통일 자원 인식자들(URI: Uniform Resource Identifiers):
Generic Syntax and Semantics. 1997.
(Work in progress; see updates to RFC1738.)

Br?gemann-Klein

Br?gemann-Klein, Anne.
Regular Expressions into Finite Automata.
Extended abstract in I. Simon, Hrsg., LATIN 1992, S. 97-98. Springer-Verlag, Berlin 1992.
Full Version in Theoretical Computer Science 120: 197-213, 1993.

Br?gemann-Klein and Wood

Br?gemann-Klein, Anne, and Derick Wood.
Deterministic Regular Languages.
Universit? Freiburg, Institut f? Informatik, Bericht 38, Oktober 1991.

Clark

James Clark. Comparison of SGML and XML.
영문 http://www.w3.org/TR/NOTE-sgml-xml-971215 참조.

IETF RFC1738

IETF (Internet Engineering Task Force).
RFC 1738: Uniform Resource Locators (URL),
저자: T. Berners-Lee, L. Masinter, M. McCahill. 1994.

IETF RFC1808

IETF (Internet Engineering Task Force).
RFC 1808: Relative Uniform Resource Locators,
저자: R. Fielding. 1995.

IETF RFC2141

IETF (Internet Engineering Task Force).
RFC 2141: URN Syntax,
저자: R. Moats. 1997.

ISO 8879

ISO (International Organization for Standardization).
ISO 8879:1986(E).
정보 처리 -- 텍스트와 오피스 시스템 -- (SGML언어)
Information processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML) First edition -- 1986-10-15.
[Geneva]: International Organization for Standardization, 1986.

ISO/IEC 10744

ISO (International Organization for Standardization).
ISO/IEC 10744-1992 (E).
정보 기술 -- Hypermedia/Time-based Structuring (HyTime 언어).
[Geneva]: International Organization for Standardization, 1992.
Extended Facilities Annexe.
[Geneva]: International Organization for Standardization, 1996.

B. 글자 분류

다음 유니코드(Unicode) 표준에 정의된 특징들 글자은 분류되어있다. 기초(base) 글자(다른것들 보다 이들은 영어(Latin)의 알파베트 글자들을 포함하고, 구분글자(diacritics)는 제외된다), 표식글자(ideographic) 글자, 그리고 결합(combining) 글자들(무엇보다 이 분류는 대부분의 구분글자(diacritics)을 포함)로 ; 이들 분류는 결합하여 글자들의 분류를 만든다. 숫자와 확장자(extender)들도 구별하였다.

여기에 정의된 글자 분류는 다음과 같이 유니코드(Unicode) 글자 데이터베이스 기초로 부터 만들어 질 수 있다:

• 이름의 시작 글자는 Ll, Lu, Lo, Lt, Nl 가운데 하나이여야 한다.
• Name-start 글자 이외의 이름 글자들은 Mc, Me, Mn, Lm, 또는 Nd 중 하나를 가져어야 한다.
• compatibility area에 있는 글자들(말하자면 with 글자 코드가 #xF900 보다 크고 #xFFFE 보다 작은)은 XML 이름에 허용되지 않는다.
• 폰트(font) 또는 통용성 전환(compatibility decomposition)을 갖는 글자들(말하자면 이들은 "compatibility formatting tag"를 가지고 데이터베이스의 필드 5에 있는 -- field 5로 표시되고 "<"로 시작하는)은 허용되지 않는다.
• 다음 글자들은, 특성 화일이 그들을 알파베틱으로 분류하였슴으로, 이름 글자들이 아니고 이름 시작 글자로 취급된다: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
• #x20DD-#x20E0 벙위의 글자들은 제외되었다(Unicode, 항목 5.14에 따라).
• 글자 #x00B7는, 특성 목록이 지정한대로, 확장자(extender)로 분류된다.
• 글자 #x0387는 이름 글자로 추가된다, #x00B7은 그는 정규적으로 동일함으로.
• ':' 와 '_' 글자들은 이름 시작 글자들에 허용된다.
• '-' 와 '.'글자들은 이름 글자들에 허용된다.

C. XML 과 SGML (비지명적)

XML은 SGML의 하부세트(subset)가 되도록 설계되었고, 여기서 각 유효한(valid) XML 문서는 SGML 문서에도 맞아야 한다. SGML에서와 달리 XML이 문서들에 추가적으로 제한 한 상세 비교는 [Clark]을 참조하라.

D. 엔티티와 글자 참조의 확장 (비지명적)

이 부록은, 4.4 "XML 처리자의 엔티티와 참조의 처리"에 설명 한 바와 같이, 엔티티(entity)- 와 글자-참조의 인식(recognition)과 확장(expansion)의 순서를 설명하는 일부 예제들을 포함하고 있다.

선언이 DTD를 포함하려면

그러면, 엔티티(entity) 선언이 해석(parse)되면 XML 처리자(processor)는 그 글자 참조를 인식 할 것이고, 이를 해결(resolve)하여 엔티티 "example"의 값으로 아래 스트링을 저장한다:

문서에서 "&example;"을 참조하면 텍스트는 다시 해석(reparse)되고, 이때에는 "p" 엘레멘트의 시작태그와 종료태그가 인식 될 것이고, 세개의 참조들은 인식되고 확장(expand)되어, "p" 엘레멘트(element)는 아래 내용(content)을 가질 것이다(모든 데이터는 있으나 구분자나 코드는 없는):

더 복잡한 예제는 코드(rule)와 그 효과를 완전히 설명 할 것이다. 아래 예제에서, 줄 번호는 오직 참고 만를 위한 것이다.

이는 아래의 결과를 만든다:

• 4번, 글자 37 참조는 즉시 확장되고, 파라메터(parameter) 엔티티(entity) "xx"는 값 "%zz;"로 부호(symbol) 테이블에 저장된다. 교체 텍스트가 없어 파라메터(parameter) 엔티티(entity) "zz"의 참조는 인식하지 못한다. ("zz"가 아직 선언되지 않았슴으로, 이는 오류일 것이다.)
• 5번, "<" 글자 참조는 즉시 확장되고, 파라메터(parameter) 엔티티(entity) "zz"는 교체 텍스트 "<!ENTITY tricky "error-prone" >"로 저장되며, 이는 잘 형성된 엔티티(entity) 선언이다.
• 6번, "xx" 참조는 인식되고, "xx"("%zz;") 교체 텍스트는 해석(parse)된다. 이번에는 "zz" 참조가 인식되고, 그 교체 텍스트("<!ENTITY tricky "error-prone" >")가 해석(parse)된다. 일반(general) 엔티티(entity) "tricky"가 이제 선언되어, 교체(replacement) 텍스트 "error-prone"를 갖는다.
• 8번, 일반(general) 엔티티(entity) "tricky" 참조는 인식되고, 확장되어, "test" 엘레멘트(element)의 완전한 내용(content)은 문법이 없는 그대로 기술하는 스트링 "This sample shows a error-prone method."가 된다.

E. 판정적 내용 모델 (비지명적)

규격부합성(compatibility)을 위하여, 엘레멘트 타입 선언에서 내용(content) 모델(model)들은 판정적이 될 필요가 있다.

SGML은 판정적 내용 모델("unambiguous(명확한)"로 불리움)을 필요로 한다; SGML 시스템을 사용하는 XML 처리자(processor)들은 비 판정적 내용 모델을 오류들로 표시 할 수 있다.

예를 들어, 내용(content) 모델(model) ((b, c) | (b, d))는 비 판정적이다. 주어진 최초의 b로는, b 위에 따라오는 엘레멘트(element)를 내다 보지 않고는, 해석자(parser)가 모델(model)의 어느 b가 일치 검사되는가 알 수 없기 때문이다. 이 경우, b의 두 참조는 단일 참조로 붕괴되어, (b, (c | d)) 모델(model)을 만들 수 있다. 이제 최초의 'b'는 명확히 내용(content) 모델(model)의 단일 이름과 만 일치 검정을 한다. 해석자(parser)는 앞에 무엇이 따라오는가를 알 필요가 없다; 'c' 또는 'd'가 받아 질 것이다.

어 공식적으로: 유한 문장 자동화는 내용 모델로 부터 표준 기능(algorithm)들을 사용하여 구성 될 수 있다. 예를 들면 Aho, Sethi와 Ullman [Aho/Ullman]의 항목 3.9 기능(algorithm) 3.5. 많은 이와 같은 기능(algorithm)들에서, 일반 공식(표현)으로 각 위치에 후속 세트가 구성된다 (말하자면, 일반 공식(표현) 문법 체계에서 각각 행할 조각); 만일 어떤 위치에, 같은 엘레멘트 타입 이름 안에 하나 이상의 후속 위치가 라벨되어 있는, 후속 세트가 있으면, 내용 모델은 오류이며, 오류로 알릴 수 있다.

많은 것을 허용하는 기능(algorithm)들이 있지만, 모든 비 판정적 내용 모델이 같은 판정적 모델(model)에서 처럼 자동 정리하는 것은 아니다; Br?gemann-Klein 1991 [Br?gemann-Klein] 참조.

F. 글자 엔코딩의 자동감지 (비지명적)

XML 엔코딩(encoding) 선언은 각 엔티티(entity)에, 어떤 글자 엔코딩이 사둉되고 있는가를 나타내는, 내부적으로 라벨(label)로 기능(function)한다. 그러나, XML 처리자(processor)가 내부적 라벨(label)을 읽을 수 있기 전에, 어떤 글자 엔코딩)이 사용되고 있는가(어떤 내부적 라벨을 지정하려고 하는가)를 알아야 한다는 것은 명백하다. 일반적인 경우, 이것은 가망이 없는 상황이다. 그러나, XML에서 완전히 불가능 한 것은 아니다. XML은 일반적인 경우를 두가지 방식으로 제한하기 때문이다: 각 적용(implementation)은 글자 엔코딩(encoding)들의 한정된 세트만을 지원하는 것으로 간주되고, XML 엔코딩 선언은, 정상적인 경우 각 엔티티(entity)에 사용되는 글자 엔코딩을 자동 검정이 가능하게 하기 위하여, 위치와 내용(content)이 제한된다. 또한, 많은 경우 XML 데이터 흐름 자체에 추가적으로 사용 할 수 있는 다른 정보 자원들이 있다. XML 엔티티(entity)가 처리자에게 다른 동반하는 (외부적) 정보를 제시하는가 않는가에 따라, 두가지 경우가 구별 될 수 있다. 먼저 제시하지 않는 경우를 보자.

UTF-8 또는 UTF-16가 아닌 각 XML 엔티티 양식은 반드시 XML 엔코딩 선언으로 시작하여야 되기 때문에, 여기서 첫 글자들은 '<?xml'이어야 하며, 규격에 부합하는 처리자(processor)는 감지 할 수 있를 것이고, 두개에서 네개의 8진 숫치 입력 후에는 다음이 적용된다. 이 목록을 읽는데 UCS-4에서 '<'는 "#x0000003C"이고 '?'는 "#x0000003F"이며, 데이터 흐름에 필요한 UTF-16의 Byte Order Mark는 "#xFEFF"이라는 것을 알면 도움이 된다.

• 00 00 00 3C: UCS-4, big-endian machine (1234 순서)
• 3C 00 00 00: UCS-4, little-endian machine (4321 순서)
• 00 00 3C 00: UCS-4, unusual octet order (2143)
• 00 3C 00 00: UCS-4, unusual octet order (3412)
• FE FF: UTF-16, big-endian
• FF FE: UTF-16, little-endian
• 00 3C 00 3F: UTF-16, big-endian, no Byte Order Mark (엄격히 말하면 오류)
• 3C 00 3F 00: UTF-16, little-endian, no Byte Order Mark (엄격히 말하면 오류)
• 3C 3F 78 6D: UTF-8, ISO 646, ASCII, ISO 8859의 일부 부분, Shift-JIS, EUC, 또는 다른 어떤 7-bit, 8-bit, 또는 혼합 너비(mixed-width) 엔코딩(encoding), 이는 ASCII 그 글자들은 정상위치, 너비와 값들을 갖는다 것을 확인한다; 이들 중 어느것이 적용된다는 것을 알기 위해, 실제 엔코딩 선언이 읽어져야 하지만, 이들 엔코딩들은 모두 ASCII 글자들에서 같은 이진수(bit) 형태(patterns)를 사용하므로, 엔코딩(encoding) 선언 자체를 읽는 것이 가능하다.
• 4C 6F A7 94: EBCDIC (어떤 선호로; 어떤 코드 페이지가 사용되는가는 알려면 완전한 엔코딩 선언이 읽혀져야 한다.)
• 기타: 엔코딩(encoding) 선언 없는 UTF-8, 또는 아니면 데이터 흐름이 붕괘되는, 부위적(fragmentary), 또는 어떤 종류의 포장(wrapper) 안에 쌓인

이 수준의 자동감지는 XML 엔코딩(encoding) 선언을 읽고, 글자 엔코딩 인식자(identifier)에 해석(parse)하는데는 충분하다. 여전히 각 엔코딩 가족의 개별 구성원을 구별하는 것이 필요하다. (예를 들어 8859로 부터 UTF-8, 서로 다른 8859의 부분, 또는 사용하는 특정 EBCDIC 코드 페이지(code page)를 구별, 등).

엔코딩 선언의 내용들이 ASCII 글자로 제한되기 때문에, 처리자(processor)는, 사용되는 엔코딩(encoding) 가족(family)가 감지되면, 전체 엔코딩 선언을 쉽게 읽을 수 있다. 실제적으로, 모든 널리 사용되는 글자 엔코딩들은 위의 하나에 해당되므로, 운영체계나 송신 프로토콜(transport-protocol) 수준의 외부적 자원 정보에서 현실성이 적은 경우도, XML 엔코딩 선언은 상당히 합리적으로, 글자 엔코딩(encoding)들의 범위 라벨링(labeling)하도록, 허용한다.

일단 처리자(processor)가 사용하는 글자 엔코딩을 감지하면, 각 입력 과정을 달리 불러 할 것인가, 혹은 각 입력 글자에 적당한 변환 기능(function)을 호출 할 것인가등에, 적정하게 작용 할 수 있다.

다른 자체 라벨링(self-labeling) 체계에서와 마찬가지로, 어떤 소프트웨어가 엔코딩(encoding) 선언 갱신 없이 엔티티(entity)의 글자 세트 또는 엔코딩에 변경을 주면, XML 엔코딩 선언은 작용하지 않을 것이다. 글자 엔코딩 과정 적용자(Implementor)들은 사용된 내부적, 외부적 정보를 엔티티(entity)에 라벨(label)하는데 정확히 하도록 주의하여야 한다.

두변째 가능한 경우는, 일부 화일 시스템과 네트워크 프로토콜에서 처럼, XML 엔티티(entity)가 엔코딩 정보와 함께 올 때, 발생된다. 복수 정보 자원을 사용 할 수 있을 때, 그들 사이의 상대적 우선순위와 마찰(모순)의 경우 선호되는 처리 방식(method)은 XML을 전달하는데 사용되는 상위 레벨 프로토콜(protocol)의 부분으로 지정되어야 한다 내부적 라벨(label)과 외부적 헤더(header)의 "MIME-type" 라벨 사이의 상대적 우선순위 규칙들은, 예를 들어, "text/xml"와 "application/xml MIME type"을 정의하는 RFC 문서의 부분이어야 한다. 그러나, 공통사용성(interoperability)의 견지에서 아래 규칙들이 추천된다.

• XML 엔티티가 화일 안에 있으면, 글자 엔코딩(encoding)을 결정하기 위하여 Byte-Order Mark와 엔코딩 선언 PI가 (있으면) 사용된다; 모든 다른 정보 계통(heuristics) 및 자원(source)들은 오류회복 만을 위한 것이다.
• XML 엔티티가 "text/xml"의 "MIME type" 과 함께 전달(배달)되면, "MIME type"의 charset 파라메터(parameter)가 글자 엔코딩(encoding) 방식(method)을 결정한다; 모든 다른 정보 계통 및 자원들은 오류회복 만을 위한 것이다.
• XML 엔티티(entity)가 "application/xml"의 "MIME type" 과 함께 전달(배달)되면 글자 엔코딩(encoding)을 결정하기 위하여 Byte-Order Mark 와 엔코딩 선언 PI가 (있으면) 사용된다; 모든 다른 정보 계통(heuristics) 및 자원(source)들은 오류회복 만을 위한 것이다.

이 규칙들은 프로토콜 수준(protocol-level) 문서가 없을 때에 만 적용된다; 구체적으로, "MIME types text/xml"와 "application/xml"이 정의 되었으면, 해당 RFC 추천안들은 이 규칙들을 적용하지 말아야 한다.

G. W3C XML 작업구룹(Working Group) (비지명적)

이규격은 W3C XML 작업구룹(WG: Working Group)에 의하여 발행을 위하여 준비되고 승인되었다. 이규격의 WG 승인은 모든 WG 구성원이 '승인'에 투표하였슴을 의미하는 것은 아니다. 현재와 과거의 XML WG 구성원들은:

Jon Bosak, Sun (Chair); James Clark (Technical Lead); Tim Bray, Textuality and Netscape (XML Co-editor); Jean Paoli, Microsoft (XML Co-editor); C. M. Sperberg-McQueen, U. of Ill. (XML Co-editor); Dan Connolly, W3C (W3C Liaison); Paula Angerstein, Texcel; Steve DeRose, INSO; Dave Hollander, HP; Eliot Kimber, ISOGEN; Eve Maler, ArborText; Tom Magliery, NCSA; Murray Maloney, Muzmo and Grif; Makoto Murata, Fuji Xerox Information Systems; Joel Nava, Adobe; Conleth O'Connell, Vignette; Peter Sharpe, SoftQuad; John Tigue, DataChannel

영문 저작권? 영문 W3C (영문 MIT, 영문 INRIA, 영문 Keio ), 모든 권리 보유. W3C 영문 책임, 영문 상표권, 영문 문서 사용과 영문 소프트웨어 면허 규칙들 적용.

W3C의 문서 사용을 위한 법를적 문제는 원문을 참조하라.
번역자는 이 번역문에 대한 직, 간접적인 일체의 책임을 지지 않는다.

다른 규격 번역문들
[HTML 4] [CSS 2] [CSS 1] [XHTML 1.0]
번역문 제공자 : 트리오 웹 프랜드

이문서(http://trio.co.kr/webrefer/xml/xml10.html)는 자유로이 연결 사용이 가능함.

저작권 정보

본 강좌는 Prentice Hall 출판사의
"XML: The Annotated Specification"을 일부 참고하였음을 밝힙니다.

본 강좌에서 사용하고 있는 XML 1.0 스펙의 한국어 번역본은 윈도우 사용자 그룹에 그 저작권이 있으며, 이 스펙 전체가 단 한 구절도 훼손되지 않는 경우에 한하여 배포될 수는 있으나 기타 상업적인 목적으로의 전재 및 인용은 금합니다

저작권 정보

본 강좌는 Prentice Hall 출판사의
"XML: The Annotated Specification"을 일부 참고하였음을 밝힙니다.

본 강좌에서 사용하고 있는 XML 1.0 스펙의 한국어 번역본은 윈도우 사용자 그룹에 그 저작권이 있으며, 이 스펙 전체가 단 한 구절도 훼손되지 않는 경우에 한하여 배포될 수는 있으나 기타 상업적인 목적으로의 전재 및 인용은 금합니다.

본 강좌의 저작권 또한 윈도우 사용자 그룹에 있으며 무단 전재 및 인용을 금합니다

저작권 정보

본 강좌는 Prentice Hall 출판사의
"XML: The Annotated Specification"을 일부 참고하였음을 밝힙니다.

본 강좌에서 사용하고 있는 XML 1.0 스펙의 한국어 번역본은 윈도우 사용자 그룹에 그 저작권이 있으며, 이 스펙 전체가 단 한 구절도 훼손되지 않는 경우에 한하여 배포될 수는 있으나 기타 상업적인 목적으로의 전재 및 인용은 금합니다.

본 강좌의 저작권 또한 윈도우 사용자 그룹에 있으며 무단 전재 및 인용을 금합니다

## 자료출처 : Devpia XML 게시판의 김병희 님의 자료를 무단 -_- ;; 복사 ;

1.DOM(Document Object Model)문서개체모델

원래 DOM 이란 플렛폼과 언어에 구애받지 않는 인터페이스를 말합니다.

웹 컨텐트와 구조, 문서 스타일에 접근하여 동적으로 변경할 수 있도록 합니다.

그럼 실질적인 의미의 DOM이란 무엇일까요..

W3C에 의해 개발되고 있는 프로그래밍 인터페이스 규격인 DOM은,

프로그래머가 HTML 페이지나 XML 문서들을 프로그램 객체로 만들거나 수정할 수 있도록 해줍니다.

현재로서, HTML과 XML은 그저 데이터 구조의 형태로 문서를 표현하는 방법일 뿐입니다.

이러한 문서들은 마치 프로그램 객체처럼, 자신들의 콘텐츠나, 객체 내에 감추어진 데이터를 가질 수 있게 됨으로써,

문서를 조작할 수 있는 콘트롤을 보장하는데 도움을 줄 수 있게 합니다.

문서들은 객체들과 마찬가지로,메쏘드라고 불리는 객체지향 프로시저들을 함께 가지고 갈 수 있습니다.

그럼 XML DOM을 어떻게 사용할까요.

XML 파서의 인스턴스를 만들어 XML DOM을 사용합니다.

이것을 가능하게 하기 위해 Microsoft에서는 Msxml.dll의 표준 COM 인터페이스 집합을 통해 XML DOM을 제공합니다.

Msxml.dll에는 XML 문서 작업을 위한 형식 라이브러리와 구현 코드가 들어 있습니다.

Internet Explorer에서 실행되는 VBScript와 같은 스크립팅 클라이언트로 작업하는 경우에는 CreateObject 메쏘드를 사용하여 Parser 개체의 인스턴스를 만드는 방식으로 DOM을 사용합니다.

ASP(Active Server Page)에서 VBScript를 사용하는 경우에는 Server.CreateObject를 사용합니다.

Set objParser = Server.CreateObject( "Microsoft.XMLDOM" ) 

이것은  많이 보셨죠..? 정리 하자면 CreateObject 메쏘드를 사용해서 인스턴스를 만들어서 DOM 을 사용하는 것이죠.

MSDN에 가보시면 예제와 설명이 풍부하게 나와 있습니다.

꼭 참고 하세요.

2. 객체(Object)와 인스턴스(instance)

프로그래머의 관점에서 말씀 드리면 객체는 어떤 실행을 하게될 코드의 집합입니다.

인스턴스화는 객체에 대해 특정한 변형을 정의하고, 이름을 붙인 다음,

그것을 물리적인 어떤 장소에 위치시키는 등의 작업을 통해, 인스턴스를 만드는 것을 의미합니다.

정리 하자면 지하에 어떤 장소가 있다고 칩시다. 그 장소에는 작동할 수 있는 기계가 있구요.

그 장소에 들어가기 위해서는 통로가 있어야 겠지요. 그 통로를 만들고 그 장소에 들어가면 기계를 작동 할 수가 있습니다.

그 기계가 객체 이고 그 통로를 인스턴스라고 비유 할 수 있습니다.

CreateObject( "Microsoft.XMLDOM" )가 이제 이해가 가시죠. CreateObject를 이용 인스턴스를 만들고 Microsoft.XMLDOM 를 사용하는 겁니다.

그리고 다 사용하고 난 다음에는 통로를 닫아 줘야 겠죠. 그렇지 않으면 통로는 계속 열려 있을테니까요.

set abc = noting 이 바로 인스턴스를 닫아 주는 겁니다.

이제 인스턴스, 객체, dom 등이 이해가 가시나요?

참고로 저는 용어에 대한 설명을 얻기 위해서 텀즈 사이트와 MSDN사이트를 자주 갑니다..
개념 파악에 확실히 도움이 되니까 여러분들도 자주 가셔서 정보 얻으세욤...

## 자료출처 ~ Devpia XML 게시판 김병희 님 자료를 -_- 무단으로 복사해왔습니다 ;;

XML과 CSS, XSLT

저번 시간에는 XML를 본격적 으로 배우기 전에 기본적으로 숙지해야할 개념 들에 대해
알 아 보았다. 간단하게 복습해 보자. 우선 문서(document)에 대해 이해 했다. 즉 문서
의 구성요소가 의미와 내용 그리고 구조 라고 했었다. 그리고 마크업 언어는 그런 문서
를 표현해 주기 위한 기호들의 규칙의 집합이라고 했었다. 이 두가지를 이해 했다면 일
단 성공이다. 오늘은 ‘마크업 언어로 작성된 코드 즉, 태그 들을 어떻게 브라우저가 스
크린 상에서 보여주는가?’ 에 대한 대답의 내용으로 강좌를 하려고 한다. 오늘 배워야
할 용어는 CSS와 XSLT이다.


1.CSS(cascading style sheets)
HTML은 학자들이 쓴 논문의 내용을 구조화 하여 보여주기 위해 처음 고안된 마크업 언어
라고 저번에 설명 했었다. HTML소스는 보여주려는 내용과 그 내용을 어떻게 표현 할 것
인가를 나타내는 태그로 구성된다. 물론 동적인 웹페이지의 경우 스트립트 소스와 ASP등
의 소스들이 서로 섞여 있지만 여기서는 일단 HTML만 생각하자.

여러분이 초기에 마크업 언어를 만든 개발자라고 하자. 그리고 논문을 웹페이지에 보여
주려고 한다. 그러면 다음 문제를 생각 하지 않을 수 없을 것이다.
즉 논리적 구조를 바탕으로 도큐먼트를 만드는 대신에 요소의 위치를 어떻게 잡을 것인
가, 글자(폰트)를 무엇으로 할 것인가, 색을 무엇으로 바꿀까 하는 문제들 이다.
한마디로 표현해 웹상에서 어떻게 가시적으로 보여줄 것인가 하는 문제인 것이다. 어떻
게 이쁘게 어떻게 눈에 띄도록 하는 것들이 그런것이다.

그래서 고안된 것이 CSS이다. 이제 CSS에 대해 간략히 정리하자.
‘CSS는 만들어진 도큐멘트를 어떻게 디스플레이(표현-presentation) 할 것인지 대한 스
타일 시트이다.’

웹브라우저에서 어떤 문서를 보여주기 위해 필요한 것은 보여줄 문서의 내용과 그 내용
에 대한 구조를 나타내는 마크업언어인 HTML, 그리고 그것들을 웹브라우저에서 표현해
줄 스타일 시트가 필요하다. CSS는 물론 HTML태그가 어떻게 표현될것인지를 정해주는 것
이다. 그러므로 HTML로 작성되지 않은 순수한 문서에 CSS를 적용시키는 것은 말이 성립
되지 않는다. HTML 태그가 있음으로 해서 CSS가 있는 것이다.!

CSS는 HTML 코드 안에 삽입 되거나 따로 *.CSS라는 확장자로한 파일로 저장되어 있다.
Text/css란 코드를 본적이 있을 것이다. *.CSS라는 파일명이 삽입된 HTML코드를 본적도
있을 것이다. 즉 ‘다음 HTML코드를 *.CSS파일에 정의된 대로 웹브라우저에서 보여 주어
라’하는 뜻이다. 물론 이것을 해석하는 엔진은 당연히 브라우저 안에 있다.
여기서 잠깐 헷갈려 하는 사람들을 위해 서버에서 클라이언트로 오는 데이터가 무엇인
지 설명해야겠다.


클라이언트가 서버에서 요청하는 파일은 모두 HTML코드로 되어있다. ASP등의 서버쪽 언
어들은 서버 측의 ASP엔진에서 이미 해석되고 순수한 HTML코드 데이터만 클라이언트로
오게 되는 것이다. 그리고 클라이언트의 웹브라우저에서 그 태그들을 해석하여 웹페이지
에 나타내는 것이다. 자바스크립트 또한 웹브라우저안에서 해석된다.
시간 날 때 서버측 언어와 클라이언트측 언어에 대해 설명할 기회가 있을 것이다.  
이제 CSS에 대해 이해가 가는가? 그럼 다음을 보자.




2.XSLT(Extensible Stylesheet Language for Transformations)
우리가 공부하고자 하는 것은 XML이다. 그런데 자꾸 HTML에 대한 설명을 집어 넣는 이유
는 우선 HTML을 조금 이라도 아는 분들이 XML을 배우려고 하지 전혀 모르는 사람이 XML
을 배우려고 하지는 않는다는 것이다. 그러기 때문에 HTML에 대한 설명을 XML에 대한 설
명을 위해 집어 넣는 것이다.


그럼 이제 본격적으로 XSLT에 대해 알아 보자.
XSLT에 대해 이해하기 전에 스타일 시트에 대해 어떤 질문이 생겨야 한다. XML도 어차
피 마크업 언어 이고 XML태그를 웹상에서 표현해 주려면 CSS가 필요해야 한다. 그런데
처음 강좌에서 XML의 강력한 장점 중의 하나가 사용자가 마음대로 태그를 만들 수 있다
는 것이었다. 이제 본격 적인 질문이다. 사용자 마음대로 태그를 만들어 버리면 브라우
저가 어떻게 그 태그를 해석해서 웹페이지에 보여준다는 것인가? 대답부터 말하면 웹브
라우저는 ‘전혀 모른다’ 이다. HTML에 쓰이는 태그는 HTML 스펙에 따라 정의되어 있
고 브라우저는 그 스펙에 대한 정보를 포함하고 있기 때문에 즉 정해진 태그는 얼마든
지 해석해서 보여 줄 수 있다. 하지만 XML의 경우 당연히 보여 줄 수 없다. 따라서 스타
일 시트를 쓰지 않고 XML파일을 작성하고 웹상에 출력해 본다면 파일 그대로 보여주게
된다.

즉 XML 문서를 웹상에서 디스 플레이 하려면 당연히 스타일 시트가 있어야 한다. 물론
CSS를 쓴다. 하지만! 정해진 대로 어떤 태그를 어떤 식으로 디스 플레이 할 필요는 없다
는 것이다. 만약 <안녕>이라는 태그(XML에서는 요소라 부른다)를 사용한다면 CSS에서 <
안녕>태그에 포함된 내용은 어떻게 보여주라고 지정할 수 있다는 말이다.
XML에서는 이것을 <?xml-stylesheet ?>라는 처리 지시문을 통해 정해 준다.


이제 XSLT에 대해 파고 들어 보자.
XML도 충분히 CSS를 이용해서 웹상에서 디스플레이 해 줄 수 있다고 했다. 근데 굳이 다
른 스타일 시트를 쓰려는 이유는 무엇일까?
‘XSLT는 XML문서를 텍스트를 기반으로 하는 다른 XML뿐만 아니라 어떤 다른 형식으로
도 변환 하는 것을 가능하게 한다’ transformation이라는 단어가 ‘변환’이라는 뜻을
가지고 있다는 것을 명심하자.

즉 XSLT는 XML변환 언어이다. XML는 순수하게 문서의 데이터 구조만을 나타낸다. 그리
고 XML의 강력한 장점 중의 하나가 서로 다른 플랫폼의 서로 다른 어플리케이션과 상관
없이 쓸 수 있다는 것이었다. 이것을 이식성이 강하다고 말하는데 XML을 다른 웹상 뿐
만 아니라 다른 어떤 어플리케이션에 나타내고자 할 때 즉 XML을 다른 용도를 사용하고
자 할 때 XSLT를 사용한다.


정리하자면 하나의 XML문서가 있다면 이것을 가지고 이 XML문서를 사용하고자 하는 각각
의 어플리 케이션이 그 어플리케이션에 맞게 표현할 XSLT를 이용하여 표현 할 수 있다.
물론 각각의 경우 적용할 XSLT는 다를 것이다.
XSLT변환을 하기 위해 필요한 것은 XML문서, XSLT스타일 시트 그리고 XSLT엔진 이다.
HTML의 경우 웹브라우저에 자체 해석 엔진이 있다고 했다. 물론 CSS해석 엔진도 포함된
다. XML의 경우도 웹브라우저에 당연히 엔진이 있어야 한다.
MSXML라고 본적이 있을 것이다. 어디 가서 MSXML3.0 또는 4.0을 깔아야 한다고 다운로
드 주소까지 친절하게 나와있는 사이트를 보았을 것이다. 이것이 쉽게 말해 XML해석 엔
진이다. 이쪽 업계에서 이것을 파서라고 부른다. MSXML은 IE(Internet Explorer)에 장착
된 XML파서로서 XSLT엔진 또한 포함하고 있다.
이제 XSLT에 대해 이해가 가는가…?


다음 시간에는 XSLT예제와 직접 실습해 보도록 하겠다. 그리고 특히 전자 상거래 에서
왜 XSLT가 중요한지에 대한 설명과 그 예도 들어 보도록 하겠다.

자바가 바라보는 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 (사람은 찾고자 하는 정보에 대한 검색조건만 입력하면 컴퓨터가 알아서 최적의 결과를 보여준다.)