 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Document | ||||
|
문서의 양식을 갖추어야 한다는 말은 다음의 의미를 포함한다.
- 하나 또는 그 이상의 엘리먼트들을 포함하고 있다.
- 루트 또는 문서 엘리먼트라 불리는 엘리먼트가 정확히 하나 존재하며 그
엘리먼트의 어느 부분도 다른 엘리먼트의 내용에
포함돼서는 안된다. 그 밖의 모든 엘리먼트들의 경우, 시작 태그가 다른 엘리먼트의 내용 안에 있을 경우 종료 태그 역시 같은
엘리먼트의 내용 안에 있다. 보다 간단히 말하면 시작 태그와 종료 태그에 의해 범위가 한정되는 엘리먼트들은 각각의 내부에서
올바르게 중첩된다.
2.2 문자들
파싱된 엔터티는 문자들의 연속체인 텍스트를 포함하는데 텍스트는 마크업 이나 문자데이터를 나타낸다. 문자란 ISO/IEC 10646 [ISO 10646]에 정의된대로 텍스트의 최소 단위를 말한다. 인정되는 문자들은 탭, 커서 맨앞으로 옮기기, 줄바꿈, 그리고 Unicode 와 ISO/IEC 10646에서 인정하는 문자기호들이다. [Unicode]의 6.8에 정의된 대로 '호환성 문자들'을 사용하는 것은 권장할 만한 일이 못된다.| Character Range | ||||||
|
문자코드를 비트 패턴으로 코딩하는 메커니즘은 엔터디마다 다르다. 모든 XML프로세서는 10646의UTF-8와 UTF-16 인코딩을 수용해야 한다. 둘 둥 어느 것이 사용되고 있는지를 신호해 주거나 다른 인코딩을 작동하게 하는 메커니즘은 뒤쪽의 "4.3.3 엔터티에서 문자 인코딩"에서 논의된다.
2.3 일반적인 문법 구성
이 섹션에서는 문법에서 널리 쓰이는 몇몇 기호들의 정의한다.S (여백)는 하나 또는 하나 이상의 스페이스(#x20) 문자, 커서 맨앞으로 이동, 줄바꿈, 또는 탭으로 구성된다.
| White Space | ||||
|
문자들은 편의상 글자, 숫자, 기타 문자로 분류된다. 글자들은 하나 또는 하나 이상의 철자들이 모여 글자를 이루는 표음문자나 표의문자들로 이루어진다. 각 클래스의 특정 문자에 대한 상세한 정의는 "부록B : 문자 클래스"에 나와 있다.
이름(Name)은 글자 하나 또는 몇 개의 구두점중 하나로 시작해 이름 문자들(name characters)로 불려지는 글자들, 숫자, 하이픈, 밑줄, 콜론, 또는 종지부 등으로 계속되는 토큰이다. 문자열 xml 또는 어떤 문자열이든 일치하는(('X'|'x') ('M'|'m') ('L'|'l')) 것으로 시작하는 이름들은 이 스펙의 이번 버전 또는 다음 버전에서 표준화될 것이다.
주의 : XML 이름 내부에서 콜론은 name space들의 실험을 위한 것이다. 정확한 의미는 미래의 어느 시점에서 표준화 될 것으로 기대되며 그 시점에서 시험적으로 콜론을 사용한 문서들은 업데이트되어야 할 지도 모른다. (XML에 채택된 name space 메커니즘이 실제로 name-space 범위지정자로 콜론을 쓸 것이란 보장은 없다). 이것은 실질적으로 XML 문서를 만드는 사람들이 name-space 실험의 일부로서가 아니면 XML 이름들에 콜론을 사용해선 안된다는 것을, 그러나 XML 프로세서들은 콜론을 이름 문자로 받아들여야 한다는 것을 의미한다.
Nmtoken (name token)은 이름 문자들의 혼합이다.
| Names and Tokens | ||||||||||||||||||||
|
글자 데이터는 작은 따옴표 안의 문자열이며 그 문자열의 범위지정자로 쓰이는 인용부호는 포함하지 않는다. 글자들은 내부 엔터티들의 내용(Entity Value), 속성들의 가치(AttValue), 외부 식별자(Systemliteral)을 기술하는데 사용된다. SystemLiteral은 마크업에 대한 상세한 분석없이도 파싱될 수 있다는 점을 주목할 것.
| Literals | ||||||||||||||||||||||||||||
|
2.4 문자데이터와 마크업
텍스트는 혼합된 문자데이터와 마크업으로 이루어진다. 마크업은 시작 태그, 종료 태그, 비어있는 엘리먼트 태그, 엔터티 참조, 문자 참조, 주석, CDATA 섹션 범위지정자, 문서 형 선언, 처리명령어의 형태를 띤다.마크업이 아닌 모든 텍스트는 문서의 문자데이터를 구성한다.
앰퍼샌드 문자(&)와 왼쪽 꺾쇠(<)는 마크업 범위지정자로 사용될 때만, 또는 주석, 처리명령어, 또는 CDATA섹션 안에서 사용될 때만 문자 형태로 나타날 수 있다. 그것들은 또한 내부 엔터티 선언의 문자 엔터티 값 안에서 유효성을 갖는다.이것에 관해서는 "4.3.2 : 잘 구성된 파싱된 엔터티"를 참고할 것. 만약 그것들을 다른 곳에 써야할 필요가 있을 때는 숫자로 된 문자 참조로 대신하거나 각각 "&"나 "<" 같은 문자열을 사용해 문자 형태로의 사용을 피해야 한다. 오른쪽 꺾쇠(>)는 ">"로 표현될 수 있으며, 오른쪽 꺾쇠가 내용중 "]]>" 문자열에 사용되는 경우, 즉 그 문자열이 CDATA 섹션의 끝을 나타내는 것이 아닐 경우, 호환성을 위해 반드시 ">" 혹은 문자 참조를 사용해 문자 형태로의 사용을 피해야 한다.
엘리먼트들의 내용중 문자데이터는 어떤 마크업의 시작 범위지정자를 포함하지 않는 문자열을 말한다. CDATA섹션에서 문자 데이터는 CDATA 섹션 종료 범위지정자( "]]>" )를 포함하지 않는 문자열을 말한다.
속성값이 작은 따옴표와 큰따옴표를 모두 포함하도록 하려면 어퍼스트로피 혹은 작은따옴표(')는 "'"로 큰따옴표(")는 """로 표현해야 한다.
| Character Data | ||||
|
2.5 주석
주석은 다른 마크업 외부라면 문서 내 어디에서나 나타날 수 있으며 또한 문서 형 선언 안에서 문법적으로 허용된 장소에 나타날 수도 있다. 주석은 문서가 갖는 문자 데이터의 일부분이 아니다. XML 프로세서는 어플리케이션이 주석의 텍스트를 검색하는 것을 가능하게 할 수도 있지만 반드시 그래야 하는 것은 아니다. 호환성을 위해 더블 하이픈("- -") 문자열이 주석 안에 있으면 안된다.| Comments | ||||
|
주석의 한 예이다.
<!-- declarations for <head> & <body> --> |
2.6 처리 명령어
처리 명령어 (PIs)는 문서에 어플리케이션을 위한 명령어를 포함하기 위한 것이다.| Processing Instructions | ||||||||
|
PIs는 문서가 갖는 문자 데이터의 일부는 아니지만 반드시 어플리케이션으로 전달되어야 한다. PI는 명령어가 전달되어야 할 어플리케이션을 인식하기 위해 사용되는 타겟(PITarget)으로 시작한다. "XML" "xml"같은 타겟 이름들의 표준화는 이 스펙의 이번 버전 또는 앞으로 나올 버전의 일로 남겨졌다. XML 표기법 메커니즘을 PI 타켓들의 정식 선언을 위해 사용하 수 있다.
2.7 CDATA 섹션
CDATA 섹션은 문자데이터가 나타날 수 있는 곳이면 어디에서나 나타날 수 있다. CDATA섹션은 문자를 담고 있는 텍스트가 뭉치는 것을 피하기 위해 사용하는데, 뭉치게 되면 텍스트는 마크업으로 인식될 것이다. CDATA섹션은 "<![CDATA[" 로 시작해서 "]]>": 로 끝난다.| CDATA Sections | ||||||||||||||||
|
CDATA 섹션 안에서는 CDEnd 문자열만이 마크업으로 인식되며 따라서 왼쪽 꺾쇠나 앰퍼샌드도 문자 형태로 사용할 수 있다. 즉 "<" 나 "&" 를 대신 사용할 필요가 없으며 사용할 수 없다는 말이다. CDATA 섹션은 중첩을 허용하지 않는다.
"<greeting>" 와 "</greeting>" 가 마크업이 아니라 문자 데이터로 인식되는 CDATA의 한 예이다.
<![CDATA[<greeting>Hello, world!</greeting>]]> |
2.8 도입부 문서 형 선언
XML 문서들은 문서가 준하고 있는 XML의 버전을 알려주는 XML 선언으로 시작하거나 시작해야 한다. 다음은 완전한 XML 문서의 예인데 잘 구성된 문서이긴 하지만 유효한 문서는 아니다.<?xml version="1.0"?> |
다음도 마찬가지다.
<greeting>Hello, world!</greeting> |
XML 스펙 1.0 버전의 규약에 합치한다는 것을 나타내기 위해서는 1.0이라는 버전 번호를 사용해야만 한다. 문서가 XML 스펙의 1.0 버전을 따르고 있지 않은데도 1.0이란 숫자를 사용하는 것은 오류다. 이 스펙의 차후 버전에 1.0이 아닌 숫자들을 주려는 것이 XML 워킹 그룹의 생각이다. 그러나 이런 생각이 XML 차기 버전을 반드시 발표하겠다는 것을 의미하거나 현재 작업중이라는 것을 의미하지는 않는다. 차후 버전들을 배제하는 것이 아니므로 이번 버전은 상황이 된다면 자동인식 버전이 될 가능성이 있다. 프로세서들은 지원하지 않는 버전 라벨이 붙은 문서를 받았을 때 오류 신호를 보낼 수도 있다.
XML 문서에서 마크업의 기능은 문서의 저장 구조와 논리 구조를 기술하고 속성-값 짝을 그 구조와 연관시키는 것이다. XML은 논리 구조에 관한 규약ㅇ르 정의하고 미리 정의된 저장 단위의 사용을 지원하기 위해 문서 형 선언이라는 메커니즘을 제공한다.XML 문서가 연관된 문서 형 선언을 갖고 있고 그 선언에 명시된 조건을 따른다면 그것은 유효한(valid) 문서가 된다.
문서 형 선언은 문서 내 최초의 엘리먼트에 앞서 나타나야 한다.
| Prolog | ||||||||||||||||||||||||
|
XML 문서 형 선언은 문서 클래스에 문법을 제공하는 마크업 선언들을 포함하거나 가리킨다. 문법이란 문서 형 정의, 즉 DTD를 말한다. 문서 형 선언은 마크업 선언들을 담고 있는 특별한 외부 부분집합(외부 엔터티의 특별한 부류)들을 가리키거나 내부 부분집합에서 마크업 선언들을 직접 포함할 수 있고, 혹은 그 둘을 모두 할 수도 있다. 문서의 DTD는 함께 취해지는 그 두 부분집합들로 구성된다.
마크업 선언은 엘리먼트 타입 선언, 속성 리스트 선언, 엔터티 선언, 혹은 표기법 선언이다. 이런 선언들은 다음의 정합성 규약과 유효성 규약에 기술된 것 처럼 매개변수 엔터티안에 통째로 또는 부분적으로 포함될 수 있다. 보다 자세한 사항은 "4. 물리적 구조"에 나와 있다.
| Document Type Definition | ||||||||||||||||||
|
마크업 선언은 매개변수 엔터티의 대체 텍스트 의 천체 혹은 부분으로 구성될 수 있다. 개인적인 비종단(elementdecl, AttlistDecl 등)을 위해 이 스펙의 후반부는 모든 매개변수 엔터티들이 포함되고 난 다음의 선언들에 대해 기술하고 있다.
유효성 규약 : 루트 엘리먼트 타입.
문서 형 선언에서의 이름은 루트 엘리먼트의 엘리먼트 타입과 일치해야 한다.
유효성 규약 : 올바른 선언/PE 중첩.
매개변수-엔터티 대체 텍스트는 마크업 선언들로 올바르게 중첩되어야 한다. 다시 말하면 마크업 선언의 처음 문자 또는 마지막 문자(위에 있는 markupdecl)는 매개변수-엔터티 참조의 대체 텍스트에 포함되며, 그 둘은 같은 대체 텍스트 안에 포함되어야 한다.
정합성 규약 : 내부 부분집합 안의 PEs.
내부 DTD 부분집합에서 매개변수-엔터티 참조는 마크업 선언이 있는 곳에서만 발생하며 마크업 선언 내부에서는 일어나지 않는다.(이것은 외부 매개변수 엔터티들 안에서 발생하는 참조 또는 외부 부분집합에는 적용되지 않는다).
내부 부분집합과 같이 DTD 안에서 참조되는 외부 부분집합과 외부 매개변수 엔터티들은 비종단 기호인 markupdecl에 의해 허용되고 여백 또는 매개변수 엔터티 참조들과 함께 흩어져 있는 타입들의 완전한 마크업 선언들의 연속으로 구성되어야 한다. 그러나 외부 부분집합 혹은 외부 매개변수 엔터티 내용의 일부분들은 경우에 따라 조건 섹션의 구성물을 사용함으로써 무시할 수 있다. 이는 내부 부분집합에서는 허용되지 않는다.
| External Subset | ||||||||
|
외부 부분집합과 외부 매개변수 엔터티들 역시 그런 점에서 내부 부분집합과 구별되며, 매개변수 엔터티 참조들은 마크업 선언들 사이에서 뿐 아니라 마크업 선언들 내부에서도 허용된다.
문서 형 선언을 가진 XML 문서의 예이다.
<?xml version="1.0"?> |
시스템 식별자인 "hello.dtd"는 문서에 DTD의 URI를 준다.
선언들은 다음의 예에서 보듯 로컬에서 주어질 수도 있다.
<?xml version="1.0" encoding="UTF-8" ?> |
외부 부분집합과 내부 부분집합이 모두 사용되면 내부 부분집합은 외부 부분집합에 앞서 발생한 것으로 간주된다. 이는 내부 부분집합의 엔터티와 속성 리스트 선언이 외부 부분집합의 엔터티와 속성 리스트 선언보다 우선권을 갖게 되는 효과를 가져온다.
2.9 독자적인 문서 선언
마크업 선언들은 XML 프로세서에서 어플리케이션으로 전해질 때 문서의 내용에 영향을 미칠 수 있다. 속성 초기값이나 엔터티 선언들이 그 예이다. XML 선언의 한 구성 요소로 나타날 수 있는 독자적인 문서 선언은 문서 엔터티의 외부에 나타나는 선언들이 있는지의 여부를 신호해 준다.| Standalone Document Declaration | ||||||
|
독자적인 문서 선언에서 "yes"라는 값은 문서 엔터티 (DTD 외부 부분집합 내에 혹은 내부 부분집합로부터 참고된 외부 매개변수 엔터티 내에 있는)의 외부에 마크업 선언들이 없다는 것을 나타낸다. 마크업 선언들은 XML 프로세서로부터 어플리케이션으로 전해지는 정보에 영향을 미친다. "no"라는 값은 그러한 외부 마크업 선언들이 있거나 있을 수 있다는 것을 나타낸다. 독자적인 문서 선언은 외부 선언들의 존재를 단지 나타낼 뿐이라는 점에 유의해야 하는데 즉, 외부 엔터티들이 내부적으로 선언되어 있으면 문서 내에서 외부 엔터티 참조의 존재는 그것의 독자적인 상태를 변화시키지 않는다.
외부 마크업 선언들이 없다면 독자적인 문서 선언은 아무런 의미가 없다. 외부 마크업 선언들이 있다면 독자적인 문서 선언은 존재하지 않으며 "no" 값으로 간주된다.
Standalone="no"가 효력을 갖는 모든 XML 문서는 알고리즘적으로 독자적인 문서로 전환될 수 있는데, 이는 몇몇 네트워크 전송 어플리케이션에는 아주 유용한 것이다.
유효성 규약 : 독자적인 문서 선언.
독자적인 문서 선언은 어떤 외부 마크업 선언이 다음을 포함할 경우 "no" 값을 가져야만 한다.
- 초기 값을 갖는 속성들의 선언.(이 속성들이 적용되는 엘리먼트들이 문서 안에서 이 속성들의 값에 대한 기술없이 나타나는 경우) 또는
- amp, lt, gt, apos, quot 이외의 엔터티들의 선언.(그 엔터티들의 참조가 문서 안에 나타나는 경우) 또는
- normalization에 종속적인 값들을 갖는 속성들의 선언.(문서 내에서 속성들이 정상화의 결과로 변하게 될 값을 가지며 나타날 경우) 또는
- 엘리먼트 내용을 갖는 엘리먼트 타입들의 선언.(여백이 그 엘리먼트 타입의 인스턴스 내부에서 곧바로 발생하는 경우)
<?xml version="1.0" standalone='yes'?> |
2.10 여백 처리
XML 문서들을 편집할 때 마크업을 훨씬 쉽게 알아볼 수 있도록 분리하려면 여백(이 스펙에 나와있는 비종단 S를 사용해 표현되는 스페이스, 탭, 빈라인)을 사용하는 것이 편리하다. 여백의 목적은 문서의 전달된 버전에 포함되는 것이 결코 아니다. 그와는 반대로 의미있는 여백이 전달된 버전에 저장되어야 하는 것은 다영한 일이다 (예를 들어 시와 소스 코드 안에서).XML프로세서는 마크업이 아닌 문서내의 모든 문자들을 어플리케이션에 보내주어야만 한다. 유효성을 검사하는 XML 프로세서는 이들 문자들중 어느 것이 요소 내용에 나타나는 여백을 구성하는지를 어플리케이션에 알려주어야만 한다.
xml로 이름붙여진 특별한 속성 : 스페이스는 요소에 붙여져야 하는데 이는 어플리케이션들에 의해 그 요소 안에 여백이 보존되어야만 한다는 의도를 알려주기 위해서이다. 유효한 문서에서 이 속성은 다른 속성과 마찬가지로 사용되는 경우에 선언되어야만 한다. 선언될 경우 그것은 가치값이 초기값(default)와 보존하라(preserve)만 가능한 열거형식으로 주어져야만 한다. 예를 들어보자.
<!ATTLIST poem xml:space (default|preserve) 'preserve'> |
초기값이라는 가치값은 어플리케이션들의 기본적인 여백 처리 모드들이 이 요소에 적합함을 나타낸다. 보존하라는 가치값은 어플리케이션들이 모든 여백을 보전해야 한다는 의도를 나타낸다. 이 선언된 의도는 또 다른 xml 문서로 바뀌지 않는다면 그것이 상술되어 있는 요소의 내용 안에서 모든 요소들에 적용될 것이다. : 스페이스 속성
어떤 문서의 루트 요소는 그것이 이 속성에 가치값을 제공하거나 속성이 디폴트 가치값으로 선언된 경우가 아니라면 어플리케이션 스페이스 처리에 관해 아무런 의도도 신호해서는 안된다.
2.11 라인의 끝부분 처리
XML의 파싱된 엔터티들은 종종 편집상의 편의를 위해 라인으로 구성된 컴퓨터 파일들로 저장된다. 이 라인들은 전형적으로 문자 복귀(#xD)와 라인 피드(#xA)의 몇몇 조합에 의해 분리된다.외부의 파싱된 엔터티 또는 내부의 파싱된 엔터티의 문자 엔터티 가치값이 두개의 문자를 연속적으로(#xD#xA) 포함하든지 아니면 #xD와 같이 하나의 문자를 포함하든지에 상관없이 XML 프로세서는 문자 어플리케이션의 업무를 단순화하기 위해 하나의 #xA 문자를 어플리케이션에 보내야만 한다. (이 행위는 파싱하기 전에 입력할 때 모든 줄바꿈을 #xA로 표준화함으로써 가능하다)
2.12 언어 식별
문서를 파싱할 때 컨텐트를 만들 때 사용한 자연 언어나 공식언어가 무엇인지 식별하는 것은 종종 유용할 때가 있다. xml이라는 특별한 속성 : XML 문서에 있는 요소들의 속성 가치값이나 컨텐츠에 사용된 언어를 특화하기 위해 lang이란 단어가 문서내에 삽입될 수 있다. 유효한 문서에서 다른 속성들과 마찬가지로 이 속성을 사용할 경우 선언해주어야 한다. 이 속성의 가치값들은 [RFC1766] "언어 식별을 위한 태그들"에 정의된대로 언어를 식별할 수 있다.| Language Identification | ||||||||||||||||||||||||
|
Langcode란 다음과 같은 경우를 말한다.
- 두개의 문자로 된 언어코드서 [ISO
639]에 정의된 것 처럼 언어들의 이름을 나타내기 위한 코드.
- Internet Assigned Numbers Authority [IANA]에
등록된 언어 식별자 : 이것들은 "I"나 "I"로 시작한다.
- 사용자에 의해 지정되거나 개인적인 사용시 부분들간에 동의된 언어 식별자 : 이것들은 나중에 표준화 되거나 IANA에 등록된
이름들과 혼돈을 빚지 않기 위해 "x"나 "X"로 시작해야만 한다.
언어에 하위 코드를 주고 국가에 상위코드를 주는 것은 관례다. XML문서의 다른 이름들과는 달리 이 가치값들은 경우에 따라 달라진다는 것을 주목하라.
예를 들어보자.
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p> |
xml로 선언된 의도 : lang은 xml 문서로 대체되지 않는다면 그것이 상술되어 있는 모든 속성과 요소의 내용에 따라야 한다. : 그 컨텐트 내의 또다른 요소에 관한 lang
xml을 위한 간단한 선언 : lang은 이 형식을 따를 것이다.
xml:lang NMTOKEN #IMPLIED |
그러나 조건이 맞는다면 특정한 디폴트 가치값이 주어질 수도 있다. 영어권 학생들을 위해 영어로 주석이 달린 프랑스 시 모음집에서 xml : lang은 다음과 같이 선언될 수 있다.
<!ATTLIST poem xml:lang NMTOKEN 'fr'> |
3. 논리적 구조들
각각의 XML 문서는 하나 또는 그 이상의 요소들을 담고 있다. 요소들의 경계는 시작태그와 마침태그에 의해 정해지고 내용없는 요소들의 경우 엠프티 태그들에 의해 정해진다. 모든 요소는 이름에 의해 식별되는 타입을 가지고있는데 타입은 종종 일반적인 식별자(GI)로 불린다. 그리고 매 요소는 속성 스펙의 세트를 가지고 있어야 한다. 각 속성 스펙은 이름과 밸류를 가지고 있다.| Element | ||||||||||||||||
|
이 스펙은 의미론이나 사용법 또는 문법을 넘어서 요소타입들의 이름이나 속성 등을 담고 있지는 않다. 다만 (('X'|'x')('M'|'m')('L'|'l'))의 조응을 갖고 있는 이름들은 이 스펙이 이번 혹은 차후버전에서의 표준을 위해 남겨졌다.
Well-formedness 조건 : 엘리먼트 타입의 조응.
요소의 마침태그에 있는 이름은 반드시 요소의 시작태그에 있는 이름과 일치해야 한다.
Validity 조건 : 요소의 유효성.
이름이 요소타입과 조응하는 elementdecl에 일치하는 선언이 있거나 다음의 한 경우에 해당할 때 그 요소는 유효하다.
- 선언이 Empty와 조응하고 그 요소가 아무런 내용도
담고 있지 않는 경우
- 선언이 children과
조응하고, child
요소들의 연속이 각각의 자녀 요소들 간의 선택적인 여백(비종단 S와 일치하는
문자들)과 함께 컨텐트 모델에서 규칙적인 표현에 의해 보증되는 언어에 속하는 경우.
- 선언이 Mixed와
조응하고 그 내용이 문자
데이터와 내용 모델에서 요소타입이 이름과 일치하는 자녀
요소들로 구성될 경우.
- 선언이 ANY와 조응하고 어떤 자녀
요소들의 타입들이 선언되었을 경우.
3.1 시작태그, 마침태그, 비어있는 요소 태그
비어있지 않은 모든 XML요소의 시작은 시작 태그에 의해 표시된다.| Start-tag | ||||||||||||||||||||||||
|
시작태그와 마침태그 내의 이름은 요소의 타입을 설명한다. 한쌍의 Name과 Attvalue는 요소의 속성에 대한 상술로 간주된다. 즉 각 쌍에 있는 Name은 속성의 이름으로 간주되고 Attvalue의 내용(' or " 범위지정자 사이에 있는 텍스트)은 속성 가치값으로 간주된다.
Well-formedness 조건 : 독특한 Att 스펙.
어떤 속성 이름도 같은 시작태그나 빈요소 태그에 한 번 이상 나타나서는 안된다.
Validity 조건 : 속성 가치값 타입.
속성은 반드시 선언되어야 한다. 가치값은 그것을 위해 선언된 타입의 가치값이어야 한다. (속성 타입에 관해서는 "3.3 속성 리스트 선언들"을 볼 것)
Well-formedness 조건 : 외부 엔터티 참고가 없다.
속성 가치값들은 외부 엔터티에 직간접적인 엔터티 참고를 포함할 수 없다.
Well-formedness 조건 : 속성 가치값이 <가 있어서는 안된다.
속성가치값("<"와 다른 것) 에서 직간접적으로 참고되는 엔터티의 대체 텍스트는 <를 포함해서는 안된다.
시작태그의 예이다.
<termdef id="dt-dog" term="dog"> |
시작태그로 시작한 모든 요소의 끝은 시작태그에서 주어진 요서의 타입과 일치하는 이름을 포함하고 있는 엔드 태그에 의해 마크되어야만 한다.
| End-tag | ||||
|
마침 태그의 예이다.
</termdef> |
시작 태그와 마침 태그 사이의 텍스트는 요소의 내용이라 불린다.
| Content of Elements | ||||
|
요소가 비어있다면 그것은 마침태그가 바로 뒤에 붙는 시작태그에 의해 표현되거나 비어있는 요소 태그를 사용해 표현되어야 한다. 비어있는 요소 태그는 특별한 양식을 요구한다.
| Tags for Empty Elements | ||||||
|
비어있는 요소 태그는 그것이 EMPTY란 키워드를 사용해 선언되었건 아니건 간에 아무런 내용도 갖고 있지 않는 요소를 위해 사용한다. 상호운용성을 위해 비어있는 요소 태그는 사용해야만 하며 EMPTY로 선언된 요소들만을 위해 사용할 수 있다.
비어있는 요소들의 예이다.
<IMG align="left" |
3.2 엘리먼트 타입 선언
XML 문서의 요소 구조는 유효성이라는 면에서 보자면 엘리먼트 타입과 속성 리스트 선언들을 사용해 제약받아야 한다. 엘리먼트 타입 선언은 요소의 내용을 제약한다.엘리먼트 타입 선언은 종종 어느 엘리먼트 타입이 요소의 자식으로 보여질 수 있는지도 규정한다. 이용자 옵션에서 XML프로세서는 한 선언이 어떠한 선언도 제공되지 않은 엘리먼트 타입에 관해 언급할 때 경고를 보낼 수 있다. 그러나 이런 상황은 에러는 아니다.
엘리먼트 타입 선언은 다음의 양식을 따른다.
| Element Type Declaration | ||||||||||
|
이름은 선언되고 있는 엘리먼트 타입을 알려준다.
유효성 조건 : 독특한 엘리먼트 선언.
어떤 엘리먼트 타입도 한번 이상 선언되어서는 안된다.
엘리먼트 타입 선언들의 예이다.
<!ELEMENT br EMPTY> |
3.2.1 요소 내용
요소 타입은 그 타입의 요소들이 여백(비종단 S와 조응하는 문자들)에 의해 분리될 수 있는 자식 요소(문자데이터가 아니다) 를 포함할 때 요소 내용을 가진다. 이 경우 제한사항은 내용 모델, 자식 요소들의 허용된 타입들을 통제하는 간단한 문법, 그리고 자식 요소들이 나타나야할 순서들을 포함한다. 문법은 내용분자(cps)에 관해 만들어지는데 이름들과 내용분자들의 선택 리스트, 또는 내용 분자들의 연속 리스트들로 구성돼 있다.| Element-content Models | ||||||||||||||||||||
|
각 이름은 자식요소로 나타나는 요소들의 타입이다. 선택 리스트에 있는 어떤 내용분자도 문법 내에서 선택리스트가 나타나는 곳의 요소 내용에 나타날 수 있다. ; 연속 리스트에서 발생하는 내용분자들은 리스트에 주어진 순서대로 요소 내용에 각각 발생해야 한다. 이름이나 리스트 다음에 오는 옵션 문자는 리스트 내의 요소 또는 내용분자가 한 번 또는 그이상 발생하거나(+), 영번 또는 그이상 발생하거나(*), 영번 또는 한번 발생(?)할 수 있다. 그러한 작동자가 없다는 것은 요소 또는 내용분자가 딱 한번만 나타나야함을 의미한다. 이 문법과 의미는 이 스펙의 산물에서 사용된 것들과 동일하다.
요소의 내용은 연속과 선택, 반복 실행자를 준수하고 내용 속의 모든 요소를 내용 모델의 엘리먼트 타입과 대응해 매치시키며 내용 모델을 통해 경로를 트레이스하거나 그럴 경우에만 요소의 모델과 조응한다. 호환성 면에서 보자면 문서 내의 요소가 내용 모델 속 엘리먼트 타입이 한번 이상 발생하는 것과 조응하는 것은 에러다. 더 자세한 사항을 알고 싶으면 "부록 E : 결정성 내용 모델"을 볼 것.
유효성 조건 : 적당한 그룹/PE 중첩.
매개변수 엔터티 대체 문서는 괄호처리된 그룹과 적절히 중첩되어야 한다. 다시 말해 선택, 연속, 혼합 구조에서 괄호를 열거나 닫는 것은 매개변수 엔터티의 대체 텍스트 안에 포함된다. 양쪽 다같은 대체 문서에 포함되어야 한다.
상호운용성 면에서 볼때 매개변수 엔터티 참고가 선택, 연속, 혼합 구조에 나타나면 그것의 대체 텍스트는 비어있어서는 안되고 대체 텍스트의 첫번째나 마지막 비공백 문자가 커넥터(| or ,) 여서는 안된다.
요소 내용 모델들의 예
<!ELEMENT spec (front, body, back?)> |
3.2.2 혼합된 내용
요소 타입은 그 타입의 요소들이 문자 데이터나 선택적으로 자식 요소들과 혼재되어 있을 경우 내용을 혼합한다. 이 경우 자식 요소들의 타입들은 제약을 받지만 그들이 순서나 발생 빈도는 제약을 받지 않는다.| Mixed-content Declaration | ||||||||||||||||
|
이름은 자식으로 나타날 수 있는 요소들의 타입을 알려준다.
유효성 조건 : 복사 타입은 없다.
같은 이름이 단일한 혼합된 내용 선언에서 한번 이상 나타나서는 안된다.
혼합된 내용 선언들의 예이다.
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*> |
3.3 속성 리스트 선언들
속성들은 이름-가치값 쌍을 요소들과 연관시키는데 사용한다. 속성 스펙은 시작 태그와 비어있는 요소 태그들 사이에서만 나타날 수 있다. 그것들을 인식할 수 있는 산물은 "3.1 시작 태그, 마침 태그, 비어있는 요소 태그"에 나와 있다. 속성 리스트 선언들은 다음의 목적을 위해 사용된다.- 주어진 엘리먼트 타입에 속하는 속성들의 집합을 정의하기 위해
- 이러한 속성들의 타입 제한조건을 정하기 위해
- 속성들의 초기값을
제공하기 위해
| Attribute-list Declaration | ||||||||
|
AttlistDecl 규칙에서 이름은 요소의 타입을 말한다. 사용자 옵션으로 XML 프로세서는 속성들이 엘리먼트 타입(그자체는 선언되지 않은)을 위해 선언되면 경고를 보낼 수 있는데 이것은 에러는 아니다. AttDef 규칙에서 이름은 그 속성의 이름이다.
하나 이상의 AttlistDecl이 주어진 엘리먼트 타입에 제공되면, 제공된 모든 내용들은 병합된다. 주어진 요소타입의 같은 속성에 하나 이상의 정의가 주어지면 최초의 선언은 묶이고 나중의 선언들은 무시된다. 상호운용성을 위해 DTD 작성자들은 주어진 요소타입에 최대한 하나의 속성 리스트 선언을, 주어진 속성 이름에 최대한 하나의 속성 선언을, 그리고 각각의 속성 리스트 선언에 최소한 하나의 속성 선언을 제공하기 위해 선택할 것이다. 상호운용성을 위해 XML프로세서는 이용자 옵션으로 주어진 엘리먼트 타입에 하나 이상의 속성 리스트 선언이 제공되거나 또는 주어진 속성에 하나 이상의 속성 선언이 제공될 때 경고를 해 줄 수 있다. 그러나 이것이 에러는 아니다.
3.3.1 속성 타입
XML 속성 타입에는 세종류가 있다. 문자열 타입, 토큰화된 타입, 그리고 숫자를 매겨가는 타입. 문자열 타입은 가치값으로 글자들을 사용한다. 토큰화된 타입은 주석에 나와 있는 대로 다양한 어휘와 의미적 제한들을 사용한다.| Attribute Types | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
유효성 조건 : ID. ID 타입의 가치값들은 Name 산물들과 맞아야 한다.
이름은 XML 문서에서 이 타입의 가치값으로는 한번 이상 나타나서는 안된다. 예를 들어 ID 가치값은 그것을 낳는 요소들을 독특한 방식으로 식별해야 한다.
유효성 조건 : 엘리먼트 타입당 하나의 ID.
요소 무입은 상술된 ID 속성을 하나 이상 가질 수 없다.
유효성 조건 : ID 속성의 초기값.
ID 속성은 #IMPLIED 또는 #REQUIRED의 선언된 초기값을 가져야만 한다.
유효성 조건 : IDREF.
IDREF타입의 가치값들은 Name 산물과 조응해야 하고 IDREFS 타입의 가치값들은 이름들과 조응해야 하고, 각각의 이름은 XML문서내의 어떤 요소에 관한 ID 속성의 가치값과 조응해야만 하다. 즉 IDREF 가치값은 어떤 ID 속성과 매치되어야만 한다.
유효성 조건 : 엔터티 이름.
엔터티 타입의 가치값은 Name 산물과 조응해야만 하고 ENTITIES 타입의 가치값들은 이름들과 조응해야 하고, 각각의 이름은 DTD에 선언된 파싱되지 않은 엔터티의 이름과 조응해야 한다.
유효성 조건 : 이름 토큰.
NMTOKEN 타입의 가치값들은 Nmtoken
산물과 일치해야 하고 NMTOKENS타입의 가치값들은 Nmtokens와
매치되어야 한다.
숫자로 매겨지는 속성은 선언에서 제공된
가치들의 리스트 중 하나를 이용할 수 있다. 숫자로 매기는 타입에는 두가지 종류가 있다.
| Enumerated Attribute Types | ||||||||||||||||
|
NOTATION 속성은 속성이 첨부된 요소를 해석하는데 사용하기 위해 연관된 시스템과 (또는) 공식의 식별자를 가진 DTD에 선언된 기수를 식별한다.
유효성 조건 : Notation 속성.
이 타입의 가치값들은 선언에 포함된 기수 이름중의 하나와 조응해야만 한다. 선언 안에 있는 모든 기수 이름들은 선언되어야만 한다.
유효성 조건 : 열거.
이 타입의 가치값들은 선언 안의 Nmtoken 토큰들 중 하나와 조응해야 한다.
상호운용성을 위해 동일한 Nmtoken은 단일한 엘리먼트 타입의 열거된 속성 타입들 내에서 한번 이상 발생해서는 안된다.
3.3.2 속성 초기값
속성 선언은 속성의 존재가 필요한지 아닌지에 관한 정보를 제공한다. 또는 문서에서 선언된 속성이 부재할 경우 XML 프로세서가 어떻게 반응해야 하는 가에 관한 정보를 제공한다.| Attribute Defaults | ||||||||||||||||||||||||||||
|
속성 선언에서 #REQUIRED은 속성이 언제나 제공되어야 한다는 것 뜻하고 #IMPLIED은 어떤 초기값 밸류도 제공되지 않았다는 것을 뜻한다. 만약 선언이 #REQUIRED도 아니고 #IMPLIED도 아니라면 AttValue 가치값은 선언된 초기값을 포함한다. #FIXED라는 키워드는 속성이 언제나 초기값을 가져야 한다는 것을 말한다. 만약 초기값 밸류가 선언되면 XML프로세서는 누락된 속성을 만났을 때 속성이 선언된 초기값 밸류에 있는 것으로 가정하고 작동한다.
유효성 조건 : 요구되는 속성.
초기값 선언이 #REQUIRED라는 키워드라면 속성은 속성 리스트 선언 내에 있는 타입의 모든 요소들을 위해 상술되어야만 한다.
유효성 조건 : 효력을 갖는 속성 초기값.
선어된 초기값 밸류는 선언된 속성 타입의 어휘 제약을 총족해야만 한다.
유효성 조건 : 고정된 속성 초기값.
속성이 #FIXED라는 키워드와 함께 선언된 초기값 밸류를 가지고 있다면 그 속성의 인스턴스는 초기값 밸류와 조응해야만 한다.
속성 리스트 선언의 예이다.
<!ATTLIST termdef |
3.3.3 속성-가치값 표준화
속성의 가치값이 어플리케이션에 전해지거나 유효성 검사를 받기 전에, XML 프로세서는 다음의 사항대로 그것을 표준화해야만 한다.- 문자 참고는 참고된 문자를 속성 가치값에 추가해 처리한다.
- 엔터티 참고는 엔터티의 대체 텍스트를 재귀적으로 처리함으로써 처리한다.
- 여백 문자(#x20, #xD, #xA, #x9)는 #x20을 표준화된 가치에 추가함으로써 처리한다. 단 외부의 파싱된
엔터티 또는 내부의 파싱된 엔터티의 문자로 된 엔터티 가치값의 일부인 "#xD#xA" 순번을 위해 #x20 하나만 부가하는 경우는
제외한다.
- 다른 문자들은 그것들을 표준화된 가치값에 부가해 처리한다.
선언이 읽혀지지 않는 모든 속성들은 선언된 CDATA처럼 간주해 non-validating 파서로 다루어야 한다.
3.4 조건 부분
조건 부분은 그것들을 통제하는 키워드에 근거한 DTD의 논리적 구조에 포함된 또는 그것에서 배제된 문서 형 선언 외부 부분집합의 일부분이다.| Conditional Section | ||||||||||||||||||||
|
내부 그리고 외부의 DTD 부분집합과 마찬가지로 조건 섹션은 여백과 뒤섞인 하나 또는 그 이상의 완전한 선언들, 주석들, 처리명령어, 또는 중첩된 조건 섹션들을 포함할 수 있다.
조건 섹션의 키워드가 INCLUDE이면 조건 섹션의 내용들은 DTD의 일부이다. 조건 섹션의 키워드가 IGNORE이면 조건 섹션의 내용들은 논리적으로 DTD의 일부가 아니다. 신뢰성 있는 파싱을 위해서는 무시된 조건 섹션의 내용 조차도 읽어야만 하는데 이는 중첩된 조건 섹션을 찾아내고 무시된 조건 섹션의 끝을 확실히 찾아내기 위해서이다. INCLUDE라는 키워드를 포함한 조건섹션이 IGNORE라는 키워드를 가진 보다 큰 조건 섹션 안에 발생할 때 외부와 내부의 조건 섹션은 모두 무시된다.
조건 섹션의 키워드가 매개변수 엔터티 참고라면 프로세서가 조건 섹션을 포함할 것인가 무시할 것인가를 결정하기 전에 매개변수 엔터티는 그것의 내용으로 대체되어야만 한다.
예를 들어보자.
<!ENTITY % draft 'INCLUDE' > |
4. 물리적 구조
XML문서는 하나 또는 여러 개의 저장 단위로 구성된다. 이것들은 엔터티들이라고 불린다.; 엔터티는 모두 내용 을 가지고 있으며 모두 (단 아래에서 보듯 외부 DTD 부분집합와 문서 엔터티는 예외이다) 이름으로 식별된다. 각각의 XML 문서는 XML 프로세서의 시작점으로 쓰이고 전체 문서를 담을 수 있는 문서 엔터티를 가지고 있다.엔터티들은 파싱되기도 하고 되지 않기도 한다. 하나의 파싱된 엔터티의 내용은 그것의 대체 텍스트에 관한 것이다. 이 텍스트는 문서에서 꼭 필요한 부분으로 간주된다.
하나의 파싱되지 않은 엔터티는 소스가 텍스트일 수도 있고 아닐 수도있다. 만약 텍스트라면 XML이 아닐 것이다. 파싱되지 않은 각각의 엔터티는 연관된 표기법을 가지고 있는데 이는 이름으로 식별된다. XML프로세서는 어플리케이션에 이용가능한 엔터티와 표기를 위한 식별자를 가져야 한다는 조건을 넘어 XML은 파싱되지 않은 엔터티들의 내용에 어떠한 제약도 가하지 않는다.
파싱된 엔터티들은 엔터티 참고를 사용한 이름에 의해 호출된다. 파싱되지 않은 엔터티들은 엔터티값이나 엔터티들의 속성들에 주어진 이름에 의해 호출된다.
일반적인 엔터티들이란 문서 내용 안에서의 사용을 위한 엔터티를 말한다. 이 스펙에서 일반적인 엔터티들은 의미가 모호해지지 않는 한 종종 공식적으로 인정받지 않은 엔터티라는 말로 언급될 것이다. 매개변수 엔터티들은 DTD내에서의 사용을 위해 파싱된 엔터티들이다. 이 두가지 타입의 엔터티들은 서로 다른 양식의 참고를 사용하며 서로 다른 문맥 속에서 인식된다. 더욱이 그 둘은 서로 다른 네임스페이스를 차지한다. 같은 이름을 가진 매개 엔터티와 일반적인 엔터티는 확연이 구별된다.
4.1 문자와 엔터티 참조들
하나의 문자 참조란 ISO/IEC 10646 문자세트에 있는 특정한 문자를 가리킨다. 이용할 수 있는 입력장치로부터 직접적으로 접근할 수 없는 예를 하나 들어 보자.| 문자 참조 | ||||||||||
|
Well-Formedness 규약: 적법한 문자.
문자 참고를 사용해 언급된 문자들은 Char를 위한 산물과 조응해야 한다.
만약 문자 참고가 "&#x"로 시작하면, 정지성에 상응하는 숫자와 글자들은 ISO/IEC 10646의 문자 코트 포인트를 16진법으로 표현한다. 만약 문자참고가"&#"로 시작하면 정지성에 상응하는 숫자들은 문자 코드 포인트를 십진법으로 표현한다.
하나의 문자 참조는 이름 붙여진 엔터티의 내용에 관한 것이다. 파싱된 일반 엔터티 참고는 앰퍼샌드 (&)와 세미콜론 (;)을 범위한정자로 사용한다. 매개변수 엔터티 참조들은 퍼센티지 표시 (%)와 세미콜론 (;)을 범위한정자로 사용한다.
| 엔터티 참조 | ||||||||||||||||||||||||||||||||||||||||||||||
|
Well-Formedness 규약 : 선언된 엔터티
어떠한 DTD도 없는 문서, 매개변수 엔터티 참고를 하나도 포함하지 않은 내부 DTD 부분집합만을 가진 문서, 또는 "standalone='yes'"를 가진 문서에서 엔터티 참고에 주어진 Name은 엔터티 선언의 이름과 일치해야만 한다. 단 well-formed 문서들은 amp, lt, gt, apos, quot같은 엔터티들 중 어느 것도 선언할 필요가 없다. 매개변수 엔터티의 선언은 어느 매개변수 엔터티 참고보다도 선행해야 한다. 마찬가지로 일반 엔터티의 선언은 속성-리스트 선언에서 초기값 밸류에 나타나는 어떤 일반 엔터티 참고보다도 선행해야 한다. 엔터티들이 외부의 부분집합 또는 외부 매개변수 엔터티에서 선언되면 non-validating 프로세서는 그것들의 선언을 읽거나 처리할 의무가 없다는 점에 주목하라. 그런 문서들에서는 standalone='yes'일 경우에만 엔터니가 선언되어야 한다는 규칙이 well-formedness 조건이 된다.
유효성 규약 : 선언된 엔터티
외부 부분집합 또는 "standalone='no'"를 포함한 외부의 매개변수 엔터티를 가진 문서에서 엔터티 참고에 주어진 Name은 엔터티 선언에 주어진 이름과 조응해야만 한다. 상호운용성을 위해 유효한 문서들은 "4.6 미리 정의된 엔터티들"에 상술된 양식으로 amp, lt, gt, apos, quot등을 선언해야만 한다. 매개변수 엔터티의 선언은 그것의 어느 참고보다도 선행해야 한다. 마찬가지로 일반 엔터티의 선언은 속성 리스트 선언에 있는 초기값 밸류에 나타나는 어느 일반 엔터티 참고보다도 선행해야 한다.
Well-Formedness 규약 : 파싱된 엔터티.
엔터티 참고는 파싱되지 않은 엔터티의 이름을 포함해서는 안된다. 파싱되지 않은 엔터티는 엔터티 또는 엔터티들 타입이라고 선언된 속성 값들 에서만 참고할 수 있다.
Well-Formedness 규약 : 재귀 불가.
파싱된 엔터니는 직접적이든 간접적이든 그것 자체로 재귀하는 참고를 포함해서는 안된다.
Well-Formedness 규약 : DTD 내부.
매개변수 엔터티 참조들은 DTD 안에서만 나타날 수 있다.
문자와 엔터티 참조들의 예이다.
Type <key>less-than</key> (<) to save options. |
매개변수 엔터티 참조의 예이다.
<!-- declare the parameter entity "ISOLat2"... --> |
4.2 엔터티 선언들
엔터티들은 다음과 같은 식으로 선언된다.| 엔터티 선언 | ||||||||||||||||||||
|
Name은 엔터티 참조 안에 있는 엔터티 또는, 파싱되지 않은 엔터티의 경우는 엔터티나 엔터티들 속성값에 있는 엔터티를 식별한다. 같은 엔터티가 한번 이상 선언되면 맨 처음에 발견된 선언만이 묶이게 된다. 이용자 옵션으로 XML프로세서는 엔터티들이 여러 번 선언됐을 경우 경고를 할 수 있다.
4.2.1 내부 엔터티들
엔터티 선언이 EntityValue라면, 그 정의된 엔터티는 내부 엔터티라고 불린다. 분리된 물리적인 저장 객체가 없기 때문에 내부 엔터티의 내용은 선언에 주어진다. 문자로된 엔터티 값에 있는 엔터티와 문자참고의 몇몇 처리과정이 올바른 대체 텍스트를 만들기 위해 필요할 수 도 있다는 점을 주목하라.: "4.5 내부 엔터티 대체 텍스트의 생성"을 볼 것.내부 엔터티는 파싱된 엔터티이다.
내부 엔터티 선언의 예이다.
<!ENTITY Pub-Status "This is a pre-release of the |
4.2.2 외부 엔터티들
내부 엔터티가 아닌 것은 다음에 선언된 것처럼 외부 엔터티가 된다.| 외부 엔터티 선언 | ||||||||||||||
|
만약 NDataDecl이 나타난다면, 이것은 일반 파싱되지 않은 엔터티이다; 그렇지 않으면 그것은 파싱된 엔터티이다.
유효성 규약 : 선언된 표기
Name은 표기의 선언된 이름과 일치해야 한다.
The SystemLiteral은 엔터티의 시스템 식별자를 말한다. 그것은 엔터티를 검색하기 위해 사용되는 URI이다. 해쉬 마크(#)와 종종 URI와 함께 사용되는 단편 식별자는 정확하게는 URI 그 자체의 부분은 아니라는 점을 주목하라; XML 프로세서는 단편 식별자가 시스템 식별자의 부분으로 주어질 경우 에러 신호를 보낼 수 있다. 그렇지 않고 이 스펙의 범위 밖의 정보 (예를 들어 특정한 DTD에 의해 정의된 특별한 XML 엘리먼트 타입 또는 특정한 어플리케이션 스펙에 의해 정의된 처리 명령어 등)에 의해 제공되지 않으면 관계된 URI들은 엔터티 선언들이 발생하는 리소스의 위치에 상응한다. URI는 이런 식으로 문서 엔터티와 외부 DTD 부분집합을 포함하고 있는 엔터티, 또는 외부 매개변수 엔터티들과 관련을 갖는다.
XML 프로세서는 URI 내에서 아스키형태가 아닌 문자들을 다룰 수 있어야 한다. 그 방법은 1바이트 또는 그 이상으로 UTF-8에 있는 그 문자들을 표현한 다음 URI 탈출 메커니즘을 가지고 이 바이트들을 탈출하는 것으로 예를 들자면 각 바이트를 %HH로 변환하는 것 등이다. (HH는 바이트 가치값의의 16진법 표기를 말한다)
시스템 식별자에 덧붙여 외부 식별자는 공개된 식별자를 포함할 수도 있다. 엔터티 내용을 검색하고자 하는 XML 프로세서는 대안적인 URI를 발생시키기 위하여 공개된 식별자를 사용할 수도 있다. 그렇게 할 수 없다면 프로세서는 이 시스템에 상술된 URI를 사용해야만 한다. 매치가 시도되기 전에 공개된 식별자의 모든 여백 문자열은 단일한 공백 문자들(#x20)로 표준화되어야 하며 앞쪽에 있는 여백은 제거되어야만 한다.
외부 엔터티 선언들의 예이다.
<!ENTITY open-hatch |
4.3 파싱된 엔터티들
4.3.1 텍스트 선언
외부의 파싱된 엔터티들은 각각 텍스트 선언으로 시작한다.| 텍스트 선언 | ||||
|
텍스트 선언은 파싱된 엔터티의 참고에 의해서가 아니라 글자 그대로 주어져야 한다. 텍스트 선언은 외부의 파싱된 문서의 시작 외에는 어느 부분에도 나타나서는 안된다.
4.3.2 Well-Formed 파싱된 엔터티들
문서 엔터티는 그것이 문서라 이름 붙여진 것과 조응할 경우 형식에 잘 맞는 것이 된다. 외부의 일반 파싱된 엔터티는 그것이 extParsedEnt라 이름 붙여진 것과 매치될 경우 well-formed 된 것이다. 외부의 매개변수 엔터티는 그것이 extPE라 이름 붙여진 것과 조응할 경우 형식에 잘 맞는 것이 된다.| Well-Formed 외부의 파싱된 엔터티 | ||||||||
|
내부의 일반 파싱된 엔터티는 그것의 대체 텍스트가 내용이라 이름 붙여진 것과 조응할 경우 형식에 맞는 것이 된다. 모든 내부의 매개변수 엔터티들은 정의에 의해 well-formed가 된다.
엔터티들에서 well-formedness의 결과는 XML 문서 내에서 논리적, 물리적 구조들이 적절히 중첩된다는 것이다.; 시작 태그, 마침 태그, 빈 요소 태그, 요소, 주석, 처리 명령, 문자 참조, 또는 엔터티 참조는 절대로 한 엔터티에서 시작해 다른 엔터티에서 끝날 수 없다.
4.3.3 엔터티들에서의 문자 코딩
XML문서 내에 있는 각각의 외부 파싱 엔터티는 그것의 문자를 위한 다른 코딩 방법을 사용할 수 있다. 모든 XML 프로세서는 UTF-8이나 UTF-16의 엔터티를 읽을 수 있어야만 한다.>UTF-16으로 코딩된 엔터티들은 ISO/IEC 10646 Annex E와 Unicode Appendix B (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF)에 의해 기술된 Byte Order Mark로 시작해야만 한다. 이것은 인코딩 기호이며 마크업이나 XML문서의 문자데이터의 일부분이 아니다. XML 프로세서들은 UTF-8과 UTF-16으로 코딩된 문서들을 구별하기 위해 이런 문자를 사용해야만 한다.
XML 프로세서가 UTF-8과 UTF-16로 코딩된 엔터티만을 읽어야 한다고 하더라도 다른 코딩방법들도 세계 도처에서 널리 쓰이고 있다는 점을 인식해야 한다. 그리고 XML 프로세서들이 그것들을 사용하는 엔터티들을 읽는 것은 괜찮은 일이다. UTF-8과 UTF-16이 아닌 다른 코딩으로 저장되는 파싱된 엔터티들은 인코딩 선언을 담고있는 텍스트 선언과 함께 시작해야만 한다.:
| 부호화 선언 | ||||||||||
|
문서 엔터티 내에서, 부호화 선언은 XML 선언의 일부분이다. EncName 은 사용된 코딩의 이름을 의미한다.
부호화 선언 내에서 Unicode / ISO/IEC 10646의 다양한 인코딩과 변형을 위해서는 "UTF-8", "UTF-16", "ISO-10646-UCS-2", "ISO-10646-UCS-4"라는 값을 사용해야만 하고 ISO 8859의 부분들을 위해서는 "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-9"의 값들을 사용해야만 하며 JIS X-0208-1997의 다양한 코딩 형식을 위해서는 "ISO-2022-JP", "Shift_JIS", "EUC-JP"의 값을 사용해야만 한다. XMl 프로세서는 다른 인코딩방법을 인식할 수도 있다.; 열거된 것들 외에 Internet Assigned Numbers Authority [IANA]에 (as charsets)로 등록된 문자 코딩방법들은 그들의 등록된 이름의 사용을 참고하도록 권장되고 있다. 이 등록된 이름들은 상황에 따라 변하도록 정의되어 있어 그것들과 조응하고자 하는 프로세서들 역시 상황에 따라 다른 방식을 취해야 한다는 점에 주의하라.
외부 전송 프로토콜(HTTP 또는MIME)에 의해 제공된 정보가 없는 경우에 인코딩 선언을 포함하고 있는 엔터티가 선언에 붙여진 것과 다른 코딩으로 XML 프로세서에 나타나는 것은 에러이다. 인코딩 선언이 외부 엔터티의 시작이 아닌 다른 곳에서 나타나는 것도 에러이며 Byte Order Mark나 인코딩 선언으로 시작하지 않는 엔터티가 UTF-8 이외의 인코딩을 사용하는 것도 에러이다. 아스키는 UTF-8의 부분집합이며 보통의 아스키 엔터티들은 인코딩 선언을 꼭 필요로 하지는 않는다는 사실에 유의하라.
XML 프로세서가 처리할 수 없는 인코딩을 가진 엔터티와 만나는 것은 치명적 오류이다.
부호화 선언의 예이다.
<?xml encoding='UTF-8'?> |
4.4 XML 프로세서의 엔터티와 참조 처리
아래에 있는 테이블은 문자 참고와 엔터티 참고, 파싱되지 않은 엔터티들의 호출 등이 나타나는 문맥과 그 각 경우에 있어 XML 프로세서의 행위에 관한 요약이다. 맨 왼쪽 열의 라벨은 인식 정황을 기술하고 있다. :- 내용 안의 참조
- as a reference 어떤 요소의 시작 태그의 다음과 마침 태그의 전 어디에나 존재하는 참조 비종단 내용과 일치한다.
- 속성값 안의 참조
- 시작 태그에 있는 속성의 가치값이나 속성 선언에 있는 초기값 내에 존재하는 참조. 비종단 AttValue와 일치한다.
- 속성값으로서 발생
- 엔터티 형식으로 선언된 속성값이나 ENTITIES 형식으로 선언된 속성값에 있는 공간적으로 떨어진 토큰 중의 하나로서 나타나는 이름으로 참조가 아니다.
- 엔터티값 내의 참조
- 엔터티의 선언에 있는 내부 엔터티의 글자 엔터티값이나 매개변수 안에 존재하는 참조로서 비종단 EntityValue와 일치한다.
- DTD 내의 참조
- DTD의 내부 혹은 외부 부분집합 안에, 그러나 EntityValue 또는 AttValue의 외부에 존재하는 참조.
| 엔터티 타입 | 문자 | ||||
| 매개변수 | 내부의 일반 |
외부의 파싱된 일반 |
파싱되지 않은 | ||
| 내용 안의 참조 |
인식되지 않음 | 포함 | 유효할 경우 포함 | 금지 | 포함 |
| 속성값의 참조 |
인식되지 않음 | 글자로 포함 | 금지 | 금지 | 포함 |
| 속성값으로 발생 |
인식되지 않음 | 금지 | 금지 | 통보 | 인식되지 않음 |
| 엔터티값의 참조 |
글자로 포함 | 무시 | 무시 | 금지 | 포함 |
| DTD내의 참조 |
PE로 포함 | 금지 | 금지 | 금지 | 금지 |
4.4.1 인식되지 않음
DTD 밖에 있는 문자 % 는 아무런 특별의미도 가지지 않는다. ; 그래서 DTD안에서 매개변수 엔터티가 되는 것은 내용에서 마크업으로 인식되지 않는다. 같은 식으로 파싱되지 않은 엔터티들의 이름들은 정적히 선언된 속성의 가치값 안에 나타나는 경우를 제외하고는 인식되지 않는다.4.4.2 포함
엔터티는 그것의 대체 텍스트가 참고문 그 자체를 대신해 검색되고 처리될 때 포함되는데 그것은 참고문이 인식되는 곳에서는 문서의 일부분인 것 처럼 간주된다. 대체 텍스트는 문자 데이터와 (매개변수 엔터티들은 제외하고) 마크업을 포함할 수 있는데 그것들은 보통의 방식으로 인식되어야만 한다. 단 마크업 범위한정자(amp lt, gt, apos, quot 같은 엔터티들)와 혼동되는 것을 피하기 위해 대체 텍스트는 언제나 데이터로서 다루어야 한다. ("AT&T;"라는 문자열은 "AT&T;"로 확장하고 남아있는 앰퍼샌드는 엔터티 참고 범위한 정자로 인식되지 않는다) 문자 참고는 지시된 문자가 참고문 그 자체를 대신해 처리되는 경우에만 포함된다.4.4.3 유효할 경우 포함
XML 프로세서가 파싱된 엔터티의 참고문을 인식할 때, 문서의 유효성검사를 위해 XML 프로세서는 그것의 대체 텍스트를 포함해야만 한다. 그 엔터티가 외부 엔터티라면 프로세서는 그 XML 문서의 유효성을 검사하려 해서는 안된다. 프로세서는 엔터티의 대체 텍스트를 포함할 수도 있지만 꼭 그럴 필요는 없다. 유효성 검사용이 아닌 파서는 대체 텍스트를 포함하지 않는다. 그것은 어플리케이션에 그 엔터티를 인식했지만 읽을 수 없다는 것을 알려주어야 한다.이런 규칙은 SGML과 XML 엔터티 메커니즘에 의해 제공되고, 우선적으로 저작에 있어 모듈성을 지원하도록 설계된 자동 포함이 다른 어플리케이션들, 특히 문서 브라우징에 반드시 적합하지는 않다는 인식에 기초한다. 예를 들어 브라우저들은 외부의 파싱된 엔터티 참고문을 만나면 엔터티가 존재함을 시각적으로 보여주거나 요청이 있을 경우에만 디스플레이를 위해 검색할 수 있도록 하기 위해 선택을 할 수 있다.
4.4.4 금 지
다음의 것들은 금지된다. 이것들은 치명적인 오류를 낳는다:- 파싱되지
않은 엔터티에 관한 참조의 출현.
- l DTD 문서에서 어떤 문자나 일반 에터티 참고문이 나타날 때. 단 엔터티값
또는 속성값안에
있는 경우는 제외.
- 속성값에 있는 외부 엔터티의 참조
4.4.5 글자로 포함
엔터티 참조가 속성 가치값에 나타나거나 매개변수 엔터티가 문자 엔터티 가치값에 나타날 때 그것의 대체 텍스트 는 참고문 그 자체를 대신해 마치 그것이 참고문이 인식된 장소에 있는 문서의 일부분인 것처럼 간주해 처리된다. 단 대체 텍스트에 있는 하나 혹은 두개의 인용 문자는 언제나 보통의 테이터 캐릭터로 간주해 처리해야 하며 그 글자를 종결지어서는 안된다. 예를 들어보자. 다음은 형식에 잘 맞는 것이다.<!ENTITY % YN '"Yes"' > |
다음은 형식에 맞지 않는 것이다.
<!ENTITY EndAttr "27'" > |
4.4.6 통 보
파싱되지 않은 엔터티의 이름이 선언된 엔터티 또는 엔터티들 타입의 속성 가치값 안에 토큰으로 나타날 때, 유효성 검사 파서는 시스템의 어플리케이션과 공개된 (만약 있다면)식별자에게 엔터티와 그것이 관련된 표기를 위해 통보해야만 한다.4.4.7 무 시
일반 엔터티 참고문이 엔터티 선언 안에 있는 EntityValue에 나타날 때 그것은 무시되면 그대로 남겨진다.4.4.8 파싱된 엔터티로 포함
외부의 파싱된 엔터티들과 마찬가지로 매개변수 엔터티들은 유효하다면 포함될 필요가 있다. 매개변수 엔터티 참고가 DTD안에서 인식되고 포함될 때 그것의 대체 텍스트 는 앞에 오거나 뒤에 오는 공백(#x20)문자를 덧붙임으로써 확대된다. 이것의 목적은 매개변수 엔터티들의 대체 텍스트가 DTD안의 문법적인 토큰의 전체 수를 포함하도록 강제하는 것이다.4.5 내부 엔터티 대체 텍스트의 구성
내부 엔터티들의 처리에 관한 이야기를 할 때 엔터티 가치값의 두 양식을 구별하는 것은 유용한 일이다. 글자 엔터티값은 실제로 엔터티 선언에 나타나는 인용된 문자열인데 비종단 EntityValue와 일치한다. 대체 텍스트는 문자 참고문과 매개변수 엔터티 참조 다음에 오는 엔터티의 내용이다.내부 엔터티 선언( EntityValue)에 주어진 글자 엔터티값 (EntityValue)은 문자, 매개변수 엔터티, 일반 엔터티 참고문을 포함할 수 있다. 그런 참고문들은 전적으로 글자 엔터티 밸류안에 포함되어야 한다. 위에 기술된 대로 실제 포함된 대체 텍스트는 참고하는 어떤 매개변수 엔터티의 대체 텍스트를 담고 있어야 하고 글자 엔터티 가치값에 있는 어떤 문자 참고문 대신에 참고하는 문자를 포함해야 한다; 그러나 일반 엔터티 참고문은 확장되지 않은 채로 남아 있어야만 한다. 다음의 선언을 예로 들어보자.
<!ENTITY % pub "Éditions Gallimard" > |
엔터티 "book"의 대체 텍스트는 :
La Peste: Albert Camus, |
일반 엔터티 참조문 "&rights;"는 참조문 "&book;"이 문서의 내용이나 속성값에 나타날 경우 확장될 것이다.
이런 간단한 규칙들은 복잡한 상호작용을 한다. 보다 어려운 사례에 관한 상세한 논의를 알고 싶으면 "부록 D. 엔터티와 문자 참조들의 확장"을 볼 것.
4.6 미리 정의된 엔터티들
엔터티와 문자참고문들은 둘다 왼쪽 꺾쇠, 앰퍼샌드, 그리고 다른 범위한정자와의 혼돈을 피하기 위해 사용할 수 있다. 일반 엔터티의 집합 (amp, lt, gt, apos, quot)은 이런 목적을 위해 따로 정의된다. 수문자 참고 역시 사용할 수 있는데 그것들은 인식되는 즉시 확장되며 문자데이터로 간주된다. 그래서 수문자 참조 "<" 와 "&"는 < 와 &가 문자 데이터 내에 발생할 때 혼돈을 피하기 위해 사용할 수 있다.모든 XML프로세서는 이 엔터티들이 선언되었는지의 여부에 상관없이 그것들을 인식해야 한다. 상호운용성을 위해, 유효한 XML문서들은 다른 것과 마찬가지로 이 엔터티들을 사용하기 전에 선언해 주어야 한다. 해당 엔터티들이 선언되면 그것들은 내부 엔터티로 선언되어야만 하는데 내부엔터티의 대체 텍스트는 혼돈을 피하기 위해 쓰이는 하나의 문자이거나 아래 예시된 대로 그 문자의 문자 참고문이어야 한다.
<!ENTITY lt "&#60;"> |
"lt" 와 "amp"의 선언 속에 있는 <와 & 문자들은 엔터티 대체가 형식에 잘 맞아야 한다는 조건을 충족시키기 위해 이중으로 피해져야 한다는 사실을 주목할 것.
4.7 표기 선언들
표기들은 이름에 의해 파싱되지 않은 엔터티들의 포맷과 표기 속성을 낳는 요소들의 포맷, 또는 처리명령이 지정된 어플리케이션을 식별한다.표기 선언들은 표기를 위한 이름을 제공해 엔터티나 속성 리스트 선언 또는 속성 스펙에서 사용될 수 있게 한다. 그리고 외부의 식별기에 XML프로세서나 그것의 클라이언트 어플리케이션이 주어진 표기에서 데이터를 처리할 수 있는 도우미 어플리케이션의 위치를 지정해 주는 표기를 제공한다.
| Notation Declarations | ||||||||
|
XML 프로세서들은 어플리케이션들에 이름과 속성 가치값에서 선언되고 참고되는 표기의 외부 식별자, 속성 정의, 또는 속성 선언을 제공해야 한다. 프로세서들은 부가적으로 외부 식별자를 시스템 식별자, 파일명, 또는 어플리케이션이 기술된 표기 내의 데이터를 호출할 수 있도록 해주는 데 필요한 다른 정보로 변형시킬 수 있다. (그러나 XML 문서들이 XML프로세서나 어플리케이션이 구동되고 있는 시스템에서 표기에 특화된 어플리케이션이 가능하지 않은 표기들을 선언하거나 참고하는 것은 에러가 아니다)
4.8 문서 엔터티
문서 엔터티는 엔터티 트리구조의 루트로서, 그리고 XML 프로세서의 시작점으로 작용한다. 이 스펙은 문서 엔터티가 어떻게 XML프로세서에 의해 위치를 지정받는가를 상술하지 않는다. 다른 엔터티들과는 다르게 문서 엔터티는 이름을 갖지 않으며 어떠한 식별없이도 프로세서 입력 흐름에 나타날 수도 있다.5. 정 합
5.1 유효성검사 프로세서와 비 유효성검사 프로세서
정합성을 검사하는 XML 프로세서들은 두가지로 나뉜다. 유효성 검사 프로세서와 비 유효성 검사 프로세서.유효성 검사 프로세서와 비 유효성 검사 프로세서는 둘다 문서 엔터티와 그것들이 읽는 그 밖의 파싱된 엔터티들에서 이 스펙의 well-formedness 조건에 위반하는 것들을 알려주어야 한다.
유효성검사 프로세서들은 DTD의 선언으로 표현된 조건의 위반을 알려주어야 하고 이 스펙에 나와 있는 유효성 조건을 충족시키기 위해 잘못된 것들을 알려주어야 한다. 이것을 달성하기 위해 유효성 검사 XML 프로세서는 전체 DTD와 문서 내에서 참고된 모든 외부의 파싱 엔터티들을 읽고 처리해야 한다.
비 유효성 검사 프로세서들은 전체 내부 DTD 집합을 포함해 문서 엔터티의 형식이 잘 갖춰졌는지 만을 체크한다. 그것들은 문서의 유효성을 체크할 필요는 없는 반면 내부의 DTD 부분집합 안에서 그것들이 읽은 모든 선언과 그들이 읽은 어떠한 매개변수 엔터티 내부의 선언, 심지어 그들이 읽지 않은 매개변수 엔터티의 첫번째 참고안의 어떤 선언이라도 처리해야만 한다. 다시 말하면 Non-validting 프로세서들은 그 정보를 그러한 선언들안에서 속성값을 표준화하기 위해 사용해야 하고, 내부 엔터티들의 대체 텍스트를 포함해야 하며, 초기 속성값을 제공해야만 한다. 그것들은 엔터티가 무효로 하는 선언들을 포함하고 있을 지도 모르기 때문에 엔터티 선언들 또는 읽혀지지 않은 매개변수 엔터티의 참고문 다음에 나타나는 속성-리스트 선언들을 처리해서는 안된다.
5.2 XML 프로세서 사용하기
유효성 검사 XML 프로세서는 매우 범용적이다. 그것은 문서의 모든 부분을 읽어야 하고 모든 well-formedness와 유효성 위반을 알려주어야 한다. 비 유효성 검사 프로세서는 그런 것이 요구되지는 않는다. 그것은 문서 엔터티 외에 문서의 다른 어떤 부분도 읽어야 할 필요는 없다. 여기서 XML프로세서의 사용자에게 중요한 두가지 점을 알 수 있다.- 어떤 well-formedness 에러도, 특히 외부의 엔터티를 읽는데 필요한 well-formedness 에러는 비
유효성 검사 프로세서에 의해서는 발견되지 않을 수도 있다. 선언된
엔터티, 파싱된
엔터티, 재귀
불가라 이름 붙여진 제약조건들과 "4.4 XML
프로세서의 엔터티와 참조 처리"에서 금지
라고 기술된 몇몇 경우가 그 예이다.
- 프로세서에서 어플리케이션으로 전해지는 정보는 프로세서가 매개변수와 외부의 엔터티를 읽었는가의 여부에 따라 변할 수 있다.
예를 들어 비유효성 검사 프로세서는 속성값을 표준화하지
않을 수도 있고, 내부 엔터티들의 대체 텍스트를 포함하지
않을 수도 있고, 또는 초기
속성값들을 제공하지 않을 수도 있다. 그렇게 하는가 안하는 가는 외부 또는 매개변수 엔터티들에 있는 선언을 읽었는가
아닌가에 달려 있다.
6. 표 기
XML의 공식 문법은 간단한 Extended Backus-Naur Form (EBNF) 표기법을 사용해 이 스펙에 제시했다. 문법에 있는 각각의 규칙은 양식에 있는 하나의 심볼을 정의한다.symbol ::= expression |
심볼들은 정규적인 표현으로 정의되었을 경우 대문자의 이니셜만으로 쓰여지고 그렇지 않은 경우 소문자 이니셜로 쓰여진다. 문자열들은 인용된다.
규칙의 오른쪽에 있는 표현 안에 다음의 표현들이 하나 또는 그이상의 문자열과 대응하기 위해 사용된다.
- #xN
- N이 십육진법의 정수이면 그 표현은 ISO/IEC 10646의 문자와 조응하는데 그것의 규범적인(UCS-4) 코드 가치값은 부호없는 바이너리 숫자로 해석될 경우 지시된 가치값을 갖는다. #xN의 앞쪽에 있는 0의 개수는 별로 중요하지 않다. 일치하는 코드 값에서 앞에 있는 0의 개수는 사용하는 문자 코딩에 의해 영향을 받으며 XML에는 별로 중요하지 않다.
- [a-zA-Z], [#xN-#xN]
- 지시된(포함하는) 범위의 값을 갖는 어떤 문자와도 조응한다.
- [^a-z], [^#xN-#xN]
- 지시된 범위 밖의 값을 갖는 어떤 문자와도 조응한다.
- [^abc], [^#xN#xN#xN]
- 주어진 문자들 사이에 있지 않은 값을 가지는 어떤 문자와도 조응한다.
- "string"
- 큰 따옴표 안에 주어진 그것과 일치하는 문자열과 조응한다.
- 'string'
- 작은 따옴표 안에 주어진 그것과 일치하는 문자열과 조응한다.
- (표현)
- 표현은 한 단위로 다루어지며 다음 리스트에 기술된 대로 결합될 수 있다.
- A?
- A와 조응하거나 아무것과도 일치하지 않는다; 선택적으로 A와 일치.
- A B
- A,B와 순서대로 조응.
- A | B
- A 또는 B와 조응. 그러나 둘 다와 동시에 조응하지는 않는다.
- A - B
- A와 조응하나 B와는 조응하지 않는 어떤 문자열과도 일치한다.
- A+
- 한번 혹은 여러번 발생하는 A와 조응.
- A*
- 포함하지 않거나 여러 번 발생하는 A와 일치.
- /* ... */
- 주석.
- [ wfc: ... ]
- well-formedness 규약; 이것은 이름에 의해 저작과 관계된 well-formed 문서들에 대한 제약조건을 식별한다.
- [ vc: ... ]
- 유효성 규약; 이것은 이름에 의해 저작과 관련된 유효한 문서들에 대한 제약조건을 식별한다.
부 록
A. 참고
A.1 꼭 참고해야 할 것들
- IANA
- (Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. See 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, ed. H. Alvestrand. 1995.
- ISO 639
- (International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [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 subdivisions -- Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
- ISO/IEC 10646
- ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).
- Unicode
- The Unicode Consortium. 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 et al.
- Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (Work in progress; see updates to RFC1738.)
- Bruggemann-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. See http://www.w3.org/TR/NOTE-sgml-xml-971215.
- IETF RFC1738
- IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.
- IETF RFC1808
- IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators, ed. R. Fielding. 1995.
- IETF RFC2141
- IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997.
- ISO 8879
- ISO (International Organization for Standardization). ISO 8879:1986(E). 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). Information technology -- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
B. A. 문자집합들
Unicode 표준에 정의된 기준에 따르면 문자들은 기본문자들(무엇보다도 라틴 알파벳 중 발음구분을 위한 기호들을 뺀 영어 알파벳이 포함된) , 표의문자들, 그리고 조합문자들(무엇보다 이것은 대부분의 발음구분을 위한 기호들을 포함한다)로 분류된다. 이 집합들은 글자들의 집합을 구성하기 위해 조합된다. 숫자와 확장자들 역시 구분된다.| Characters | ||||||||||||||||||||||||
|
여기 정의된 문자 집합들은 다음의 Unicode 데이터베이스로부터 파생된 것이다.
- Name 시작 문자들은 Ll, Lu, Lo, Lt, Nl 카테고리중의 하나를 가져야만 한다.
- Name 시작 문자를 제외한 나머지 Name문자들은 Mc, Me, Mn, Lm, 또는 Nd 카테고리중 하나를 가져야만
한다.
- 호환 영역에 있는 문자들(예를 들어 #xF900 보다 크고 #xFFFE보다 작은 문자코드와 같이 쓰이는)은 XML
이름들로는 쓰이지 않는다.
- 폰트나 호환성 분해를 갖는 문자들(예를 들어 "<"로 시작하는 데이터베이스의 5번 필드에 있는 호환 포매팅 태그와
함께 쓰이는 것들)은 허용되지 않는다.
- 다음의 문자들은 이름 문자라기 보다는 이름 시작 문자로 간주된다. 왜냐하면 특성 파일이 그것들을 알파벳처럼 분류하기
때문이다. : [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
- #x20DD-#x20E0 문자들은 제외된다. (Unicode 5.14섹션의 규정에 따라).
- #x00B7문자는 확장자로 분류되는데 왜냐하면 특성 리스트가 그렇게 식별하기 때문이다.
- #x0387문자는 이름 문자로 추가되는데 왜냐하면 #x00B7이 그것의 규범적인 동등가이기 때문이다.
- ':' 와 '_' 는 이름시작 문자로 허용된다.
- '-' 와 '.' 는 이름 문자들로 허용된다.
C. XML과 SGML (비규범적)
XML은 SGML의 부분집합으로 설계되었으며 그런 점에서 모든 유효한 XML문서는 적합한 SGML 문서여야 한다. SGML의 문서 규약과 그것을 넘어서는 XML의 추가적인 문서규약을 자세히 비교하려면 [Clark]을 볼 것.D. 엔터티의 확장과 문자 참조 (비규범적) (Non-Normative)
이 부록은"4.4 프로세서의 엔터티와 참조 처리"에 기술된 엔터티참조와 문자참조의 인식과 확장의 예를 잘 보여주는 예들을 담고 있다.만약 DTD가 다음의 선언을 담고 있다면
<!ENTITY example "<p>An ampersand (&#38;) may be escaped |
XML프로세서는 엔터티 선언을 파싱했을 때 문자 참조들을 인식할 것이고 "example"이라는 엔터티의 값대로 다음의 문자열을 저장하기 전에 그것들을 분석할 것이다.:
<p>An ampersand (&) may be escaped |
문서에서 "&example;" 에 관한 참조는 텍스트들이 재파싱되도록 할 것인데 그때 "p"요소의 시작태그와 마침태그는 인식될 것이고 세개의 참조들이 인식되고 확장될 것이며 "p" 요소는 모든 데이터를 가지나 범위한정자나 마크업을 갖지는 않게 된다.:
An ampersand (&) may be escaped |
보다 상세한 예는 규칙들과 그 효과들을 완전히 보여줄 것이다. 다음의 예에서 줄의 수는 오로지 참조들을 위한 것이다.
1 <?xml version='1.0'?> |
이것은 다음과 같은 결과를 낳는다.
- 4번째 줄에서 문자37에 대한 참조는 즉시 확장되고 매개변수 엔터티 "xx"는 "%zz;"값과 함께 심볼 테이블에
저장된다. 대체 텍스트가 다시 스캔되지 않으므로 매개변수 엔터티 "zz"에 대한 참조는 인식되지 않는다. (그리고 "zz"가 아직
선언되지 않았으므로 그것은 에러가 될 것이다)
- 5번 라인에서 "<"에 대한 문자참조는 즉시 확장되며 매개변수 엔터티 "zz"는 대체 텍스트
"<!ENTITY tricky "error-prone" >"와 함께 저장되는데 그것은 well-formed 엔터티
선언이다.
- 6번 라인에서 "xx"에 대한 참조는 인식되며 "xx"의 대체 텍스트(즉 "%zz;")는 파싱된다. "zz"에 대한 참조는
그것의 차례가 되었을 때 인식되며 그것의 대체 텍스트 ("<!ENTITY tricky "error-prone" >")는
파싱된다. 일반 엔터티인 "tricky"가 대체 텍스트 "error-prone"와 함께 이제 선언된 것이다.
- 8번 라인에서 일반 엔터티 "tricky"에 대한 참조는 인식되며 확장된다. 그래서 "test"요소의 모든 내용은
자기기술적인(문법적이지는 않다) 문자열 This sample shows a error-prone method가
된다.
E. 결정성 내용 모델들 (비규범적)
호환성을 위해 엘리먼트 타입 선언의 내용 모델들은 결정적인 것이어야만 한다.SGML은 결정성 내용 모델("명확성unambiguous")을 요구한다. ; SGML 시스템을 사용해 만들어진 XML프로세서는 비결정성 내용 모델을 에러로 신호할 것이다.
예를 들어 내용 모델 ((b, c) | (b, d)) 는 비결정적이다. 왜냐하면 b 라는 이니셜이 주어지면 파서는 어느 요소가 그 b를 따르는가를 찾아보지 않고는 모델 속의 어떤 b가 일치하는 것인지 알 수가 없기 때문이다. 이런 경우 b에 관한 두가지 참조는 하나의 참조로 합쳐질 수 있으며 모델이 (b, (c | d))로 읽게 만든다. 이니셜 b 는 이제 명확히 문서 모델속의 하나의 이름과만 일치하게 된다. 파서는 다음에 무엇이 오는지 살필 필요가 없게 되며 c나 d 모두 받아들여진다.
보다 형식적으로 말하면 한정적인 상태 오토매톤을 표준알고리즘 (예를 들어 Aho, Sethi, and Ullman [Aho/Ullman]의 3.9 부분에 있는 3.5알고리즘)을 이용해 내용모델로부터 구축할 수도 있다. 그와 유사한 많은 알고리즘에서 뒤따라오는 세트는 규범표현(예를 들어 규범표현을 위한 문법 트리에 있는 각각의 리프 노드)는 의 각 포지션에 맞게 구조화된다. ; 만약 어느 포지션이 하나 이상의 뒤따라오는 포지션이 같은 엘리먼트 타입 이름으로 붙여지는 뒤따라오는 세트를 갖게 된다면 내용 모델은 에러상태가 되며 에러로 보고될 것이다.
모든 비결정석 내용 모델들을 제외한 모든 내용모델들이 자동적으로 동등한 결정성 모델들로 변형되도록 하는 알고리즘들이 존재한다. Bruggemann-Klein 1991 [Br?gemann-Klein]을 볼 것.
F. 문자 부호화의 자동 검출(비규범적)
XML 부호화 선언은 어떤 문자부호가 사용되는지를 지시하면서 각 엔터티 내부의 라벨로서 기능한다. 그러나 XML 프로세서가 내부의 라벨을 읽(을 수 있)기 전에, 어떤 문자부호들이 현재 사용되고 있는지-즉 내부의 라벨이 지시하려고 하는 것이 무엇인지-를 분명히 알아야 한다. 일반적인 경우에 이것은 가망없는 상황이지만 XML에서는 완전히 가망이 없지는 않다. 왜냐하면 XML은 일반적인 경우를 두 가지 방법으로 제한하기 때문이다 : 각각의 구현은 한정된 문자부호 만을 지원하는 것으로 가정된다. 그리고 일반적인 경우에 XML 부호화선언은 각각의 엔터티에서 사용되고 있는 문자부호를 자동검출하는 것을 실행가능하게 하기 위해서 위치와 내용에 제한된다. 또한 많은 경우에 다른 정보자원도 XML 데이터열 자체에 부가하여 사용할 수 있다. 두 경우는 아마도 XML 엔터티가 (외부의) 정보를 수반함이 없이 프로세서에 표시되는지 혹은 수반하면서 프로세서에 표시되는지에 따라 구별될 것이다. 먼저 우리는 첫번째 경우를 고려해 보기로 한다.UTF-8 혹은 UTF-16 형식이 아닌 각각의 XML 엔터티는 XML 부호 선언과 함께 시작해야만하기 때문에-그 첫번째 문자는 '<?xml'가 되어야 한다. 어떤 형성 프로세서도 2 혹은 4 바이트의 입력 후에는 그 다음의 어떤 case가 적용되는지를 감지할 수 있다. 다음 리스트를 읽는 것은 UCS-4에서 '<'는 "#x0000003C"이고 '?'는 "#x0000003F", 그리고UTF-16 data streams에 필요한 바이트 순서 마크(Byte Order Mark) 는 "#xFEFF"라는 것을 아는 데 도움을 줄 것이다.
- 00 00 00 3C: UCS-4, 큰 엔디안(endian) 기계 (1234 순서)
- 3C 00 00 00: UCS-4, 작은 엔디안 기계 (4321 순서)
- 00 00 3C 00: UCS-4, 색다른 8비트 명령 (2143)
- 00 3C 00 00: UCS-4, 색다른 8비트 명령 (3412)
- FE FF: UTF-16, 큰 엔디안
- FF FE: UTF-16, 작은 엔디안
- 00 3C 00 3F: UTF-16, 큰 엔디안, 바이트 순서 마크 없음 (그래서 엄격히 말하면 에러상태다)
- 3C 00 3F 00: UTF-16, 작은 엔디안, 바이트 순서 마크 없음 (그러므로 엄격히 말하면 에러다)
- 3C 3F 78 6D: UTF-8, ISO 646, ASCII, ISO 8859의 일부, Shift-JIS, EUC, 또는
다른 7비트나 8비트, 또는 아스키문자들이 정해진 포지션, 넓이, 그리고 값을 갖는다는 것을 확실히해주는 혼합된 넓이 부호화;
실제의 부호화 선언은 이것들 중 어느 것을 적용할 것인지를 감지할 수 있도록 읽혀져야만 한다. 그러나 이 모든 코딩들이 아스키
문자들을 위한 같은 비트 패턴을 사용하기 때문에 부호화선언 그자체는 믿을 만하게 읽혀질 것이다.
- 4C 6F A7 94: EBCDIC(몇몇 플레이버에서; 전체 부호화 선언은 어떤 코드 페이지가 사용중인지를 알려줄 수
있도록 읽혀져야만 한다)
- 그 밖에 부호화 선언없는UTF-8. 그렇지 않으면 데이터열은 훼손되고 파편화되며 또는 어떤 커버에 둘러싸이게
된다.
부호선언의 내용은 ASCII 문자에 국한되기 때문에, 어떤 부호들의 묶음이 사용되는지를 감지하기만 하면 프로세서는 전체 부호화선언을 신뢰할 수 있게 읽어낼 수 있다. 실제적으로 광범위하게 사용되는 문자부호는 위의 범주 중 하나에 들어가기 때문에, XML 부호화선언은 심지어 OS나 혹은 전송 프로토콜 수준의 외부정보소스가 믿을 수 없는 경우에도, 믿을만한 문자부호들의 범위 내(in-band) 라벨링을 합리적으로 가능하게 한다.
만약 프로세서가 사용중인 문자부호를 검색하기만 하면, 각각의 경우를 위한 별도의 입력 루틴을 불러냄으로써 혹은 각각의 입력문자(each character of input)에 맞는 변환기능을 불러냄으로써 프로세서는 적절하게 작동할 수 있다.
다른 어떤 자체 라벨링 시스템과 마찬가지로, 만약 어떤 소프트웨어가 엔터티의 문자세트를 변화시키거나 부호화 선언을 업데이트시키지 않으면서 부호를 바꾼다면 XML부호 선언은 작동하지 않을 것이다. 문자부호 루틴의 구현자는 엔터티를 라벨링하는데 사용되는 내외부 정보의 정확성을 확인하는데 주의를 기울여야 한다.
두번째 가능한 경우는, 어떤 파일시스템이나 어떤 네트워크 프로토콜에서 그런 것처럼, XML 엔터티가 부호정보를 수반할 때 일어난다. 다수의 정보소스가 이용가능할 때, 그들의 상대적인 우선권이나 분쟁 해결 시 선호되는 방법은 XML을 전송하는데 사용되는 상위레벨의 프로토콜의 일부분으로 특화되어야한다. 예를 들어 내부 라벨과 외부헤더에 있는 MIME형식라벨의 상대적인 우선권을 위한 규칙은 텍스트/xml과 어플리케이션/xml MIME 형식을 정의하는 RFC문서의 부분이어야 한다.
- 만약 XML 엔터티가 파일안에 있으면 바이트 순서 마크와 부호선언 PI는 (만약 존재한다면) 문자부호를 결정하는데 사용될
것이다. 다른 모든 발견적 방법(heuristics)과 정보의 소스는 오로지 에러 복구를 위한 것이다.
- 만약 XML 엔터티가 텍스트/xml의 MIME 형식으로 전달된다면 MIME형식의 문자세트 (charset) 매개변수는
문자부호방식을 결정한다. 다른 모든 발견적 방법과 정보의 소스는 오로지 에러 복구를 위한 것이다.
- 만약 XML 엔터티가 MIME형식의 어플리케이션/xml로 전달된다면, 바이트 순서 마크와 부호선언 PI는 (만약
존재한다면) 문자부호를 결정하는데 사용될 것이다. 다른 모든 발견적 방법과 정보의 소스는 오로지 에러 복구를 위한
것이다.
G. W3C XML 워킹 그룹 (비규범적)
이 스펙은 출판을 위해 W3C XML WG(워킹 그룹)에 의해 준비되었으며 승인되었다. 이 스펙에 대한 WG의 승인은 모든 WG멤버가 그것의 승인을 위해 투표했다는 것을 의미하는 것은 아니다. 현재의 그리고 지금까지의 XML WG 멤버는 다음과 같다.Jon Bosak, Sun (의장); James Clark (기술 책임자); Tim Bray, Textuality and Netscape (XML 공동 편집자); Jean Paoli, Microsoft (XML 공동 편집자); C. M. Sperberg-McQueen, U. of Ill. (XML 공동 편집자); Dan Connolly, W3C (W3C 사무관); 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
Copyright © 1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.