XHTML1.0 와 XHTML1.1의 차이

HTML4.01의 특징
HTML은 웹에 필요한 기본적인 항목들을 DTD를 활용하여 선언하여 놓고 그에 따라 문서를 작성하는 방식입니다. 즉 문서를 만드는데 필요한 도구들의 집합이라고 볼수 있습니다. 확장이 불가능하지만 정보를 보여주고 표현하는데에는 문제점이 없을정도로 확장되어있습니다.

XML1.0 (Extensible Markup Language)
XML의 기본 배경은 SGML에서 가장 간단하고 손쉽게 정보의 정의를 선언할수 있도록 한 언어로 자유롭게 정보를 확장할수 있습니다.

XML의 특징
XML 은 특별한 형식을 가지고 있지는 않습니다. 하지만 작성된 웹문서를 재활용할수 있는 방안들이 많습니다.(XST , Xpath , XLink 등) 이유는 만들어진 계기 자체가 정보를 작성함에 있어 간단하고 손쉽게 작성할수 있도록 하기 위해 HTML처럼 미리 정의해 놓은 엘리먼트가 없기 때문입니다. 그렇기 떄문에 정보를 담기에는 최적의 환경을 제공합니다. 하지만 반대로 말한다면 정보가 어떠한 의미로 어떠하게 사용해야 하는것인지에 대해 정확하게 선언해야 합니다.(DTD를 활용)

XHTML1.0 (The Extensible HyperText Markup Language 1.0)
XHTML1.0은 부제가 곧 XHTML의 이름인 것과 같이 “확장이 가능한 웹문서” 라는 것 이며 XML의 데이터로서의 기능과, HTML의 표현이 가능하도록 하는 방법을 가장 큰 이슈로 발전하였습니다.

XHTML1.0의 특징
XML 의 DTD작성 방법을 이용하여 기본적으로 사용하는 XHTML DTD 와는 별개로 또 추가적인 DTD를 사용(확장/Extensible)하여 데이터로서의 새로운 정보의 분류와 수없이 많은 디바이스들에게 현문서의 정보양식 및 표준, 확장을 제시합니다.
각 엘리먼트는 어떠한 의미를 가지고 어떠한 방법으로 표현하는 가에 대한 것이 중점적으로 설명되며, 그것은 XHTML을 지원하는 모든 디바이스는 지켜야만 합니다.

XHTML1.1(Module-based XHTML)
XHTML1.1 은 부제와 같이 모듈을 기본으로 하는 XHTML입니다. XHTML을 추상적인 기준에 따라 분류하여 일정한 목적에 따라 필요 있는, 없는 정보를 분류하고 그에 따른 모듈화된 엘리먼트를 적용하도록 하는 방향으로 지원합니다.
모듈화를 기본으로 하기 떄문에 실제적으로 엘리먼트의 소개 보다는 모듈적인 부분에서 접근하게 됩니다. 엘리먼트의 의미 보다는 모듈의 사용처 및 모듈에 대한 설명, 그리고 그런 모듈을 만드는 방법(XHTML 모듈방법론 / XHTML™ Modularization 1.1 )을 소개하며 이런 방법론 및 기본이 되는 모듈을 총체적으로 XHTML1.1이라 칭합니다.

XHTML1.1의 특징
가 장 큰 기준은 사용하는 엘리먼트는 XHTML1.0과 크게 틀리지 않지만. XHTML1.1에서 추가된 루비요소(ruby) 와 가상모듈(Abstract Modules) 그리고 모듈화가 되어있는 MOD파일이 리스트화 되어있으며. 1.1은 이런 MOD를 가져오거나(include) 또는 베재(igone)하여 새로운 DTD를 생성하게 됩니다.

----------------------------------------------------------------------------------

XHTML1.0와 XHTML1.1의 차이
XHTML1.0 (이하 1.0)와 XHTML1.1(이하 1.1)의 실제 엘리먼트의 차이는 거의 없습니다.(1.1에 루비요소만 추가) 즉 1.0을 사용하던 퍼블리셔는 1.1의 유효성 검사를 패스하는데는 큰 문제가 없습니다. 1.0으로 검사를 통과했다면 1.1도 당연하게 패스가 됩니다. 하지만 1.0와 1.1는 접근하는 개념이 틀리며 그것이 "가상모듈"입니다. 1.0을 사용할수 있다 라는 전제하에 아래의 설명을 보셔야 합니다.

