XML 1.0 규격 한국어 번역문
확장성 작성 언어
번역에 관련한 주석는 이 색상으로 표시하여 원문 번역 내용과 구분하였다.
CSS 적용은 원본에 준하여 하되 한글 표현이 어색한 부분은 약간 조정하였다.
W3C에서 프레임을 허용하지 않아 프레임을 선택 할 수 있게 하였다.
영문 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
목차
1.
소개 1.1
기원과 목표 1.2
용어2.
문서들 2.1
잘 형성된 XML 문서들 2.2
글자들 2.3
공통 문법적 구성 2.4
글자 데이터와 코드(markup) 2.5
코멘트(comment) 2.6
처리지시(processing instruction) 2.7
CDATA 항목 2.8
서문(prolog)과 문서 타입 선언(document type declaration) 2.9
독립 문서 선언(Standalone Document Declaration) 2.10
공백의 처리 2.11
줄 끝의 처리(End-of-Line Handling) 2.12
언어의 인식3.
논리적 구조 3.1
시작태그, 종료태그와 빈 엘레멘트 태그 3.2
엘레멘트 타입 선언 3.2.1
엘레멘트 내용 3.2.2
혼합 내용(content) 3.3
애트리뷰트 목록 선언들 3.3.1
애트리뷰트 타입 3.3.2
애트리뷰트(attribute) 디폴트 3.3.3
애트리뷰트 값 정상화(normalization) 3.4
조건부 항목(conditional section)4.
물리적 구조 4.1
글자와 엔티티 참조 4.2
엔티티(entity) 선언 4.2.1
내부적 엔티티(entity) 4.2.2
외부적 엔티티(entity) 4.3
해석(parse)된 엔티티(entity) 4.3.1
텍스트 선언 4.3.2
잘 형성된 해석(parse)된 엔티티(entity) 4.3.3
엔티티 안의 글자 엔코딩 4.4
XML 처리자의 엔티티와 참조의 처리 4.4.1
인식하지 못하는 4.4.2
포함된 4.4.3
포함된 If 유효성 검정 4.4.4
금지된 4.4.5
리터랄(literal)에 포함된 4.4.6
알림(notify) 4.4.7
통과(bypassed) 4.4.8
PE(파라메터 엔티티)로 포함된 4.5
내부적 엔티티(entity) 교체 텍스트의 형성 4.6
사전에 정의된 엔티티(entity) 4.7
주석(notation) 선언들 4.8
문서 엔티티(entity)5.
규격부합성 5.1
유효성 검정하는, 유효성 검정 않는 처리자 5.2
XML 처리자(processor)의 사용6.
주석(notation)
Appendices
A.
참조 A.1
지명적 참조 A.2
다른 참조B.
글자 분류C.
XML과 SGML (비지명적)D.
엔티티와 글자 참조의 확장 (비지명적)E.
판정적 내용 모델 (비지명적)F.
글자 엔코딩의 자동감지 (비지명적)G.
W3C XML 작업구룹 (비지명적)
확장성 작성 언어 (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)을 기술한다.
XML은 1996 W3C가 주관하는 XML 작업구룹(당초에는 SGML 점검회: Editorial Review Board)에 의하여 개발되었다. Sun Microsystems의 Jon Bosak가 회장이었고, 역시 W3C에 의하여 조직된, XML에 특히 관심이 있는 구룹(Special Interest Group: 과거 SGML 작업구룹으로 알려짐)이 참여하였다. 작업구룹의 구성원은 부록에 기재되어있다. Dan Connolly가 W3C의 접촉 담당으로 있었다.
XML에 대한 토론 목표는 다음과 같다:
- XML은 인터넷에서 막바로 사용 할 수 있어야 한다..
- XML은 넓은 종류의 적용(application)을 지원하여야 한다.
- XML은 SGML과 상호 통해야(사용가능) 한다.
- 이는 XML 문서들을 처리하는 프로그램을 쉽게 쓸 수 있어야 한다.
- XML의 선택적 성능(feature)들이 완전히 최소되던가 가능하면 없어야 한다.
- XML 문서들은 인간이 이해하기에 상당히 쉬워야 한다.
- XML 디자인을 빨리 할 수 있어야 한다.
- XML 디자인을은 양식에 따르고 함축적이야 한다.
- XML 문서들은 생성하기 쉬워야 한다.
- XML 작성(markup)에서의 간결성(terseness)은 별로 중요하지 않다.
이 규격과 관련된 표준들(Unicode, 글자들을 위한 ISO/IEC 10646, 언어의 인식 태그들을 위한 RFC 1766, 언어 이름 코들을 위 한 ISO 639, 국가 이름 코드를 위한 ISO 3166)은, 비표준인 XML 버전 1.0과 이를 처리하는 구성 컴퓨터 프로그램등에 필요한, 모든 정보를 제공한다.
XML 규격의 원문 버전은, 모든 텍스트와 법률적 경고에 합당하면, 배포를 자유롭게 할 수 있다.
용어들은 이 규격 본체에서 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 문서들이 처리 될 가능성을 향상하기 위하여, 비 구속적으로, 포함한 추천사항이다.
이규격에 정의된 바에 따라 잘 형성된 것이면, 데이터 오브젝트(object)는 하나의 XML 문서이다. 잘 형성된 XML 문서는 또한, 추가적인 제한요소들에 맞으면, 유효(valid) 할 수 있다.
각 XML 문서는 논리적 구조와 물리적 구조를 갖는다. 물리적으로, 문서는 엔티티(entity)라 불리우는 단위들로 이루어 진다. 한 엔티티(entity)는 다른 엔티티를 참조(refer) 할 수 있으며, 그 문서 안에 포함되게 된다. 한 문서는 최상위("root") 또는 문서 엔티티(entity)로 시작된다. 논리적으로, 문서는 선언, 엘레멘트(element), 코멘트(comment), 글자 참조와 처리지시(processing instruction)들로 이루어 지며, 이들 모두 그 문서의 명시적 코드(markup)로 지정된다. 논리적 구조와 물리적 구조는, "4.3.2 잘 형성되고 해석(parse)된 엔티티(entity)"에 설명된 바와 같이, 적정하게 네스트(nest)되어야 한다.
텍스트적 오브젝트(object)는 다음을 만족시키면 잘 형성된 XML 문서이다:
- 전체적으로, 라벨된(labeled)
문서 산물과 일치한다.
- 이규격에서 주어진 잘 형성됨을 위한 필수사항들에 부합한다.
- 문서에서 직접 혹은 간접적으로 참조된 각 해석(parse)된 엔티티가 잘 형성된 것이다.
일치하는 문서(document) 산물(production)은 다음 사항을 내포(의미)한다:
- 하나 이상의 엘레멘트(element)를 포함한다.
- 최상위(root)라 불리우는 엘레멘트 또는 문서 엘레멘트 단 하나 만을 가지며, 이들 부분이 어떤 다른 엘레멘트의 내용(content) 안에 나타나지 않는다. 모든 다른 엘레멘트들에서, 또 다른 엘레멘트의 내용 속에 시작태그가 있으면, 종료태그도 같은 엘레멘트의 내용 속에 있다. 좀 더 간단히 말하면, 시작과 종료태그들로 구분되는 엘레멘트들은 서로 적정하게 네스트(nest) 되어있다.
이 결과로서, 문서에서 최상위가 아닌(non-root) 각 엘레멘트 'C'에게는, 'C'는 'P'의 내용 안에 있으나, 'P'의 내용에 있는 어떤 다른 엘레멘트의 내용이 않되록, 문서에서 다른 엘레멘트 'P'가 있다, 여기서 'P'는 C의 모체(parent)로 참조되고, 'C'는 'P'의 자식(child)으로 참조된다.
해석(parse)된 엔티티(entity)는 텍스트를 갖는데, 이는 글자들의 연속으로, 코드(markup)나 글자 데이터가 될 수 있다. 한 글자는, ISO/IEC 10646 [ISO/IEC 10646]에 지정 된 바와 같이, 텍스트의 기초 단위이다. 올바른(legal) 글자들은 탭(tab), 리턴(enter), 줄공급(새줄 널기), 올바른 Unicode와 ISO/IEC 10646의 그래픽 글자들이다. [Unicode] 항목 6.8에서 정의된 "규격부합성(compatibility) 글자들"의 사용은 하지 않는 것이 좋다.
| 글자 범위(Character Range) |
| [2] |
Char |
::= |
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] |
/* |
Unicode 글자(대용 블럭, FFFE, FFFF 제외). */ | |
이진수(bit) 패턴으로 코드 포인트(code point) 글자 엔코딩하는 기구(mechanism)는 엔티티(entity)에 따라 서로 다르다. 모든 XML 처리자(processor)는 10646 의 UTF-8 와 UTF-16 엔코딩(encoding)을 수용하여야 한다. 이 두가지 중 어느 것이 사용되는가 신호 보내는 기구, 또는 다른 엔코딩을 가져다 쓰는 기구는 뒤 4.3.3 "엔티티의 글자 엔코딩"에서 다룬다.
여기서는 문법에서 널리 사용되는 일부 기호(symbol)들을 정의한다.
S (공백: space)은 한개 이상의 공백글자(space: #x20), 리턴(enter), 줄공급(새줄 넣기), 탭(tab)들로 구성된다.
| 공백(White Space) |
| [3] |
S |
::= |
(#x20 | #x9 | #xD | #xA)+ | |
글자들은 편이상 글자, 숫자(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) 될 수 있다는 점에 주의하라.
| 리터랄(Literals) |
| [9] |
EntityValue |
::= |
'"' ([^%&"] | PEReference | Reference)* '"' |
|
|
|
| "'" ([^%&'] | PEReference | Reference)* "'" |
| [10] |
AttValue |
::= |
'"' ([^<&"] | Reference)* '"' |
|
|
|
| "'" ([^<&'] | Reference)* "'" |
| [11] |
SystemLiteral |
::= |
('"' [^"]* '"') | ("'" [^']* "'") |
| [12] |
PubidLiteral |
::= |
'"' PubidChar* '"' | "'" (PubidChar - "'")* "'" |
| [13] |
PubidChar |
::= |
#x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%] | |
텍스트는 글자 데이터와 코드(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)인 "]]>"를 포함하지 않는, 글자들의 스트링이다.
애트리뷰트 값에 단일, 이중 따옴표들의 포함을 허용하려면, 단일 따옴 글자(')는 "'"로, 이중 따옴 글자(")는 """로 표현 할 수 있다.
| 글자 데이터(Character Data) |
| [14] |
CharData |
::= |
[^<&]* - ([^<&]* ']]>' [^<&]*) | |
문서에서 코멘트는 다른 코드(markup) 밖 어디에나 나타 날 수 있고, 또한, 문서 타입 선언(document type declaration) 안, 문법에 의하여 허용 된 장소에 나타 날 수 있다. 이들은 문서의 글자 데이터 부분이 아니다. XML 처리자(processor)는, 필요한 것은 아니지만, 적용(application)이 코멘트 텍스트를 읽게 할 수 있다. 규격부합성을 위하여, 스트링 "--"는 코멘트 속에 나타나지 말아야 한다.
| 코멘트(Comments) |
| [15] |
Comment |
::= |
'<!--' ((Char - '-') | ('-' (Char - '-')))* '-->' | |
코멘트의 예제:
<!-- <head> & <body>의 선언 --> |
처리지시(processing instruction: PI)는 문서들이 적용(application)을 위해 지시를 포함 할 수 있게 한다.
| 처리지시(Processing Instructions) |
| [16] |
PI |
::= |
'<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>' |
| [17] |
PITarget |
::= |
Name - (('X' | 'x') ('M' | 'm') ('L' | 'l')) | |
PI는 문서의 글자 데이터 부분이 아니고, 적용(application)에 전달하여야 한다. PI는 지시가 어느 적용으로 향할 것인가를 지정하는데 사용하는 목표(PITarget)로 시작한다. 목표(target) 이름 "XML", "xml" 등은 표준화나 이규격의 향후 버전 위해 예약되었다. XML 주석(notation) 기구(mechanism)가 공식적인 PI 목표 선언에 사용 될 수 있다.
CDATA 항목은 글자 데이터가 나타 날 수 있는 어디에나 나타날 수 있고, 이들은, 그렇지 않으면 코드(markup)로 인식되는, 글자들을 포함하는 텍스트 블럭을 에스케입(escape) 하는데 사용된다. CDATA 항목은 스트링 "<![CDATA["로 시작되고 스트링 "]]>"로 끝난다.
CDATA 항목 안에서는, CDEnd 스트링 만이 코드(markup)로 인식된다. 그래서 외쪽 꺽쇄(<)와 앰퍼샌드(&)들이 그 리터랄(literal) 양식 안에 나타날 수 있다; 이들은 "<"와 "&"를 사용하여 에스케입(escape) 될 필요가 없으며 될 수도 없다. CDATA 항목들은 네스트(nest) 될 수 없다.
CDATA 항목의 예제, 여기서 "<greeting>"와 "</greeting>" 사이는 코드(markup)로 인식되지 않고 글자 데이터로 인식된다:
<![CDATA[<greeting>여러분 안녕하세요!</greeting>]]> |
XML 문서들은 사용된 XML의 버전을 지정하는 XML 선언으로 시작 할 수 있으며, 시작하여야 한다. 예를 들어, 아래는 완전한 XML 문서이고, 잘 형성된 것이지만 유효(valid)하지는 않다:
<?xml version="1.0"?>
<greeting>여러분 안녕하세요!</greeting>
|
이것도 같다:
<greeting>여러분 안녕하세요!</greeting>
|
버전 번호 "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. "물리적 구조"를 참조하라.
| 문서 타입 정의(Document Type Definition) |
|
|
코드(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) 부분들이, 조건적 항목 구성을 사용하여, 조건에 따라 무시 될 수 있다; 이는 내부적 하부세트에서는 허용되지 않는다.
| 외부적 하부세트(External Subset) |
|
|
외부적 하부세트(subset)와 외부적 파라메터(parameter) 엔티티(entity)는 또한 그 안의 내부적 하부세트에서와 다른데, 파라메터 엔티티 참조는 코드(markup) 선언들 사이에서 뿐 아니라, 속에서도 허용된다.
문서 타입 선언(document type declaration)을 갖는 XML 문서 예제:
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>여러분 안녕하세요!</greeting>
|
시스템 인식자(identifier) "hello.dtd"는 문서를 위한 DTD의 URI를 제공한다.
그 선언들은 예제와 같이 지역적으로 주어 질 수 있다:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
<greeting>여러분 안녕하세요!</greeting>
|
외부적과 내부적 하부세트(subset)들이 다 사용되면, 내부적 하부세트가 외부적 하부세트보다 먼저 나온 것으로 간주된다. 내부적 하부세트에 있는 엔티티(entity)와 애트리뷰트 목록 선언들이 외부적 하부세트에 있는 것에 우선하여 작용하는 효과를 갖는다.
코드(markup) 선언들은 XML 처리자(processor)로부터 적용(application)에 전달함에 따라 문서에 내용에 영향을 줄 수 있다; 예를 들면 애트리뷰트(attribute) 디폴트들과 엔티티(entity) 선언들이다. 독립 문서 선언은 XML 선언의 부분으로 나타날 수 있으며, 문서 엔티티에 외부적으로 이와 같은 선언들이 있는가 없는가의 신호를 준다.
| 독립 문서 선언(Standalone Document Declaration) |
| [32] |
SDDecl |
::= |
S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) |
[ |
VC: 독립 문서 선언 ] | |
독립 문서 선언(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 선언의 예제:
<?xml version="1.0" standalone='yes'?> |
XML 문서들을 작성하는데, 자주 "공백"(이규격에서 비터미널 S로 표기한 공간, 탭, 빈줄)을 사용하기 위하여 변환하여, 코드를 훨신 읽기 쉽게한다. 이와 같은 공백은 전형적으로 이 문서의 버전에 포함하기 위하여 의도된 것은 아니다. 이와는 달리 "상당한" 공백이 유지되어야 하는 경우가 많이 있는데 시 문구나 소스코드가 그 예이다.
XML 처리자는 항상 문서 안의 비 코드(markup)의 모든 글자들을 적용(application)에 전달하여야 한다. 유효성 검정 XML 처리자는 또한 적용에게, 엘레멘트 내용 안에 나타나는 공백을 구성하는 이 글자들에 대한, 정보를 제공하여야 한다.
공백이 적용에서 그대로 유지되도록, 엘레멘트에 의도하는 신호를 보내기 위하여, 'xml:space'로 이름 지워진 특별한 애트리뷰트가 엘레멘트(element)에 첨부 될 수 있다. 유효한(valid) 문서들에서, 이 애트리뷰트는 다른 것과 마찬가지로, 이것이 사용되면, 선언되어야 한다. 선언되면, 값들은 디폴트("default")와 유지("preserve") 만이 가능한 숫자주기(enumerated) 타입이 되어야 한다. 예를 들어:
<!ATTLIST poem xml:space (default|preserve) 'preserve'> |
값 "default"는 적용(application)의 이 엘레멘트 디폴트 공백처리 과정이면 만족스럽다는 신호를 보내고; 값 "preserve"는 모든 공백을 그대로 유지하겠다는 의도를 적용에 알려준다. 이 선언된 의도는 내용 안 지정된 그 엘레멘트의 모든 엘레멘트들에, 다른 'xml:space' 애트리뷰트의 인스탄스로 덮어 씌우기 되지 않는 한, 적용 할 것으로 간주된다.
문서의 최상위(root) 엘레멘트는, 이 애트리뷰트의 값이 제공되거나, 애트리뷰트가 디폴트 값으로 선언되지 않는 한, 적용의 공백 처리에 의도가 없다는 신호를 받은 것으로 간주한다.
XML로 해석(parse)된 엔티티는 자주 컴퓨터 화일들로 저장된며, 편집의 편이성을 위하여, 줄(line)들로 만들어 진다. 이 줄들은 전형적으로 리턴(carriage-return: '#xD')과 줄공급(line-feed: '#xA') 글자들의 조합으로 분리된다.
적용(applications)의 임무를 단순화 하기 위하여, 내부적으로 해석(parse)된 엔티티의 외부적으로 해석된 엔티티나 리터랄(literal) 엔티티 값이 리터랄 연속 두 글자 "#xD#xA" 또는 단일 글자 "#xD"이면 언제나, XML 처리자(processor)는 적용(application)에게 단일 글자 "#xA"를 전달하여야 한다. (이 활동은, 해석 전에 정상화에 의하여 모든 줄바꿈을 입력(input)에서 "#xA"로 편리하게 생성 할 수 있다.)
문서 처리에서, 그 문서가 작성된 내용의 자연 혹은 공식 언어를 지정하는 것이 자주 유용하다. 'xml:lang'로 이름지워 진 특별 애트리뷰트가 문서에 삽입되어 내용에 사용된 언어를 지정 할 수 있고, XML 문서의 어떤 엘레멘트 애트리뷰트 값을 지정 할 수 있다. 유효한(valid) 문서들에서, 이 애트리뷰트(attribute)는 다른 것과 마찬가지로, 사용되면 선언되어야 한다. 애트리뷰트의 값들은 [IETF RFC 1766], "언어를 인식하기 위한 태그들"에 정의 된 바와 같은 언어 인식자(identifier)들이다:
| 언어의 인식(Language Identification) |
| [33] |
LanguageID |
::= |
Langcode ('-' Subcode)* |
| [34] |
Langcode |
::= |
ISO639Code | IanaCode | UserCode |
| [35] |
ISO639Code |
::= |
([a-z] | [A-Z]) ([a-z] | [A-Z]) |
| [36] |
IanaCode |
::= |
('i' | 'I') '-' ([a-z] | [A-Z])+ |
| [37] |
UserCode |
::= |
('x' | 'X') '-' ([a-z] | [A-Z])+ |
| [38] |
Subcode |
::= |
([a-z] | [A-Z])+ | |
Langcode는 아래 것 중의 하나가 될 수 있다:
- [ISO 639]의 "언어들의 이름을 나타내는 코드"에 정의된 두글자 언어 코드
- '인터넷 할당 번호 당국'[IANA](Internet Assigned Numbers Authority)에 등옥된 언어 인식자(identifier); 이는 "
i-"(또는 "I-")의 접두어로 시작된다.
- 사용자에 의하여, 혹은 개인적 사용에서 당사자끼리 합의하여 지정된 언어 인식자(identifier); 이는 IANA에 향후 표준화되거나 등록될 이름과 마찰하지 않도록 확실히 하기 위하여 접두어 "
x-" 또는 "X-" 로 시작되어야 한다.
어떤수의 하부코드(Subcode) 부분(segment)들이 있을 수 있다; 만일 하부코드가 있고 두개의 글자로 구성되어 있으면, 이는 [ISO 3166]의 "국가들의 이름을 표현하는 코드들"에서 왔을 것이며, 만일 처음 하부코드가 두개보다 많은 글자로 구성되어 있으면, Langcode가 접두어 "x-" 혹은 "X-"로 시작하지 않는 한, 이는 IANA에 등록된 언어 하부코드 일 것이다.
습관적으로 언어코드는 소문자로, 국가코드는 (있으면) 대문자로 주어진다. 이 값들은 XML 문서에서 다른 이름들과는 다르게 대소문자를 구별하지 않는다는 점에 주의하라.
예를 들어:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit hei?m Bem?'n.</l>
</sp> |
의도적으로 'xml:lang'로 선언된 것은, 그 내용 안에서 다른 엘레멘트에 'xml:lang' 인스탄스(instance)를 사용하여 덮어씌움을 하지 않는 한, 그 정의 된 엘레멘트(element)의 모든 애트리뷰트(attribute)들과 내용(content)에 적용하는 것으로 간주된다.
'xml:lang'의 간단한 선언은 아래 양식을 갖는다;
xml:lang NMTOKEN #IMPLIED |
그러나, 적정하다면, 특정 디폴트 값들이 주어 질 수도 있다. 영국 학생들에게 불어 시들의 모음에서, 설명과 주석은 영어로 할 때, 'xml:lang' 애트리뷰트는 다음과 같이 선언 될 수 있다:
<!ATTLIST poem xml:lang NMTOKEN 'fr'>
<!ATTLIST gloss xml:lang NMTOKEN 'en'>
<!ATTLIST note xml:lang NMTOKEN 'en'> |
각 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)하며, 다음 중 하나에 해당한다:
- 선언이 '
EMPTY'(빈것)와 일치하고, 엘레멘트가 내용(content)을 갖고 있지 않다.
- 선언이
자식(child)들과 일치하고, 자식 엘레멘트들의 연속이, 내용 모델(model) 안의 일반적 지정(expression)으로 생성된 언어에 소속되어 있고, 자식 엘레멘트들의 각 짝 사이에 선택적 공백(글자가 비 터미널 S와 일치하는)을 가지고 있다.
- 선언이
Mixed(혼합)와 일치하고, 그 내용이 글자 데이터와 그 타입이 내용 모델(model)의 이름과 일치하는 자식 엘레멘트들로 구성되었다.
- 선언이
ANY와 일치하고, 어떤 자식(child) 엘레멘트의 타입이 선언되었다.
빈것이 아닌 각 XML 엘레멘트(element)의 시작은 시작태그로 표시되어 있다.
시작태그와 종료태그 안에 이름(Name)이 엘레멘트(element)의 타입(type)을 지정한다. Name - AttValue의 짝들은 그 엘레멘트의 애트리뷰트 규격으로, 각 짝의 Name은 애트리뷰트 이름과 애트리뷰트 값으로 AttValue(' 또는 " 구분자들 사이의 텍스트)의 내용으로 참조된다.
잘 형성됨을 위한 필수사항: 유일 애트리뷰트 규격(Unique Att Spec)
같은 시작태그 또는 빈 엘레멘트 태그 안에서 같은 애트리뷰트(attribute) 이름이 나와서는 않된다.
유효성 제한요소: 애트리뷰트 값 타입(Attribute Value Type)
애트리뷰트는 선언되어 있어야 한다; 그 값은 이를 위한 선언된 타입이어야 한다. (애트리뷰트 타입은 3.3 "애트리뷰트 목록 선언"을 참조하라.)
잘 형성됨을 위한 필수사항: 외부적 엔티티 참조가 없어야 함(No External Entity References)
애트리뷰트 값들은 외부적 엔티티에 대한 직접적 혹은 간접적 엔티티 참조를 포함 할 수 없다.
잘 형성됨을 위한 필수사항: 애트리뷰트 값에 '<'가 없어야 함
애트리뷰트 값에서 직접적 혹은 간접적으로 참조된 엔티티(entity)의 교체 텍스트("<" 이외의)는 '<'를 포함 할 수 없다.
시작태그의 예제:
<termdef id="dt-dog" term="dog"> |
시작태그로 시작된 각 엘레멘트(element)는, 시작태그에서 주어진 엘레멘트 타입을 복사한 이름을 포함하는, 종료태그로 표시하여야 한다:
| 종료태그(End-tag) |
| [42] |
ETag |
::= |
'</' Name S? '>' | |
종료태그의 예제:
시작태그와 종료태그 사이의 텍스트를 엘레멘트의 내용이라 한다:
| 엘레멘트의 내용(Content of Elements) |
|
|
만일 엘레멘트가 비어(empty) 있으면, 이는 시작태그가 열리자 마자 종료태그가 온 것이 거나 빈 엘레멘트 태그이다. 빈 엘레멘트 태그는 특수한 양식을 갖는다:
| 빈 엘레멘트 태그(Tags for Empty Elements) |
|
|
빈 엘레멘트 태그는 내용(content)이 없는 어느 엘레멘트에도 사용 될 수 있으며, 'EMPTY' 키워드(keyword)로 선언된다. 공통사용성(interoperability)을 위하여, 빈 엘레멘트 태그가 사용되어야 하며, 'EMPTY'로 선언된 엘레멘트들에서 만 사용 될 수 있다.
빈(empty) 엘레멘트의 예제:
<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/> |
XML 문서의 엘레멘트(element) 구조는, 유효성 검정(validation) 목적으로, 엘레멘트 타입과 애트리뷰트 목록 선언들을 사용하여 제한을 줄 수 있다. 엘레멘트 타입 선언은 엘레멘트(element)의 내용(content)에 제한을 준다.
엘레멘트 타입 선언은 자주 어떤 엘레멘트 타입들이 엘레멘트의 자식(child)들에 나타날 수 있는가의 제한을 준다. 사용자의 선택으로, 선언이 되지 않은 엘레멘트 타입의 선언이 나타나면, XML 처리자(processor)는 경고를 발생 시킬 수 있는데, 이것은 오류가 아니다.
엘레멘트 타입 선언은 다음과 같은 양식을 갖는다:
| 엘레멘트 타입 선언(Element Type Declaration) |
|
|
여기서 이름(Name)은 선언되는 엘레멘트의 타입을 준다.
유효성 제한요소: 유일한 엘레멘트 타입 선언
같은 엘레멘트(element) 타입이 다시 선언 될 수 없다.
엘레멘트 타입 선언의 예제:
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY> |
엘레멘트(element) 타입(type)은, 그 타입의 엘레멘트가 자식(child) 엘레멘트들(글자 데이터는 안되고) 만을 포함하여야 하며, 선택적으로 공백(글자가 비 터미날 S와 일치)으로 분리되면, 엘레멘트 내용(content)을 갖는다. 이 경우, 내용 모델(model), 그 자식 엘레멘트들의 허용된 타입들을 관할하는 단순 문법과, 그들이 나타 날 수 있는 순서의 제한사항을 포함한다. 문법은 내용 조각(cp: content particle)에 만들며, 이는 이름, 내용 조각의 선택 목록, 또는 내용 조각(particle)들의 순서 목록들로 구성된다:
| 엘레멘트 내용 모델(Element-content Model) |
|
|
여기서 각 이름(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)가 아니어야 한다.
엘레멘트 내용 모델의 예제:
<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*> |
그 타입의 엘레멘트가 어떤 글자 데이터를 가질 수 있고, 선택적으로 자식(child) 엘레멘트(element)들에 분산되었으면, 그 엘레멘트 타입(type)은 혼합 내용을 갖는다. 이 경우, 자식 엘레멘트들의 타입은 제한 될 수 있으나, 그들의 순서나 나타나는 갯수는 제한 될 수 없다:
| 혼합 내용 선언(Mixed-content Declaration) |
|
|
여기서 이름(Name)들이 자식(child)들로 나타날 수 있는 엘레멘트 타입을 제공한다.
유효성 제한요소: 타입 중복없슴(No Duplicate Types)
같은 이름이 단일 혼합 내용 선언 안에서 나타나지 말아야 한다.
혼합 내용 선언 예제:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)> |
엘레멘트(element)의 이름과 값의 짝들을 연관시키기 위하여 애트리뷰트(attribute)들이 사용된다. 애트리뷰트 규격들은 시작태그와 빈 엘레멘트 태그들 안에 만 나타날 수 있다; 그래서, 이들을 알기 위 한 것은 3.1 "시작태그, 종료태그, 빈 엘레멘트 태그"에 기술되었다. 애트리뷰트 목록 선언들은 다음의 경우에 사용 될 수 있다:
- 주어진 엘레멘트(element) 타입의 애트리뷰트들의 설정을 지정하기 위하여
- 애트리뷰트(attribute)에 타입 제한요소를 설정하기 위하여
- 애트리뷰트에 디폴트 값들을 제공하기 위하여
애트리뷰트 목록 선언들은 주어진 엘레멘트(element) 타입에서 관련된 각 애트리뷰트(attribute)의 이름, 데이터 타입과 디폴트 값(있으면)들을 지정한다:
| 애트리뷰트 목록 선언(Attribute-list Declaration) |
|
|
AttlistDecl 코드(rule) 안의 이름(Name)은 엘레멘트(element)의 타입(type)이다. 사용자의 선택으로, 선언이 되지 않은 엘레멘트 타입의 선언이 나타나면, XML 처리자(processor)는 경고를 발생 시킬 수 있는데, 이것은 오류가 아니다. AttDef 코드(rule) 안의 이름(Name)은 애트리뷰트(attribute)의 이름이다.
주어진 엘레멘트(element) 타입에 하나 이상의 AttlistDecl이 있으면, 제공된 모든 내용들은 통합된다(merge). 주어진 엘레멘트 타입의 같은 애트리뷰트가 하나 이상 정의되었으면, 먼저 선언이 작용되고 나중 선언들은 무시된다. 공통사용성을 위하여, DTD 작성자는 주어진 엘레멘트 타입에 많아도 한개의 애트리뷰트 목록 선언을, 주어진 애트리뷰트 이름에 많아도 한개의 애트리뷰트 정의를, 그리고 각 애트리뷰트 목록 선언 안에 적어도 한개의 애트리뷰트 정의를 선택 할 수 있다. 공통사용성(interoperability)을 위하여, 주어진 엘레멘트 타입에 하나 이상의 애트리뷰트 목록 선언되었거나, 주어진 애트리뷰트에 하나 이상의 애트리뷰트 정의가 되었으면, XML 처리자(processor)는 사용자 선택으로 경고를 발생시킬 수 있고 이것은 오류가 아니다.
XML 애트리뷰트 타입들에는 세가지가 있는다: 스트링 타입, 토큰화된(tokenized) 타입들의 세트, 그리고 번호붙인(enumerated) 타입들. 스트링 타입은 그 값으로 어떠한 리터랄(literal) 스트링도 가질수 있고; 토큰화된(tokenized) 타입들은 위에서 다룬 바와 같이 여러 내용과 문법적 제한요소를 가질 수 있다:
| 애트리뷰트 타입(Attribute Types) |
|
|
유효성 제한요소: 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) 타입들이 있다:
| 번호붙여진 애트리뷰트 타입(Enumerated Attribute Types) |
|
|
NOTATION 애트리뷰트는 시스템 과/또는 공통(public) 인식자(identifier)들과 관련하여 DTD에 선언되고, 그 애트리뷰트가 첨부된 엘레멘트를 해석(interpreting)하는데 사용되는, 주석(notation)을 인식(identify)한다.
유효성 제한요소: 주석 애트리뷰트(Notation Attributes)
이 타입의 값들은 선언에 포함된 하나의 주석(notation) 이름과 일치하여야 한다; 선언의 모든 주석(notation) 이름은 선언된 것이어야 한다.
유효성 제한요소: Enumeration
이 타입의 값들은 선언에 포함된 하나의 Nmtoken 토큰(token)과 일치하여야 한다.
공통사용성(interoperability)을 위하여, 단일 엘레멘트의 번호붙인(enumerated) 애트리뷰트 타입에서 같은 Nmtoken은 나타나지 말아야 한다.
애트리뷰트 선언은 애트리뷰트(attribute)가 있을 필요성이 있는가, 아니면, 문서에 선언된 애트리뷰트가 없으면 어떻게 XML 처리자(processor)가 반응하여야 하는가의 정보를 제공한다.
| 애트리뷰트 디폴트(Attribute Defaults) |
|
|
애트리뷰트(attribute) 선언에서, #REQUIRED는 애트리뷰트가 항상 제공되어야 하고, #IMPLIED는 디폴트 값이 없는 것을 의미한다. 만일 선언이 #REQUIRED나 #IMPLIED가 아니면, AttValue 값은 선언된 디폴트 값을 갖는다; #FIXED 키워드(keyword)는 애트리뷰트가 항상 디폴트 값을 가져야 한다는 것을 기술한다. 디폴트 값이 선언되었으면, XML 처리자(processor)가 생략된 애트리뷰트를 만났을 때, 디폴트 값이 선언된 애트리뷰트가 있는 것 처럼 행동한다.
유효성 제한요소: 필요한 애트리뷰트(Required Attribute)
디폴트 선언이 키워드 #REQUIRED이면, 애트리뷰트는 애트리뷰트 목록 선언 안 그 타입의 모든 엘레멘트에 지정되어야 한다.
유효성 제한요소: 유효한 애트리뷰트 디폴트(Attribute Default Legal)
선언된 디폴트 값은 선언된 애트리뷰트 타입의 제한요소을 만족시켜야 한다.
유효성 제한요소: 고정된 애트리뷰트 디폴트(Fixed Attribute Default)
만일 애트리뷰트가 #FIXED 키워드로 선언된 디폴트 값을 가지고 있으면, 애트리뷰트의 인스탄스(instance)는 그 디폴트 값과 일치하여야 한다.
애트리뷰트 목록 선언 예제:
<!ATTLIST termdef
id ID #REQUIRED
name CDATA #IMPLIED>
<!ATTLIST list
type (bullets|ordered|glossary) "ordered">
<!ATTLIST form
method CDATA #FIXED "POST"> |
애트리뷰트(attribute) 값이 적용(application)에 전달되거나 유효성이 점검되기 전에, XML 처리자(processor)는 아래와 같이 정상화 하여야 한다:
- 참조된 글자를 애트리뷰트 값에 첨부 함으로서 글자 참조가 처리된다.
- 반복적으로 엔티티(entity)의 교체 텍스트를 가공 함으로서 엔티티 참조가 처리된다.
- 외부적으로 해석(parse)된 엔티티의 부분, 또는 내부적으로 해석된 엔티티의 리터랄(literal) 엔티티 값인 "#xD#xA" 연속에 단일 '#x20' 만이 추가된다는 것 제외하고는, 공백 글자(#x20, #xD, #xA, #x9)는 정상화 된(normalized) 값에 '#x20'를 추가 함으로서 처리된다.
- 다른 글자들은 그것에 정상화된 값이 첨부 됨으로서 처리된다
만일 그 선언된 값이 CDATA 가 아니면, XML 처리자(processor)는, 맨 앞과 뒤의 공백(#x20) 글자들을 제거하고, 연속 공백(#x20) 글자들을 단일 공백(#x20) 글자로 교체하는, 추가적인 애트리뷰트 값의 정상화 과정을 거쳐야 한다.
선언이 없는 모든 애트리뷰트들은 유효성을 검정 않는 해석자(parser)에 의하여 CDATA가 선언된 것 처럼 취급 되어야 한다.
조건부 항목(conditional section)은, 그들을 다루는 키워드(keyword)에 기초한 DTD의 논리적 구조에 포함되거나 제외된, 문서 타입 선언 외부적 하부세트의 부분들이다.
| 조건부 항목(Conditional Section) |
|
|
내부적과 외부적 DTD 하부세트(subset)들과 마찬가지로, 조건부 항목(conditional section)은 한개 혹은 그 이상의 완전한 선언, 코멘트, 처리지시(processing instruction) 또는 네스트(nest) 된 조건부 항목들, 공백과 혼합들을 포함 할 수 있다.
만일 조건부 항목의 키워드(keyword)가 INCLUDE이면, 조건부 항목의 내용(content)은 DTD의 부분이다. 조건부 항목의 키워드가 IGNORE이면, 조건부 항목의 내용은 논리적으로 DTD의 부분이 아니다. 올바른 해석(parsing)을 위하여, 조건부 항목들의 네스트를 알아내고, (무시된) 조건부 항목의 감지된 가장 밖의 끝을 확인하기 위하여, 무시된 조건부 항목의 내용들 까지도 읽어야 한다는 점에 주의하라. 만일 조건부 항목이 키워드 INCLUDE가, 키워드 IGNORE를 갖는 더 큰 조건부 항목 안에 나타나면, 외부와 내부 조건부 항목들이 둘 다 무시된다.
만일 조건부 항목의 키워드가 파라메터(parameter) 엔티티를 참조이면, 처리자(processor)가 그 조건부 항목(conditional section)을 포함 할 것인가 무시 할 것인가를 결정하기 전에, 파라메터 엔티티는 그 내용(content)으로 대체되어야 한다.
예제:
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>
|
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)들을 차지한다; 같은 이름의 파라메터 엔티티와 일반 엔티티는 서로 다른 엔티티들이다.
글자 참조는 ISO/IEC 10646 글자 세트의 특정 글자를 참조한다. 예를 들면 입력장치들에서 직접적으로 사용 할 수 없는 글자를 참조하는 것이다.
| 글자 참조(Character Reference) |
| [66] |
CharRef |
::= |
'&#' [0-9]+ ';' |
|
|
|
| '&#x' [0-9a-fA-F]+ ';' |
[ |
WFC: 올바른(legal) 글자 ] | |
잘 형성됨을 위한 필수사항: 올바른(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 안에 만 나타날 수 있다.
글자와 엔티티 참조 예제:
Type <key>less-than</key> (<) to save options.
This document was prepared on &docdate; and
is classified &security-level;. |
파라메터(parameter) 엔티티(entity) 참조 예제:
<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2; |
엔티티(entity)들은 다음과 같이 선언된다:
| 엔티티 선언(Entity Declaration) |
|
|
Name은 엔티티 참조에 있는 엔티티, 또는, 해석(parse) 안된 엔티티(entity)의 경우, ENTITY 혹은 ENTITIES 애트리뷰트 값을 인식(identify)한다. 만일 같은 엔티티가 한번 이상 선언되었으면, 먼저 만난 선언이 적용된다; 사용자 선택으로, XML 처리자(processor)는 만일 엔티티(entity) 여러번 선언되었으면 경고를 발생시킬 수 있다.
만일 엔티티 정의가 EntityValue이면, 그 정의된 엔티티(entity)를 내부적 엔티티라 부른다. 별도의 물리적 저장 오브젝트(object)가 있지 않고, 엔티티 내용(content)은 선언에 주어진다. 일부 리터랄(literal) 엔티티 값의 엔티티와 글자 참조 처리는 올바른 교체 텍스트를 만드는데 필요 할 수 있다는 점에 유의하라: 4.5 "내부적 엔티티 교체 텍스트의 구성"을 참고하라.
하나의 내부적 엔티티는 해석(parse)된 엔티티(entity)이다.
내부적 엔티티 선언 예제:
<!ENTITY Pub-Status "This is a pre-release of the
specificaion."> |
만일 엔티티(entity)가 내부적이 아니면, 아래와 같이 선언된 외부적 엔티티이다:
| 외부적 엔티티 선언(External Entity Declaration) |
|
|
만일 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)되어야 한다.
외부적 엔티티 선언 예제:
<!ENTITY open-hatch
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif > |
외부적 해석(parse)된 엔티티(entity)는 각각 텍스트 선언으로 시작 될 수 있다.
텍스트 선언은 해석된 엔티티를 참조하는 것이 아니라 리터랄(literal)로 제공되어야 한다. 텍스트 선언은 외부적 해석(parse)된 엔티티의 시작 부분 이외의 위치에는 나올 수 없다.
문서 엔티티는, 이것이 라벨된(labeled) document의 생성물과 일치하면, 잘 형성된 것이다. 외부적 일반적(general) 해석(parse)된 엔티티는, 이것이 라벨된 extParsedEnt의 생성물과 일치하면, 잘 형성된 것이 된다. 외부적 파라메터(parameter) 엔티티는, 이것이 라벨된 extPE의 생성물과 일치하면, 잘 형성된 것이 된다.
| 잘 형성된 외부적 해석된 엔티티(Well-Formed External Parsed Entity) |
|
|
내부적 일반적(general) 해석(parse)된 엔티티(entity)는, 그의 교체 텍스트가 라벨된 내용(content)의 생성물과 일치하면, 잘 형성된 것이 된다. 모든 내부적 파라메터(parameter) 엔티티는 정의에 의해 잘 형성된 것이 된다.
엔티티가 잘 형성되었다는 것은 XML 문서의 논리적, 물리적 구조가 적정하게 네스트(nest)되었다는 것이다; 시작태그, 종료태그, 빈 엘레멘트 태그, 엘레멘트(element), 코멘트(comment), 처리지시(processing instruction), 글자 참조, 또는 엔티티 참조가 한 엔티티에서 시작되고 다른 것에서 종료 될 수 없다는 것이다.
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 Declaration) |
| [80] |
EncodingDecl |
::= |
S 'encoding' Eq ('"' EncName '"' | "'" EncName "'" ) |
| [81] |
EncName |
::= |
[A-Za-z] ([A-Za-z0-9._] | '-')* |
/* |
Latin 글자들 만 갖는 엔코딩 이름*/ | |
문서 엔티티에서, 엔코딩(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 처리자가 처리 할 수 없는 엔코딩이 있는 엔티티를 만나면 이것은 치명적 오류이다.
엔코딩 선언 예제:
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?> |
아래 테이블은 글자 참조, 엔티티 참조, 해석 안된 엔티티가 나타나면 조치와 각 경우 XML 처리자가 취해야 할 행위등의 문맥들을 요약한 것이다. 가장 왼쪽 컬럼의 라벨은 알려진 문맥을 기술하였다:
- 내용(content) 참조
- 엘레멘트의 시작태그 후 종료태그 전 어디에서나 참조; 비 터미날
content에 해당.
- 애트리뷰트 값의 참조
- 시작태그 안의 애트리뷰트(attribute) 값, 또는 애트리뷰트 선언의 디폴트 값을 참조; 비 터미날
AttValue에 해당.
- 애트리뷰트 값으로 나타남
- 참조가 아니라,
Name으로 타입이 ENTITY로 선언된 애트리뷰트(attribute)의 값으로 또는 타입이 ENTITIES로 선언된 애트리뷰트(attribute)의 값으로 하나의 공간으로 분리된 토큰(token)들로 나타나는 것.
- 엔티티(entity) 값 참조
- 파라메터(parameter) 또는 엔티티(entity)의 선언에서 내부적 엔티티의 리터랄(literal) 엔티티 값으로 참조; 비 터미날(nonterminal)
EntityValue에 해당.
- DTD 참조
- 내부적 또는 DTD의 외부적 하부세트(subset)들에서 참조, 그러나
EntityValue 또는 AttValue의 외부.
DTD 외부에서, % 글자는 특별한 의미를 갖지 못한다; 그래서, DTD에서 참조하는 파라메터(parameter) 엔티티(entity)를 content 안에 코드(markup)로 인식하지 못한다. 이와 유사하게, 적정하게 선언된 애트리뷰트(attribute)의 값으로 나타나지 않는 한, 해석(parse) 안된 엔티티 이름들이 인식되지 못한다.
엔티티(entity)가, 참조가 인식된 장소에서 그 문서의 일부분인 것 처럼 참조 그 자리에서, 그 교체 텍스트가 읽혀지고 처리되면, 포함된다. 교체 텍스트는 글자 데이터와 (파라메터 엔티티 제외) 코드(markup)를 포함 할 수 있다. 여기서 코드는, 사용된 엔티티(entity)들의 교체 텍스트가 코드 구분자들(엔티티 amp, lt, gt, apos, quot)로 에스케입(escape)하는 경우를 제외하고는 항상 데이터로 처리된다는 것 이외에는, 보통 방식으로 인식되어야 한다. (스트링 "AT&T;"는 "AT&T;"로 확장되고, 나머지 앰퍼샌드는 엔티티-참조 구분자로 인식하지 못한다.) 한 글자 참조는 지정된 글자가 그 참조 자체의 자리에서 처리되면 포함된 것이다.
XML 처리자(processor)가 해석(parse)된 엔티티(entity) 참조를 인식하면, 그 문서의 유효성 검정(validate)을 위하여, 처리자는 그 교체 텍스트를 포함(include)하여야 한다. 만일 엔티티가 외부적이고, 처리자가 XML 문서 유효성 검정을 시도하지 않으면, 그 처리자(processor)는, 필요사항은 아니지만, 엔티티(entity)의 교체 텍스트를 포함 할 수 있다. 만일 유효성 검정하지 않는 해석자(parser)가 교체 텍스트를 포함하지 않으면, 적용(application)에게 인식된 엔티티를 알려 주어야 하지만, 읽지는 않는다.
이 규칙은, 자동 포함이 SGML에 의하여 제공되고, XML 엔티티 기구(mechanism)가 원천적으로 편집의 모듈성을 지원하기 위하여 설계되고, 다른 적용들(구체적인 예로 문서 브라우징)에 적당하지 않을 수 있다는, 인식을 기초로 한 것이다. 예를 들어, 외부적 해석(parse)된 엔티티 참조를 만나면, 브라우저들은, 엔티티의 존재를 보이고, 읽어, 요구에 의해서 만 디스플레이하는, 선택을 할 수 있다.
아래는 금지된 사항들이고 치명적(fatal) 오류들을 구성한다:
애트리뷰트 값에 엔티티 참조가 나타나거나, 리터랄(literal) 엔티티 값에 파라메터(parameter) 엔티티 참조가 나타나면, 교체 텍스트 안의 단일 또는 이중 따옴표 글자는 항상 정상 데이터 글자로 처리되고, 리터랄을 종료시키지 않는다는 것을 제외하고는, 그 교체 텍스트가 그 문서의 부분인 것 처럼 인식된 참조의 위치에서 처리된다:
잘 형성된 예제:
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said &YN;" > |
그렇지 않은 예제:
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;> |
해석(parse) 안된 엔티티(entity)의 이름이 선언된 타입 ENTITY 또는 ENTITIES의 애트리뷰트(attribute) 값에 토큰(token)으로 나타나면, 유효성 검정 처리자(processor)는 시스템(system) 적용(application)과 공통(public: 있으면) 인식자(identifier)들에게, 엔티티와 그 관련된 주석(notation)을 알려 주어야 한다.
엔티티 선언에서 EntityValue에 일반 엔티티 참조가 나타나면, 그대로 놔두고 통과한다.
외부적 해석(parse)된 엔티티에서와 마찬가지로, 파라메터(parameter) 엔티티(entity)는 포함된 if 유효성 검정을 할 때 만 필요하다. DTD에서 파라메터 엔티티 참조가 인식되고, 포함되면, 그 교체 텍스트는 앞과 뒤에 각 한개의 공백(#x20) 글자를 첨부하여 확장된다; 그 의도는 파라메터(parameter) 엔티티(entity)의 교체 텍스트에 DTD 문법적 정수 수치 토큰을 방지하기 위한 것이다.
내부적 엔티티의 처리를 다루는데, 두가지 양식의 엔티티 값들을 구별하는 것이 유용하다. 리터랄(literal) 엔티티 값은 엔티티(entity) 선언에서 실제적으로 따옴표 안의 스트링으로 비 터미날 EntityValue에 해당한다. 교체 텍스트는, 글자 참조와 파라메터 엔티티 참조 교체(replacement) 이후에는, 엔티티의 내용이다.
내부적 엔티티 선언에서(EntityValue) 주어진 리터랄(literal) 엔티티 값은 글자, 파라메터(parameter) 엔티티와 일반 엔티티 참조들을 포함 할 수 있다. 이와같은 참조는 완전히 리터랄 엔티티(entity) 값 안에 포함되어야 한다. 위에 설명된 바와 같은 포함된 실제적인 교체 텍스트는 참조된 파라메터(parameter) 엔티티의 교체 텍스트를 포함하여야 하며, 참조된 글자 리터랄 엔티티 값 안에 참조하는 글자 참조를 포함하여야 한다; 그러나, 일반 엔티티 참조는 확장 안된 상태로 그대로 있어야 한다. 예를 들어, 아래 선언을 보자:
<!ENTITY % pub "Éditions Gallimard" >
<!ENTITY rights "All rights reserved" >
<!ENTITY book "La Peste: Albert Camus,
© 1947 %pub;. &rights;" > |
엔티티 교체 텍스트 "book"은:
La Peste: Albert Camus,
?nbsp;1947 ?itions Gallimard. &rights; |
일반 엔티티(entity) 참조 "&rights;"는, 문서의 내용(content) 또는 애트리뷰트 값에 나타나는 "&book;"의 참조로, 확장 될 것이다.
이들 단순한 규칙들은 복합 작용들을 할 수 있다; 어려운 예제의 자세한 사항은 D. "엔티티와 글자 참조의 확장(expansion)"을 보라.
엔티티와 글자 참조는 둘 다 왼쪽 꺽쇄(<), 앰퍼샌드(&)와 다른 구분자(delimiter)들을 에스케입(escape)하여 사용 될 수 있다. 일련의 일반(general) 엔티티(amp, lt, gt, apos, quot)는 이와같은 목적으로 지정되었다. 숫치(numeric) 글자 참조도 사용 될 수 있다; 이들은 인식되는 즉시 확장되고, 글자 데이터로 취급되어야 한다. 그리서 숫치 글자 참조 "<"와 "&"는 글자 데이터에 나타나면 '<'와 '&'를 에스테입(escape)하여 사용 될 수 있다.
모든 XML 처리자(processor)들은 이들 엔티티(entity)들이 선언된 것인가 아닌가를 인식하여야 한다. 공통사용성(interoperability)을 위하여, 유효한(valid) XML 문서들은 이들 엔티티(entity)들이, 다른 것들과 마찬가지로 사용 전에, 선언되어야 한다 문제의 엔티티가 선언되면, 아래 설명과 같이, 그것들은, 그의 교체 텍스트가 에스게입 된 단일 글자이거나 그 글자의 글자 참조인, 내부적 엔티티로 선언되어야 한다.
<!ENTITY lt "&#60;">
<!ENTITY gt ">">
<!ENTITY amp "&#38;">
<!ENTITY apos "'">
<!ENTITY quot """>
|
"lt"와 "amp"의 선언에서 "<"와 "&" 글자들은, 그 엔티티 대체(replacement)가 잘 형성된 것이 되게 하는데 필요 한, 이중(double)으로 에스케입(escaped) 되었슴에 주의하라.
주석들은, 주석(notation) 애트리뷰트, 또는 처리지시(processing instruction)가 보내지는 적용(application)을 갖는, 엘레멘트들의 해석(parse) 안된 엔티티 양식 이름으로 인식(identify)한다.
주석 선언들은, 엔티티(entity)와 애트리뷰트 목록 선언들과 애트리뷰트 규격들의 사용을 위하여, 주석에 이름을 제공한다. 그리고, XML 처리자(processor)에게 허용하는 주석 또는 주어진 주석에서 데이터 처리를 가능하게 하는 도움 적용을 위치시키는 크라이언트(client: 고객) 적용(application)을 위하여, 외부적 인식자(identifier)를 제공한다.
| 주석 선언(Notation Declarations) |
|
|
XML 처리자(processor)는 적용(application)에 이름과, 애트리뷰트 값, 애트리뷰트(attribute) 정의, 또는 엔티티(entity) 선언에서, 선언되고 참조되는 어떤 주석(notation)의 외부적 인식자(identifier)를 제공하여야 한다. 이들은 추가적으로 외부적 인식자를 시스템 인식자로, 화일 이름으로, 또는 설명된 주석 안의 데이터 처리자를 호출하는 적용을 허용하는데 필요한 다른 정보들을 해결(산출) 할 수 있다. (그러나, XML 문서에서 선언하고, 주석에서 조회하는 XML 처리자(processor) 또는 적용이 작동하고 있는 시스템에 주석 특정 적용(notation-specific application)들이 없다며, 이것은 오류는 아니다.)
문서 엔티티는 엔티티 계통도(tree)에서 최상위(root)로 작용하고, XML 처리자(processor)의 시작점이다. 이규격은 XML 처리자에 의하여 어떻게 문서 엔티티 위치되는가를 정의하고 있지 않다; 다른 엔티티들과는 달리, 문서(document) 엔티티는 이름을 갖고 있지 않고, 지정(인식)이 전혀 없어도 처리자 입력(input) 흐름이 잘 나타날 수 있다.
규격에 부합하는 XML 처리자(processor)들은 유효성 검정하는 처리자와 유효성 검정 않는 처리자 두가지 종류 중에 하나이다.
유효성 검정하는 처리자와 유효성 검정 않는 처리자들은 둘 다, 문서 엔티티의 내용과 그가 읽는 다른 해석(parse)된 엔티티들에서, 이규격의 잘 형성됨을 위한 필수사항 위반을 알려주어야 한다.
유효성 검정 처리자들은 DTD에 선언들로 나타낸 제한요소의 위반과, 이규격의 주어진 유효성 검정(validity) 제한요소를 만족시키지 못하는 겻을 알려 주어야 한다. 이를 달성하기 위하여, 유효성 검정 XML 처리자(processor)들은, 전체 DTD와 문서의 모든 참조된 외부적 해석(parse)된 엔티티를 읽고 처리하여야 한다.
유효성 검정 않는 처리자들은 전체 내부적 DTD 하부세트(subset)를 포함하여 문서 엔티티 만 그의 잘 형성됨을 검사하는 것이 필요하다. 그들은 문서의 유효성(validity) 검사가 필요하지 않지만, 내부적 DTD 하부세트와 파라메터(parameter) 엔티티에서 읽은 모든 선언을, 읽지 않은 처음 파라메터 엔티티(entity)를 참조하는데 까지, 처리(process)하는 것은 필요하다; 다시말해, 이것들은, 애트리뷰트 값들을 정상화(normalize)하고, 내부적 엔티티의 교체 텍스트를 포함(include)하고, 디폴트 애트리뷰트 값들을 제공하기 위하여, 선언들에 있는 정보를 사용하여야 한다. 이것들은 엔티티 선언들이나 읽지 않은 파라메터(parameter) 엔티티(entity) 참조 다음에 만나는 애트리뷰트 목록 선언들을 처리(process)하지 말아야 한다. 이는 그 엔티티에는 덮어씌우는 선언들을 포함 할 수 있기 때문이다.
유효성 검정 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 처리자들을 사용하지 말아야 한다.
이규격에서 간단한 양식(EBNF: Extended Backus-Naur Form)의 주석(notation)을 사용하여 XML의 공식적인 문법이 주어진다. 문법의 각 규칙은 아래와 같은 양식의 부호로 정의되었다.
symbol ::= expression |
부호 ::= 공식(표현) |
부호(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) 스트링에 일치하는.
이 부호(symbol)들은 결합되어 다음과 같이 더 복잡하게 일치할 수 있다. 여기서
A와
B는 간단한 공식(expression)을 말한다:
- (
expression)
- 공식(
expression: 표현)은 하나의 단위 취급되고, 이 목록에서 설명하는 바와 같이 결합 될 수 있다.
A?
- 선택적
A; A 또는 없는것과 일치한다.
A B
A 다음에 바로 B가 오는 것과 일치한다.
A | B
A 또는 B이나 둘 다는 아니다와 일치하다.
A - B
A는 같고 B는 갖지 않은 아무 스트링에서나 일치한다.
A+
A가 한번 혹은 그이상 나타나면 일치한다.
A*
A가 한번도 없던가 그이상 있으면 일치한다.
생성(production)에 사용된 다른 주석(notation)들은 다음과 같다:
/* ... */
- 코멘트(comment).
[ wfc: ... ]
- 잘 형성됨을 위한 필수사항(well-formed constraint); 이는 이름으로, 관련된 생성 문서들의 잘 형성됨의 제한요소를 가리킨다.
[ vc: ... ]
- 유효성 제한요소(valid constraint); 이는 이름으로, 관련된 생성 문서들의 유효성(valid)의 제한요소를 가리킨다.
부록
- 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.
- 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.
다음 유니코드(Unicode) 표준에 정의된 특징들 글자은 분류되어있다. 기초(base) 글자(다른것들 보다 이들은 영어(Latin)의 알파베트 글자들을 포함하고, 구분글자(diacritics)는 제외된다), 표식글자(ideographic) 글자, 그리고 결합(combining) 글자들(무엇보다 이 분류는 대부분의 구분글자(diacritics)을 포함)로 ; 이들 분류는 결합하여 글자들의 분류를 만든다. 숫자와 확장자(extender)들도 구별하였다.
| 글자들(Characters) |
| [84] |
Letter |
::= |
BaseChar | Ideographic |
| [85] |
BaseChar |
::= |
[#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3] |
| [86] |
Ideographic |
::= |
[#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029] |
| [87] |
CombiningChar |
::= |
[#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D | [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 | #x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] | #x3099 | #x309A |
| [88] |
Digit |
::= |
[#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-#x0ED9] | [#x0F20-#x0F29] |
| [89] |
Extender |
::= |
#x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 | #x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE] | |
여기에 정의된 글자 분류는 다음과 같이 유니코드(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은 그는 정규적으로 동일함으로.
- ':' 와 '_' 글자들은 이름 시작 글자들에 허용된다.
- '-' 와 '.'글자들은 이름 글자들에 허용된다.
XML은 SGML의 하부세트(subset)가 되도록 설계되었고, 여기서 각 유효한(valid) XML 문서는 SGML 문서에도 맞아야 한다. SGML에서와 달리 XML이 문서들에 추가적으로 제한 한 상세 비교는 [Clark]을 참조하라.
이 부록은, 4.4 "XML 처리자의 엔티티와 참조의 처리"에 설명 한 바와 같이, 엔티티(entity)- 와 글자-참조의 인식(recognition)과 확장(expansion)의 순서를 설명하는 일부 예제들을 포함하고 있다.
선언이 DTD를 포함하려면
<!ENTITY example "<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;).</p>" >
|
그러면, 엔티티(entity) 선언이 해석(parse)되면 XML 처리자(processor)는 그 글자 참조를 인식 할 것이고, 이를 해결(resolve)하여 엔티티 "example"의 값으로 아래 스트링을 저장한다:
<p>An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).</p>
|
문서에서 "&example;"을 참조하면 텍스트는 다시 해석(reparse)되고, 이때에는 "p" 엘레멘트의 시작태그와 종료태그가 인식 될 것이고, 세개의 참조들은 인식되고 확장(expand)되어, "p" 엘레멘트(element)는 아래 내용(content)을 가질 것이다(모든 데이터는 있으나 구분자나 코드는 없는):
An ampersand (&) may be escaped
numerically (&) or with a general entity
(&).
|
더 복잡한 예제는 코드(rule)와 그 효과를 완전히 설명 할 것이다. 아래 예제에서, 줄 번호는 오직 참고 만를 위한 것이다.
1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '%zz;'>
5 <!ENTITY % zz '<!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>이 sample shows a &tricky; method.</test>
|
이는 아래의 결과를 만든다:
- 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."가 된다.
규격부합성(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] 참조.
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 추천안들은 이 규칙들을 적용하지 말아야 한다.
이규격은 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의 문서 사용을 위한 법를적 문제는 원문을 참조하라.
번역자는 이 번역문에 대한 직, 간접적인 일체의 책임을 지지 않는다.