루비요소(ruby)

가상(추상)모듈(Abstract Modules)

실제적으로 모듈이 된것이 아닌, 모듈이 된거 같은 의미를 가지고 있다 라는 뜻으로 모듈 이라는 말보다는 가상모듈 이라는 것으로 실제적으로 XHTML을 모듈화를 표현 하였다.

MOD(Module Definition)

모든 웹문서는 DTD에 의해 정의되고 브라우저에 의해 표현됩니다. 가상모듈 을 포함한 모든 DTD를 분해하여 하나씩의 모듈의정의를 내린 DTD언어로 된 문서입니다. 실제적으로 1.1의 DTD는 이런 MOD들이 모여서 새로운 DTD가 됩니다.

------------------------------------------------------------------------------

XHTML1.1로의 전환의 이유

W3C에서는 이유를 아래와 같이 설명하고 있습니다.

“단 순히 웹 문서에만 사용되던 HTML이 다양한 분야와 기기(모바일 기기, 디지탈 TV 등)에 점점 더 많이 적용되고 있는데 이들 각각은 서로 요구하는 조건이나 구현상의 한계가 다르므로 기존의 규격을 일괄적으로 적용시키기가 어렵다.”

“이 런 문제를 해결하기 위해 도입된 모듈화를 통해서 서비스나 기기를 디자인할 때 표준에 맞게 만들어진 블록을 사용하고, 표준에 맞는 방법으로 어떤 블럭을 사용했는지 알려주는 방식으로 해당 기기가 어떤 모듈을 지원하는지 컨텐츠 커뮤니티(content community)에 명확하게 알려줄 수 있다. 그러면 컨텐츠 커뮤니티는 필요한 특정 모듈을 지원하는 이미 만들어진 기반(installed base)에만 신경을 써서 컨텐츠를 만들어낼 수 있다.”

“표준화된 방식을 사용함으로써 소프트웨어는 기기에 맞게 컨텐츠를 처리할 수 있고, 기기는 필요한 모듈을 처리하기 위한 소프트웨어를 자동으로 불러올(load) 수 있게 된다.”

“또한, 모듈화와 XML의 확장성을 이용해서 XHTML 표준을 어기지 않고도 XHTML 문서의 레이아웃과 디자인의 확장성을 높일 수 있다.”

즉 일괄적인 문서에 디바이스를 맞추는것이 아닌 애초에 디바이스를 고려한 웹문서를 제작할수 있도록 하는 것을 기본 목표로 합니다. 불필요한 정보와 디바이스에 따른 정확한 컨덴츠를 지원하여 표준이라는 이름에 더 맞도록 지원하도록 하는것을 기본으로 합니다. 또한 XHTML이라는 장점으로 브라우져에게는 확실하게 문서의 정보를 보여줄수 있다 라는 장점을 가질수 있습니다.

---------------------------------------------------------------------------------

마치며
XHTML1.1 은 XML의 특징과 HTML의 특징을 가져온 XHTML1.0을 기반으로 하며 1.0이 웹문서의 표준화를 기본컨셉으로 하였다면 1.1은 표준화를 기본으로 하여 추상적인 정의로 엘리먼트를 모아서 새로운 모듈을 만들고 그런 모듈들끼리 모아서 사용자에게 효율적인 정보 제공을 위한 DTD 및 웹문서를 만들기 위해 만들어 진 언어입니다.

아직은 1.1이 이른 발전일지 모르지만, 이미 XHTML은 새로이 발전하고 있으며 1.1을 한단계 더 업한 XHTML2.0 에서는 모듈화 뿐만이 아니라 좀더 구조적으로 변화하고 표현하는것이 적어지는 확실한 구조적인 모습으로 새로이 변모하고 있습니다. 1.1을 좀더 확실하게 이해 하고 사용할수 있다면 새롭게 다가오는 웹문서의 미래에 좀더 유연하게 대처할수 있지 않을까 한번 생각해봅니다.

XHTML (Extensible Hypertext Markup Language)

W3C에서 설명하는 바에 따르면, "XHTML은 XML 응용으로서의 HTML 4를 다시 공식화한 것"이다. 두 가지 용어 모두가 다 생소한 독자를 위해 부연설명을 하면, HTML은 웹상에서 보일 수 있도록 작성자가 문서 내에 집어넣는 일련의 코드 (즉, 마크업 언어)들이며, HTML 4는 그것의 최신 버전이다. XML은 웹상에서 공유될 어떤 종류의 데이터를 정의하는 방법에 관한, 일련의 구조화된 규칙이다. 그것은 누구라도 특정한 목적을 위한 일련의 마크업 세트를 발명할 수 있으므로, "확장될 수 있는" 마크업 언어라고 불리는데, 모든 사람들이 그것을 사용하는 한, XML은 웹페이지의 표현을 묘사하는 것을 포함하여, 여러 가지 목적에 채택되고, 또 사용될 수 있다. 그러한 경우로, XML의 형태로 HTML을 다시 구성하는 것이 바람직하게 보였다. 그 결과가 바로, 웹페이지를 표현하기 위한 XML의 특별한 응용인 XHTML인 것이다.

XHTML은 실제로, HTML 4의 후속 버전이다. 비록 이것이 XHTML 1.0으로 불리지만, HTML 5라고 생각해도 좋을 것이다. XHTML에서는, 모든 HTML 4 마크업 태그들과 속성들이 계속 지원될 것이다. 그러나, HTML과는 달리, XHTML은 그것을 사용하는 누구에 의해서라도 확장하는 것이 가능하다. 이미 존재하는 것에 새로운 태그와 속성들이 정의되고, 추가될 수 있으며, 웹페이지 내에 콘텐츠와 프로그램을 삽입하기 위한 새로운 방법을 만드는 것도 가능하다. 외관상으로는, XHTML 파일이 다소 더 정교한 HTML 파일처럼 보인다.


장 점
W3C의 얘기를 다시 인용하면, 장점은 "확장성과 이식성"이다. 확장성이란, 웹 전달과 표현에 관한 새로운 아이디어가 생기면, 다음 버전의 HTML이나 브라우저의 지원을 기다리지 않고서도 즉시 구현할 수 있게된다. 새로운 태그들이나 속성들이 새로운 가능성들을 표현하기 위해 정의될 수 있으며, 수신 측의 일부 프로그램이 그것을 이해할 수 있고 그것들 상에서 동작할 수 있다고 가정하면, 이전에는 절대로 일어나지 않았던 웹페이지 상에 새로운 것들이 일어날 수도 있다. XHTML에 관한 특이한 확장 판들로는, 수학적인 표현, 벡터그래픽, 그리고 멀티미디어 애플리케이션 등이 예정되어 있다.

만약 확장성이 보다 복잡한 페이지와 더 큰 프로그램으로 가게 될 것 같으면, 웹페이지들이 이전에 비해 더 간단하게 만들어짐으로써 소형장치들이 그것을 처리할 수 있도록 하기 위한, 이식성에 관한 장점이 중요성을 갖는다. 이것은 이동형 장비와, 마이크로프로세서, 프로그램 및 소형 메모리가 내장된 가정용 제품들 들에서는 중요하다. XHTML은 마크업 복잡도에 몇 개의 수준을 정의하며, 각 문서의 시작부분에는 복잡도 수준을 나타낸다. 소형 장치들 내의 프로그램은 소형 프로그램과 메모리로도 처리할 수 있도록, 복잡도가 가장 낮은 수준으로 기술된 XHTML 파일들을 기대할 수 있다.


차이점과 특색
규격과 지침서를 읽으면 더 많은 내용을 알 수 있겠지만, 여기에서는 XHTML의 일부 특색과, HTML 4와의 차이점만을 기술한다.

XHTML은 코딩 규칙을 엄격하게 준수할 것을 요구한다. 특히, 그 중에서도, 태그를 열었으면, 닫는 태그도 반드시 사용해야하고, 모든 태그들은 소문자로 기술되어야한다. HTML은 표기에 관한 한 훨씬 덜 엄격했으며, 브라우저들은 이에 관해 더욱 관대한 경향이 있었다.

이것은 XHTML 파일이 HTML 보다 분주해지는 경향이 있을 거라는 것을 의미한다. 그러나, 그들은 코딩에 있어 더 많은 정돈을 엄격히 요구하므로 읽기에 반드시 어렵지만은 않을 것이다. 추가로, 주요 편집 및 파일 작성도구들은 아마도 읽기 쉽도록 페이지를 배치할 것이다.

XHTML은 콘텐츠와 스타일시트와의 결합에 관한 생각을 보다 구조적이고 개념적인 방법으로 그리고 그것을 표현하는 보다 창조적인 방법 등을 장려하는 듯하다.

XHTML은 문득 새로운 태그들을 생각해내고 추가하는 사람들, 그리고 브라우저나, 그것을 지원하는 다른 애플리케이션들을 개발하는 사람들을 위한 쉬운 방법을 제공할 것이다.

XHTML 규격은 현재 W3C의 실무초안 단계에 있다.

function MakeXML()
{    
    var xmlDom = new ActiveXObject("Microsoft.XMLDOM");

    var objRoot = xmlDom.createElement("ROOT");
    xmlDom.appendChild(objRoot);
   
    var objNode = xmlDom.createElement("DATA");
    objRoot.appendChild(objNode);
 
    var Node1 = xmlDom.createElement("NAME");
    var Node2 = xmlDom.createElement("TEL");
    var Node3 = xmlDom.createElement("ADDRESS");
    var Node4 = xmlDom.createElement("ETC");
   
    Node1.text = "홍길동";
    Node2.text = "000-0000-0000";
    Node3.text = "서울시";
    Node4.text = "프로그래머";

    objNode.appendChild(Node1);
    objNode.appendChild(Node2);
    objNode.appendChild(Node3);
    objNode.appendChild(Node4);
     
    document.getElementById('<%=TextBox5.UniqueID%>').value = xmlDom.xml; 
}

|예제| <xsl:for-each select="테스트/사람">
for-each문은 반복적인 수행을 하기위해서 사용됩니다. select속성에는 반복할 태그명을 설정합니다. <테스트>태그안에 있는 <사람>태그를 반복적으로 읽어오기 위해서 select속성에 "테스트/사람"을 설정하였습니다. 상위태그와 하위태그를 구분하는데 '/'기호를 이용합니다.

|예제| <xsl:value-of select="전화번호">
value-of의 select속성은 속성에 해당하는 문자열을 출력하기위해 사용됩니다.

|예제|  <!ELEMENT test (name?, bc?)>
<test>태그안에 <name>과 <bc>태그를 사용합니다. <name>과 <bc>태그는 한 번 사용하거나 사용하지 않습니다.

|예제|  <!ELEMENT name (#PCDATA)>
<test>태그안에 사용하는 태그로 문자열을 설정합니다.

|예제|  <!ELEMENT bc (#PCDATA)>
<bc>태그안에 사용하는 태그로 문자열을 설정합니다.

#XML 선언방법 및 개념
XML은 데이터가 들어있는 문서로 DTD에 선언된 태그를 참고하여 작성합니다. 또한 XSL에서 작성된 양식을 XML과 함께 사용하면 다양한 출력형태를 만들어 낼 수 있습니다.
XML을 식별하기 위해서는 식별문장을 작성합니다.
   <?xml version="1.0" encoding="euc-kr" standalone="no"?>
또는
   <?xml version="1.0" encoding="ks_c_5601-1987" standalone="no"?>
식별문장은 대소문자를 구분하므로 꼭 소문자로 작성해야 합니다.
  영문 xml선언
<?xml version="1.0" encoding="UTF-8"?>

#헤더(Header)부분의 속성
- version : XML의 버전을 설정합니다.
- encoding : 국가별 인코딩을 설정합니다. 우리나라는 "euc-kr"이나 "ks_c_5601-1987"로 설정하면 됩니다.
- standalone : XML문서를 독립적으로 사용할 지, 외부의 DTD를 읽어올지 유무를 설정합니다. "yes"를 설정하면 XML문서를 독립적으로 사용하겠다는 의미입니다. "yes"나 "no"를 사용하여 설정합니다.

#노드(NODE)
노드는 리스트 등과 같은 자료구조에서 정보의 기본 단위. 혹은 분기점/접속점으로 설명될 수 있습니다.
<주소록>태그는 XML태그의 부모노드라고 합니다. 부모노드는 XML파일을 대표하는 이름이므로 한 개만 존재해야 합니다.
<사람>태그는  최상위 자식노드입니다. 부모노드는  꼭 한 개만 존재해야하지만 최상위 자식노드는 동일한 것이 여러개 존재할 수 있습니다.
<이름>, <방송>태그는 최상위 자식노드에서 파생된 자식노드입니다.

부모노드와 자식노드를 데이터베이스용어에 비유한다면 다음과 같이 설명할 수 있습니다.
- 부모노드 :: 테이블
- 최상위 자식노드 :: 레코드(<사람>태그가 두개있으므로 두 개의 레코드가 있는 것입니다.)
- 자식노드 :: 필드. 이름, 방송필드가 있는 것입니다.
XML파일은 부모노드를 시작으로 상속받아 계속적으로 자식노드를 만들 수 있기때문에 데이터베이스의 용어와 비유한다는 것은 약간 무리가 있습니다. 그렇지만 비유해서 생각하면 XML파일을 데이터베이스의 테이블처럼 사용할 때 이해가 쉽게 될 것입니다.

#XML의 파일구조
HTML은 대소문자를 구분하지 않지만, XML은 대소문자를 구분합니다. XML파일은 DTD파일과 XSL파일을 호출하여 사용할 수 있습니다. 또한, DTD와 XSL파일을 XML파일안에 삽입하여 사용할 수도 있습니다.
XML과 함께 사용되는 파일의 종류와 설명은 다음과 같습니다.
- DTD(.dtd) : 요소를 선언합니다.
- XSL(.xsl) : 문서의 스타일시트를 만들어 줍니다.
- XML (.xml) : 문서의 정보를 작성합니다.

#DTD(Document Type Definition)
HTML과는 다르게 XML은 태그를 만들 수 있습니다.
DTD(문서형식정의:Document Type Definition)는 사용자가 만든 태그를 정의하는 부분입니다. DTD안에 정의된 태그의 형식에 맞춰 XML문서를 작성합니다. 그러므로 DTD에 선언된 태그는 정상적으로 XML에서 사용했는 지의 유무를 알 수 있으므로 XML문서의 에러검증을 하는 데도 사용됩니다.
DTD는 XML문서안에 포함하여 사용하거나 XML문서안에서 저장된 DTD파일을 읽어와서 사용할 수 있습니다.
DTD는 장점과 단점을 가지고 있습니다. 사용자가 DTD를 매번 만든다면 참으로 어려운 작업이 될 것입니다. 그러므로 개인사용자가 쓰기엔 불편한 점이 많습니다. 그러나 표준적인 DTD를 제공한다면 사용자가 손쉽게 작업을 할 수 있을 것입니다.

#DTD파일 작성예제
<?xml version='1.0' encoding='ks_c_5601-1987'?>
<!ELEMENT 주소록집 (주소록*)>
<!ELEMENT 주소록 (전화번호+, 이메일*, 주소?)>
<!ATTLIST 주소록 이름 CDATA #REQUIRED>
<!ELEMENT 전화번호 (#PCDATA)>
<!ATTLIST 전화번호 종류 CDATA #REQUIRED>
<!ELEMENT 이메일 (#PCDATA)>
<!ELEMENT 주소 (#PCDATA)>

#DTD내 요소(Element)의 정의
DTD에서 정의하는 태그이름을 요소(Element)라고 합니다.
|형식|
   <!ELEMENT 요소이름(내용)>
|예제|
   <!ELEMENT address(name+, email?)>
   <!ELEMENT title(#PCDATA)>

ATTLIST선언은 태그안에 속성을 만듭니다.
|형식|
   <!ATTLIST 요소명 속성명 형문자 속성선언>
|예제|
   <!ATTLISE address tel CDATA #REQUIRED>

#요소내 기호설명
 () : 그룹요소
|예제|  (태그1|태그2),태그3
태그1이나 태그2중의 하나가 나타나고 그 뒤에 태그3가 나타납니다.

 * : 여러번 사용할 수도 있거나 사용하지 않을 수 있습니다.
|예제|  태그1*
태그1이 여러번 나타나거나 나타나지 않을 수 있습니다.

 + : 한 번이상 나타납니다.
|예제|  태그1+
태그1이 한번이상 나타납니다.

 , : 나열된 순서대로 나타납니다.
|예제|  태그1, 태그2
태그1이 나타난 다음에 태그2가 나타납니다.

 ? : 1회나타날 수 있거나 나타나지 않을 수 있습니다.
|예제|  태그1?
태그1이 한번 나타나거나 나타나지 않습니다.

 | : or조건
|예제|  태그1|태그2
태그1 또는 태그2가 반드시 나타납니다.

 없음 : 1회 나타납니다.
|예제|  태그1
태그1이 한번 나타납니다.

#요소내 키워드
- #PCDATA : 'parsed Character DATA'의 약어로 문서의 문자열을 전달하겠다는 의미로 사용됩니다.
  해당문자열의 nodeName은 '#text'로 반환됩니다.
- EMPTY : 문자열내용이 없는 태그를 사용하겠다는 의미입니다.

#DTD에서 사용되는 형 문자
CDATA : 문자데이터
ID : 다른 ID형과 구분되는 고유이름
IDREF : 다른 ID형에 정의된 이름
IDREFS : 다른 ID형에 정의된 이름이 목록
ENTITY : 미리 선언된 외부객체의 이름
ENTITES : 미리 선언된 외부객체이름의 목록

#DTD내 속성선언
#REQUIRED : 속성값을 꼭 지정해야 합니다. 그렇지 않으면 노드에러를 출력합니다.
#IMPLIED : 속성값을 지정하지 않아도 됩니다. 속성값을 지정하지 않으면 노드를 무시합니다.
#FIXED value : [value]를 요소에서 설정해야 합니다. 요소에서 이 속성을 사용하지 않으면 [value]로 처리합니다.
defaultvalue : 기본값을 설정합니다. 요소를 설정하지 않으면 defaultvalue로 설정됩니다.

#XML문서안에 DTD선언
DOCTYPE선언은 DTD파일을 호출하거나 DTD내용을 선언하기 위해서 사용됩니다.
|예제|
   <?xml version="1.0"?>
   <!DOCTYPE 부모노드명 [
    <!ELEMENT 부모노드 (#PCDATA)>
   ]>

#XML에서 DTD파일을 호출
|에제|
   <?xml version="1.0"?>
   <DOCTYPE 부모노드명 SYSTEM "test_dtd.dtd">

#XML
SGML(Standard Generalized Markup Language)은 HTML(Hyper Text Markup Language)이나 XML(eXtensible Markup Language)의 조상이 되는 언어입니다. SGML은 다양한 표준적인 기능을 포함하고 있지만 작성하기에는 까다로운 부분이 있어 일반사용자가 사용하기엔 어려운 부분이 많았습니다. 그렇기 때문에 특정 데이터를 처리(통계적요약, 수학적표시, 설명서등)하기 위해 사용되었습니다.

SGML을 단순화시켜서 발표한 것이 HTML입니다. HTML은 SGML의 기본적인 태그부분을 사용하여 사용자가 쉽게 작성할 수 있게 만들었습니다.
 HTML은 단순화된 태그라서 인터넷상의 문서를 처리하기에 부족한 부분이 많았습니다. 그래서 새롭게 등장한 것이 XML입니다.
 XML은 SGML에 근접하면서도 까다롭고 사용하지 않는 부분을 제거하고 HTML보다 확장된 기능을 포함하고 있습니다. 예를 들면, HTML은 기존에 만들어진 태그만을 사용하지만 XML은 사용자가 태그를 만들어 낼 수 있습니다.

 W3C(World Wide Web Consortium)은 웹에 관련된 표준제정과 발전을 돕는 단체입니다. W3C는 투표를 통하여 웹표준이 선정되면 공식적인 표준을 인터넷사이트에 발표합니다. 그렇기때문에 XML에 관한 정보는 'www.w3c.org'를 통해 자료를 얻을 수 있습니다.

#기본양식
|예제| <?XML version="1.0"?>
XML문서임을 알려주는 헤더(Header)부분입니다. 현재 사용되는 버전은 1.0이므로 version속성에 '1.0'을 설정합니다. XML은 HTML의 대부분 태그를 지원하고 있기 때문에 XML에서 HTML태그를 사용할 수 있습니다.

|예제| <b>XML에 오신 걸 환영합니다.</b><br></br>
HTML의 <br>태그는 한 라인을 띄우기위해서 사용되고 태그를 닫아주는 </br>가 쓰이지 않습니다. XML에서도 <br>태그는 한 라인을 뜨우기위해 사용되지만, XML에서는 시작과 끝이 없는 태그를 허용하지 않기때문에 <br>태그도 다음과 같이 닫아줘야 합니다.

|예제| <img src="naver.gif"/>
XML에서는 img태그도 마지막에 닫아주기위해 "/"를 삽입해야 합니다.

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

REC-xml-19980210

Extensible Markup Language (XML) 1.0

1998년 2월 10일 W3C 추천안

이 버전:

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

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

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

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

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

최종 버전:

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

이전 버전:

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

작성자들:

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

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

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

요약

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

이 문서의 상태

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

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

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

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

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

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

목차

Appendices

1. 소개

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

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

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

1.1 기원과 목표

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

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

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

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

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

1.2 용어

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

할 수 있다(may)

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

하여야 한다(must)

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

오류

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

치명적 오류

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

사용자의 선택으로

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

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

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

잘 형성됨을 위한 필수사항

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

일치

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

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

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

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

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

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

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

2. 문서들

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

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

2.1 잘 형성된 XML 문서들

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

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

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

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

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

2.2 글자

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

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

2.3 공통(common) 문법적 구성

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5 코멘트(comment)

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

코멘트의 예제:

2.6 처리지시

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

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

2.7 CDATA 항목

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

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

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

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

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

이것도 같다:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.10 공백의 처리

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

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

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

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

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

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

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

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

2.12 언어의 인식

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

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

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

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

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

예를 들어:

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

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

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

3. 논리적 구조

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

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

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

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

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

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

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

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

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

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

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

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

시작태그의 예제:

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

종료태그의 예제:

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

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

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

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

3.2 엘레멘트 타입 선언

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

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

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

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

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

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

3.2.1 엘레멘트 내용

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

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

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

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

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

3.2.2 혼합 내용(mixed content)

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

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

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

혼합 내용 선언 예제:

3.3 애트리뷰트 목록 선언

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

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

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

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

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

3.3.1 애트리뷰트 타입

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

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

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

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

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

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

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

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

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

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

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

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

3.3.2 애트리뷰트 디폴트

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

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

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

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

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

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

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

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

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

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

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

3.4 조건부 항목

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

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

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

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

예제:

4. 물리적 구조

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

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

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

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

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

4.1 글자와 엔티티 참조

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

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

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

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

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

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

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

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

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

글자와 엔티티 참조 예제:

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

4.2 엔티티 선언

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

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

4.2.1 내부적 엔티티

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

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

내부적 엔티티 선언 예제:

4.2.2 외부적 엔티티

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

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

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

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

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

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

외부적 엔티티 선언 예제:

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

4.3.1 텍스트 선언

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

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

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

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

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

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

4.3.3 엔티티 안의 글자 엔코딩

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

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

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

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

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

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

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

엔코딩 선언 예제:

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

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

내용(content) 참조

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

애트리뷰트 값의 참조

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

애트리뷰트 값으로 나타남

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

엔티티(entity) 값 참조

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

DTD 참조

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

4.4.1 인식 못함

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

4.4.2 포함

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

4.4.3 포함된 If 유효성 검정

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

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

4.4.4 금지된

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

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

4.4.5 리터랄(literal)에 포함된

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

잘 형성된 예제:

그렇지 않은 예제:

4.4.6 알림(notify)

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

4.4.7 통과(bypassed)

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

4.4.8 PE로 포함된

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

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

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

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

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

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

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

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

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

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

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

4.7 주석(notation) 선언

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

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

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

4.8 문서(document) 엔티티

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

5. 규격부합성

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

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

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

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

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

5.2 XML 처리자(processor)의 사용

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

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

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

6. 주석(notation)

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

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

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

#xN

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

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

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

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

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

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

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

"string"

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

'string'

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

(expression)

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

A?

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

A B

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

A | B

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

A - B

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

A+

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

A*

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

/* ... */

코멘트(comment).

[ wfc: ... ]

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

[ vc: ... ]

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

부록

A. 참조

A.1 지명적 참조

IANA

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

IETF RFC 1766

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

ISO 639

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

ISO 3166

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

ISO/IEC 10646

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

Unicode

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

A.2 다른 참조

Aho/Ullman

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

Berners-Lee 등.

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

Br?gemann-Klein

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

Br?gemann-Klein and Wood

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

Clark

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

IETF RFC1738

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

IETF RFC1808

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

IETF RFC2141

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

ISO 8879

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

ISO/IEC 10744

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

B. 글자 분류

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

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

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

C. XML 과 SGML (비지명적)

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

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

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

선언이 DTD를 포함하려면

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

저작권 정보

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

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

저작권 정보